TrueNAS Scale - OpenVPN Server - Client Access to Pihole Docker

[shauno100]

Hi,

I'm an amateur when it comes to networking so this is probably an easy fix. I am having an issue where my VPN clients connected to the OpenVPN server running on my TrueNAS Scale box being unable to ping/access web interface of and do DNS lookups against my Pihole DNS running as a docker on my TrueNAS.

A basic outline of my setup is as follows:

Main router has IP 192.168.225.1, TrueNAS Scale box IP is 192.168.225.250. PiHole docker running on TrueNAS box is 192.168.225.251. My DHCP server in router is configured to issue 192.168.225.251 as DNS server.

OpenVPN IP address subnet is 192.168.227.0/24.

Currently when i set OpenVPN server additional parameters to use my router IP for DNS

Code:

push "dhcp-option DNS 192.168.225.1"

my OpenVPN clients can see all LAN devices and can connect to them all via IP/hostname except my Pihole DNS, internet traffic is also routed through the VPN tunnel no issue.

I have Pihole DNS set to permit all origins under settings>DNS. I also have nftable rule set on the TrueNAS Scale box below:

Code:

#!/usr/sbin/nft -f


table ip nat {
        chain postrouting {
                type nat hook postrouting priority srcnat; policy accept;
                ip saddr 192.168.227.0/24 oif "enp2s0" snat to 192.168.225.250
        }
}

Do i need to do some additional routing changes to make the Pihole DNS (182.168.225.251) accessible to the VPN clients?

I should also mention i have tested by changing OpenVPN additional settings to use piHole IP for DNS but doing this results in LAN devices only being accessible vua IP and not hostname and internet access does not work. Using router IP for DNS fixes LAN hostname resolution and internet access but does not allow a connection to PiHole DNS whatsoever.

 

[DaSnipe]

Maybe add the following in System -> Advanced -> Sysctl

 

[shauno100]

I already had the net.ip4.ip_forward command set, i haven't set the 2nd cmd in your screenshot however. I will give it a go.

 

[shauno100]

Thaks for suggestion but your 2nd command "net.ipv4.conf.all.src_valid_mark" value = to 1 has completely broke my LAN, i can no longer access the TrueNAS itself on IP 192.168.225.250 let alone do DNS lookups on the Pihole DNS docker container running on it. I will now need to reset the NIC via console access.

 

[shauno100]

Ignore the above reply, it didn't break anything it turns out. Still unable to ping pihole IP from OpenVPN client though unfortunately.

 

[DaSnipe]

Thaks for suggestion but your 2nd command "net.ipv4.conf.all.src_valid_mark" value = to 1 has completely broke my LAN, i can no longer access the TrueNAS itself on IP 192.168.225.250 let alone do DNS lookups on the Pihole DNS docker container running on it. I will now need to reset the NIC via console access.

Oh well, I use Wireguard personally so figured it might help, good luck with this, someone should help

 

[shauno100]

Because my TrueNAS Scale box is on my local LAN (192.168.225.250) in 192.168.225.0/24 subnet and the PiHole docker is also allocated a static IP (192.168.225.251) in this same local subnet, i'm thinking i may need to do an extra route from OpenVPN subnet 192.168.227.0/24 through the kubernetes routing as can be seen in above screenshot?

I'm clutching at straws here but i'm thinking even though piHole is on local LAN, as far as a OpenVPN client is concerned it cannot just access the PiHole docker (192.168.225.251) as if it was a local LAN device even with the postrouting below set which can be seen in above screenshot:

Code:

#!/usr/sbin/nft -f


table ip nat {
        chain postrouting {
                type nat hook postrouting priority srcnat; policy accept;
                ip saddr 192.168.227.0/24 oif "enp2s0" snat to 192.168.225.250
        }
}

As there's actually a Kubernetes networking stack between the TrueNAS itself 192.168.225.250 and the piHole docker running on it - 192.168.225.251.

I think i need to somehow link these up with a specific static route. Once again open to help with this as network routing is not my strong suit.