Send DNS queries through a VPN tunnel

techtester-m

@johnpoz said in Send DNS queries through a VPN tunnel:

then if the vpn is down you should be down and you shouldn't send anything anywhere..

The tinfoil hat is not that tight :)
There's a difference between NO_WAN_EGRESS/Policy Route restricting all/certain interfaces,
and the entire pfSense box losing communication because the VPN is down and the VPN is unable to refresh/reconnect itself which requires human intervention...

@johnpoz said in Send DNS queries through a VPN tunnel:

No shit they want all your traffic going through them

They're listed in Panama and don't log anything, but even if they did I'd rather them have the info than "The Establishment/ISP" even if I'm just watching YouTube. It's the principal of "Stick it to the man" lol.
Also, What about people who live in China or North Korea? Don't they need this type of security?

@johnpoz said in Send DNS queries through a VPN tunnel:

just pick your localhost as outbound interface and it will query through the connection that is up

Sounds like a more solid and permanent solution than selecting WAN and every VPN interface you have...Thanks.

techtester-m

@stephenw10 Ok...I would like to redirect all DNS requests from the interfaces/users to pfSense like mentioned in the DOCs and also route them through the VPN.
Under General Settings I use Cloudflares' DNS servers and that's the only ones everyone on the network should use.

The pfSense box itself should have DNS/NTP access for its needs, as usual of course.

I asked a little bit broader question here, if you may: https://forum.netgate.com/topic/148426/an-isolated-interface-with-an-access-to-the-internet-via-an-openvpn

Btw, I really really really appreciate all the help but...these simple (I think) questions are wasting me whole days because by the time someone is ON and can answer them, 4/8/12 hours have passed, the answers are not exactly answering everything I asked and/or arise just more questions, which results in a cycle kinda like "the egg and the chicken" lol...

@johnpoz these type of answers with screenshots or at least something like "System > General Setup" etc. are the best in my opinion.

I would gladly pay for a live chat support or something but seems like the cheapest NetGate support costs $300-500! LOL

Thanks,

JeGr

@techtester-m said in Send DNS queries through a VPN tunnel:

They're listed in Panama and don't log anything, but even if they did I'd rather them have the info than "The Establishment/ISP" even if I'm just watching YouTube. It's the principal of "Stick it to the man" lol.
Also, What about people who live in China or North Korea? Don't they need this type of security?

How about watching that: https://www.youtube.com/watch?v=WVDQEoe6ZWY
Really says anything that's important. No logging? Really honest? BTW NordVPN just had an "incident" with log exploits, that they claimed were from contractors or the DC personnel but besides that, claiming to have no logs is ... interesting.

To cite the video (and that is something that already happened as far as black boxes and stuff goes...):

(...) But to customers, a VPN that doesn't keep logs is indistinguishable from a VPN that's been compromised by hackers, or that's been given a small little government black box that they don't (want to) understand but they have to plug into their systems and NOT tell anyone about (gag order etc.). Or from a VPN where a single employee has been bribed and has started logging things for just a few accounts. To be clear, I do not think any of the VPN services are a front for the FBI or Russian mobsters, or some state-sponsored plausibly-deniable intelligence operation. Genuinely they are almost certainly not, and I do not want to scaremonger. Any company that was found to be logging stuff without permission would be bankrupt soon after, it would be a very bad business decision. And the enormous amount of money that VPN companies suddenly have probably comes from overenthusiastic venture capital firms. Actually, it almost certainly comes from them. Hopefully. But if you wanted to see what the most paranoid, security-conscious people are connecting to, and you wanted to install software on their systems that is designed to read all their network traffic and then redirect it through a single choke point, then setting up a VPN service with a HUGE advertising budget would be a great way to do it!

techtester-m

So, since we can't (completely) trust anyone, what VPN provider would you suggest?

@JeGr said in Send DNS queries through a VPN tunnel:

claiming to have no logs is ... interesting

Sorry...didn't mean no logs at all, but probably nothing personalized besides your email/username and pass.

I really appreciate your time and input, but none of it answers the core of my post/questions lol :)

JeGr

@techtester-m said in Send DNS queries through a VPN tunnel:

I really appreciate your time and input, but none of it answers the core of my post/questions lol :)

I didn't add things to the mix that were already there, sorry. Just wanted to clarify that all those myths and magic, that VPNs are "supposed to have" (or are advertising) are simple nonsense or points one should think about. Like Tom says in the video: if you're planning an assassination and need plausible deniability - sure I guess. But routing all traffic through a single choke point and handing all metadata to a single - if a bit shady - company on a silver plate isn't exactly what I'd assume you want with "sticking it to the man". It's a somehow similar discussion as using DNS forwarding (or DoH) and routing that all to e.g. Cloudflare. Encrypted, nice, but that pushes all (meta)data to the provider like Cloudflare, Google etc. That so much better? Hm. ;)

All other parts you asked were answered as far as I saw or were there points missing?

techtester-m

@JeGr said in Send DNS queries through a VPN tunnel:

that pushes all (meta)data to the provider like Cloudflare, Google etc. That so much better? Hm. ;)

Rather them with their Million other customers, than your local shitty ISP trust me.
I've served in the Intelligence force. ISPs shared info with us like whores...You had to show some credentials but still...
Good luck with extracting something from NordVPN :)

@JeGr said in Send DNS queries through a VPN tunnel:

