Send DNS queries through a VPN tunnel
-
-
Yes DNS traffic has to be passed by the rules you see on LAN. So it will be passed by a catch all rule there unless you have a DNS specific rule above it as you did.
-
Yes, if you reject traffic to private addresses clients on that interface will not be able to access other local subnets. You might also want to reject traffic to 'this firewall' also so they can't access the pfSense webgui by using the public WAN IP.
You only need to pass DNS/NTP etc to the interface address if clients need to use local services for that. They could jusy use external DNS and NTP servers. -
If you want clients to use local services and still have that traffic go over the VPN then those services need to use the VPN gateway exlusively, yes. Not sure you can do that for ntp.... I've never tried.
-
See my note in #2. 'this firewall' is every IP on the firewall including the WAN IP. If you come from an internal interface you can still hit the WAN IP and get the webgui otherwise.
If you set Unbound (the DNS resolver) to use only the VPN for outgoing queries the firewall itself should still be able to resolve when the VPN is down as long as it has other DNS servers set either in System > General Setup or passed by the ISP etc. You can also set
Do not use the DNS Forwarder/DNS Resolver as a DNS server for the firewall
in System > General Setup to stop it trying to use the resolver. I assume you were seeing it fail to resolve the NordVPN server IP when the VPN was down.Steve
-
-
@stephenw10 God bless, he's back! lol
About your notes in #2 and #3:
(A) The only way users can access the webgui is through the WAN IP and the LAN IP?
(B) Maybe this one is a really newb question but still - Since users will be using the Router/pfSense as their DNS, Passing DNS/NTP to the interface address (destination) will actually catch all the DNS requests made by the users, right? Also, Since NTP in only for clock synchronization I don't need to pass it through VPN.About your note in #4:
(C) If I block "This firewall (self)", users (whom I blocked) won't be able to access the webgui, right?
(D) What does "This firewall (self)" include exactly? WAN IP + the IPs of all the interfaces + 127.0.0.1?
(E) Regarding (D) & (C) and if I'm right in (D) - if on top of that I also want to allow only certain interfaces, I would need to add the relevant rules before the rule that blocks "This firewall (self)", correct?@stephenw10 said in Send DNS queries through a VPN tunnel:
You can also set Do not use the DNS Forwarder/DNS Resolver as a DNS server for the firewall in System > General Setup
That's exactly what I did. This + the fact that I once set Outgoing Network Interfaces (under DNS Resolver) to use only the VPN gateway, is the reason why the VPN failed to reconnect after a failure?
@stephenw10 said in Send DNS queries through a VPN tunnel:
If you set Unbound (the DNS resolver) to use only the VPN for outgoing queries the firewall itself should still be able to resolve when the VPN is down
I think I'll just use Localhost as @johnpoz suggested. I'm policy routing what I want under VPN anyway...right? lol :)
-
The pfSense webgui listens on all IPs on the firewall so users can access it on any address that firewall rules allow them to reach. Usually that's the LAN and WAN IPs.
If you are passing the interface address to clients to use for DNS via DHCP, which is the default setting, they will mostly use that. But they can choose to ignore that and use a different DNS server. Some devices or applications are hard coded with DNS servers to use.
Users who are blocked from 'this firewall' will not be able access the webgui. The system alias 'this firewall' includes all IPs used by the firewall itself. It does not include subnets those IPs are in so it not prevent access between internal subnets, you would need a different rule for that.
If the firewall was set to not use the resolver itself and you had valid DNS server either passed by your ISP or set locally then the fact the resolver might not have been able to reach the root servers would not have stopped the VPN from coming up. You should check what is working on Diag > DNS Lookup. Everything there should respond when the VPN is connected. 127.0.0.1 may not if it's set to use the VPN and the VPN is down.
If you use localhost as the source address for Unbound it will use whatever the default route is. That should be via the WAN to allow the VPN to come up.
If you want clients to send DNS queries over the VPN you either need to set Unbound to use the VPN address and have clients use that, or have clients use some external DNS server and policy route that over the VPN.Steve
-
@stephenw10 said in Send DNS queries through a VPN tunnel:
If the firewall was set to not use the resolver itself and you had valid DNS server either passed by your ISP or set locally then the fact the resolver might not have been able to reach the root servers would not have stopped the VPN from coming up. You should check what is working on Diag > DNS Lookup. Everything there should respond when the VPN is connected. 127.0.0.1 may not if it's set to use the VPN and the VPN is down.
Sorry, but I think you misunderstood me. What I meant is that if you choose the VPN to be the only Outgoing Network Interface in the DNS Resolver, than when the VPN temporarily goes down it won't be able to "revive" itself through its own gateway as set in the DNS Resolver. It's "the egg and the chicken" thing and would be a funny paradox which I actually experienced...lol
Edit: On the other hand I use the plain IP of the VPN server instead of url/name and maybe I even misunderstood the DNS Resolver and it has no affect on what would be used as the default gateway for the outbound traffic, and this is actually determined by whatever is defined under System > Routing, on the Gateways tab? I'm confused already...idk@stephenw10 said in Send DNS queries through a VPN tunnel:
it will use whatever the default route is. That should be via the WAN to allow the VPN to come up.
That's exactly the behavior I want, and the reason I set it as localhost :)
@stephenw10 said in Send DNS queries through a VPN tunnel:
or have clients use some external DNS server and policy route that over the VPN.
Ok...but what if I want to have the clients use the default interface address as their DNS and/or external DNS (if they set any), catch all these requests and force them through the VPN gateway? According to my logic, which is based on my limited knowledge right now, with such a setup there would be a problem with the requests to the interface address because that would be seen as the DNS server destination and sent to the VPN server, before it reaches the pfSense DNS Resolver in order for it to forward the request to the DNS server manually set under General Setup.
Am I right here, or totally missing the order of things? -
The VPN should be able to come back up even if the DNS resolver is completely disabled as long as the system has some other DNS servers to use. Or if you're using an IP directly it doesn't even need that! If your VPN is not coming back up it's nothing to do with the DNS settings.
More likely it's because the default route got set to the VPN gateway and then to none. Set the default gateway to the WAN gateway to avoid that.If you set the DNS resolver to use local host and then you set all the clients to use the resolver and the default gateway is set to the WAN then all DNS queries will go out of the WAN and not over the VPN.
Steve
-
@stephenw10 said in Send DNS queries through a VPN tunnel:
More likely it's because the default route got set to the VPN gateway and then to none
This gateway routing problem disappeared after I added WAN to the Outgoing Netwrok Interface. I only changed that and VPN could reconnect after a reboot/disconnection/failure etc.
@stephenw10 said in Send DNS queries through a VPN tunnel:
Set the default gateway to the WAN gateway to avoid that
Yeah...that's what I had in mind. So under System > Routing set the default gateway to be the WAN instead of "automatic"?
@stephenw10 said in Send DNS queries through a VPN tunnel:
If you set the DNS resolver to use local host and then you set all the clients to use the resolver and the default gateway is set to the WAN then all DNS queries will go out of the WAN and not over the VPN.
- But that's what I want to avoid. So, I have to ask again: How do I "collect" ALL DNS requests regardless of what the clients set for themselves (8.8.8.8, 1.1.1.1 etc.) and send them to the "outside world" through the VPN?
- If I understand DNS and firewall rules correctly then these assumptions will be true (correct me if I'm wrong):
(A) For an interface with a single "Allow this interface net to any" Pass rule, all traffic including DNS would pas through that rule and the gateway defined under that rule.
(B) If (A) is true and I added a rule for tcp/udp 53,853 with VPN as the gateway, than all DNS requests directed to the interface address (default behavior) would be sent to the VPN server with destination of "interface IP" (instead of 1.1.1.1 etc.) which is wrong since there's no such DNS out there lol....Am I getting it wrong?
Thank you,
-
If you want all DNS traffic to over the VPN there are two options (there are probably more):
-
Clients use Unbound for DNS and Unbound sends all of it queries over the VPN.
-
Clients use some external DNS server and you policy route that over the VPN along with all the other client traffic.
To achieve option 1 you either set Unbound to use the VPN address for it's queries, but that seems to be breaking the connection for you for as yet unknown reasons, or set the VPN gateway to be the default gateway.
I would suggest finding out exactly why the tunnel fails to come back up if Unbound is set to use it exclusively.
Steve
-
-
A completely separate option here if you're only trying to hide DNS queries from your ISP is just to set Unbound to use DNSoverTLS.
Steve
-
@stephenw10 said in Send DNS queries through a VPN tunnel:
I would suggest finding out exactly why the tunnel fails to come back up if Unbound is set to use it exclusively
I think that wasn't the problem. The problem was that the default gateway was set (by default) to be "automatic" and this problem probably occurred when the VPN gateway was chosen by pfSense to be the default gateway.
Regardless, If I choose option 1 and I have a Pass rule for DNS (because of "Block RFC1918") then all the DNS requests made to the local interface address will be sent through the default gateway which is the WAN, when the VPN is down. In that case I think I'll just use DoT.
@stephenw10 said in Send DNS queries through a VPN tunnel:
Clients use some external DNS server and you policy route that
That's not dynamic and would require human intervention and clients setting up stuff...I want a solution of "One ring to rule them all, One ring to find them, One ring to bring them all and in the darkness bind them" LOL
@stephenw10 said in Send DNS queries through a VPN tunnel:
set Unbound to use DNSoverTLS
If I want the interface address to be the DNS address for clients, encrypt all of it AND also have the WAN as the default gateway to avoid the problems we discussed about then...My only option is probably DoT, right?
Please clarify it for me if you may. I want to be a 100% sure I understand it correctly:
-
Any DNS request sent to the interface address and catched by a firewall rule and forced through the VPN gateway would fail to resolve because the VPN server would see a DNS request with a destination of "192.168.x.x" and won't be able to resolve it. This happens because the firewall rule catched it before the DNS Resolver? Edit: If I totally misunderstood how it works then I should be able to policy route whatever I want, even DNS requests made to the local interface address, right?
-
DoT is between a DNS server and the end user and unless the DNS server belongs to the VPN provider, it has nothing to do with them and therefore won't even matter if they themselves support DoT etc., right?
-
If instead of Localhost, the VPN will be used as the Outgoing Network Interface in the DNS Resolver, would it affect the inner proper functionality of the pfSense box in case the VPN is down, or pfSense would still be able to resolve DNS/NTP for its own needs without needing the DNS resolver?
EDIT: Making long story short, I want to be able to properly achieve both sending all DNS queries through one interface/gateway AND policy routing the DNS queries of certain interfaces if desired over the former.
Thank you,
-
-
Sorry you had to wait five years for the answer, but here it is.
Yes, you can do this. But, how you accomplish it depends upon how your devices are configured to get their DNS.
If you set-up PfSense to route all traffic from a particular device on a particular IP over the VPN, and that device attempts to get its DNS from a public DNS resolver, then the DNS requests, like all traffic from that particular device, will already go out over the VPN.
So, for example, if you configure Pfsense to send all traffic from 192.168.1.15 to a VPN, and 192.168.1.15 is configured to get DNS from 8.8.8.8, then when 192.168.1.15 attempts to query 8.8.8.8 for DNS, that traffic (like all traffic from 192.168.1.15) will go out on the VPN.
But, if you configured 192.168.1.15 via DHCP and you told it to get DNS from YOUR ROUTER (192.168.1.1), and your router responds to DNS queries, then that traffic will NOT go out on the VPN. It will go to your Pfsense router, which will then obtain its DNS information however it normally gets it. If you configure your router to get secure DNS, the request will be encrypted, but it won't go out the VPN. If you get it from unencrypted DNS servers on port 53, the traffic won't be encrypted.
There is a way to accomplish this, however, and that is by using a Port Forwarding rule. You would set-up a rule that automatically forwards any requests to port 53 from 192.168.1.15 to use a specific DNS server on the internet (such as 8.8.8.8). That would prevent 192.168.1.15 from using the router for DNS, but would instead send the query out on the internet. Here's how:
Firewall -> NAT -> Port Forward
Interface: LAN
Protocol: TCP/UDP
Source: Address or Alias: 192.168.1.15
Destination Port Range: DNS / DNS
Redirect Target IP: 8.8.8.8
Redirect Target Port: DNS
Filter Rule Association: Add associated filter rule
Description: Force DNS to VPN
Firewall -> Rules -> LANEdit the rule "NAT Force DNS to VPN"
Show Advanced
Gateway: (Select your VPN Gateway Here)The "add associated filter rule" and editing that rule to refer to the gateway won't be necessary if you already have a LAN rule redirecting all internet traffic from 192.168.1.15 to the VPN, but there could be circumstances where you'd need it (such as if you configured it so that only TCP traffic from 192.168.1.15 to the VPN).
Also, you can replace 192.168.1.15 and 8.8.8.8 with Aliases to make it easier to set-up rules affecting multiple clients if you like.