All other parts you asked were answered as far as I saw or were there points missing?

The info is there but not in a way that I (new to pfsense) would know how to apply it...Sorry...

JeGr

@techtester-m said in Send DNS queries through a VPN tunnel:

Good luck with extracting something from NordVPN :)

That already happend So nothing new on that front. Especially as they were most agressive in their marketing. Everyone telling me they can survive as a company by selling a 80% discount on "lifetime" memberships and can still pay their bills with less and less revenue incoming? Nope, not buying ;)

@techtester-m said in Send DNS queries through a VPN tunnel:

The info is there but not in a way that I (new to pfsense) would know how to apply it...Sorry...

So where do you lack guidance at the moment? What info do you need exactly? That thread already has lots of info but I agree, some may be hidden to the pfsense-new eye :)

techtester-m

@JeGr said in Send DNS queries through a VPN tunnel:

That already happend So nothing new on that front

Not by hacking, exploiting or bad employee etc. lol...I meant an official org that demands data from them...Highly unlikely or so I'd like to believe at least hahaha...So what VPN provider would you suggest?

@JeGr said in Send DNS queries through a VPN tunnel:

So where do you lack guidance at the moment? What info do you need exactly? That thread already has lots of info but I agree, some may be hidden to the pfsense-new eye

Ok...thank you :) Give me a moment to sum up the points I want to understand better ok?

Edit: I'd like to understand these, please:

When there's only one pass rule for LAN or other interface, all traffic will pass through there (and tagged if set to), including all the DNS queries, right? Nothing hidden for DNS, it has to pass the same exact rules, tags, gateway etc. No rules at all = NOTHING - no DNS, no TCP/UDP etc....correct?
When we want to isolate a certain interface but still allow it access (only) to the Internet, we should add a Reject/Block rule for RFC1918 addresses and also add pass rules for TCP/UDP 53, 853 and maybe the same for NTP, correct?
In continuation to point 2 (above), if we have different pass rules for DNS/NTP and all the other traffic and we also want to pass the DNS/NTP via the VPN, we simply need to set its gateway to the VPN, policy routing it like all the other traffic, correct?
Rejecting/Blocking "This firewall (self)" is for preventing users from accessing the pfSense box, right?
If so, wouldn't that fall under the "RFC1918" rule anyway?

Suggestion: Would be super nice if pfSense had a graphic tool where you could see a drawing-like/animated visualization of all the traffic and where everything is going through/from/to etc. :)

JeGr

@techtester-m said in Send DNS queries through a VPN tunnel:

So what VPN provider would you suggest?

None, but as to why: watch the ~8min of video I posted above and make your own mind. I simply have no general use for a VPN. My DNS is encrypted and goes to my own service. No metadata for ISPs there. Mostly (more than 90%) of my traffic at home is encrypted anyways. Yes, one could extrapolate the IPs to have a guess as to what I'm surfing at. But that's it. Most comm is encrypted anyways. And if I fire up a VPN for one or two reasons, it's more likely geo restrictions or some other BS. :)

When there's only one pass rule for LAN or other interface, all traffic will pass through there (and tagged if set to), including all the DNS queries, right? Nothing hidden for DNS, it has to pass the same exact rules, tags, gateway etc. No rules at all = NOTHING - no DNS, no TCP/UDP etc....correct?

If you are talking about some normal interface LAN, OPT1 or such - then yes. If there are no rules, there's nothing going out. If you create a "* any to any *" rule, it is anything. If you force this any any rule out a certain gateway it should all go out this gateway.

Rejecting/Blocking "This firewall (self)" is for preventing users from accessing the pfSense box, right?
If so, wouldn't that fall under the "RFC1918" rule anyway?

Ah that depends. "This firewall (self)" sums up all addresses the firewall has, e.g. WAN, LAN, VPN side etc. so it's more then e.g. create a reject any to LAN_address on the LAN interface. In case of the later one you could always try to use the WAN address or VPN address in the browser and if allowed reach e.g. the WebUI through that. "This firewall" would match any IPs the firewall has now or will have in the future. Not only the address on a certain interface.

But rejecting all traffic to "this firewall" would also block clients from e.g. using DNS via the firewall's forwarder/resolver or using NTP etc. so it's a "do you need XY" kinda thing.

To your part about it being included in RFC1918 - that depends. A firewall can/could have a public IP on one of its interfaces (e.g. not using a router in front as WAN but using a modem and having the public IP directly attached to WAN). That way, a client could use https://<wan_ip> and access the webgui if you only blocked RFC1918.

techtester-m

@JeGr Ok...I think I understand what you're saying, but still have to ask - If not by "This firewall (self)" then how do you block certain users/IPs or even a whole interface from accessing the WebGUI of pfSense?

@JeGr said in Send DNS queries through a VPN tunnel:

watch the ~8min of video I posted above and make your own mind

I will.

@JeGr said in Send DNS queries through a VPN tunnel:

My DNS is encrypted and goes to my own service. No metadata for ISPs there

Could you elaborate more? How exactly do you achieve that? What kind of service do you have locally that would encrypt your traffic AND decrypt it somewhere after passing your ISP?

Thanks,

stephenw10

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

techtester-m

@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 :)

stephenw10

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

techtester-m

@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?

stephenw10

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

techtester-m

@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,

stephenw10

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

stephenw10

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

techtester-m

@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,

Decepticon

@techtester-m

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 -> LAN

Edit 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.