traffic (DNS) is using wrong output interface with OPENVPN.

[Rod_opnsense]

Hello all,

I want to use my opnsense firewall with openvpn and ensure that all trafic goes into tunnel for confidentiality.

Thanks to the NAT->Internet rule that sent traffic to the VPN gateway , the LAN initiated traffic is correcly tunnelised.
But i got an issue for DNS resolution of LAN computers. It 's sent to  firewall but the firewall  always use WAN if instead of VPN one.

I understood technical reason why one would tell that DNS should be sent to WAN, for example to solve the VPN server name before opening the tunnel. But let's forgot that and let's go only in the proof of concept (after all i can put IP of VPN server in opnsense conf.) that i want ALL traffic to be in tunnelised once it 's established (confidentiality)

My configuration is quite simple : A Lan, the opnsense box(v17.1.8-amd64), internet router. My DNS configuration is dns resolver activated on firewall. NAT computers use firewall IP for DNS.
paramter "Allow DNS server list to be overridden by DHCP/PPP on WAN " is unchecked.
parameter "Do not use the DNS Forwarder/Resolver as a DNS server for the firewall" is unchecked.
DNS servers paramter in "System/settings" are DNS from VPN provider and currently with parameter of the "use gateway" with VPN interface.

I tested a lot of configuration/parameter during well some long hours.
But it never worked as i would like, the logs show clearly DNS request using WAN interface and not VPN one.
I could put the the VPN DNS IP on the LAN computer network conf. instead of firewall IP. In that case dns traffic is correctly sent in tunnel. But i would prefer having dns on opnsense.

Can someone help for that?

Thanks !

[mimino]

The only solution to this I've found was to specify DNS servers in DHCP static mapping for devices that need to connect through VPN. Not sure if anything else is possible with DNS Resolver, without it I had no DNS traffic coming through at all.

[Rod_opnsense]

Thanks for the reply !
wow, i though this problem could be simple to solve with 1 click. Seems it's not the case.
If i add DNS leak question in this, my feeling is that it will need some time to have a good design / tuning for ensuring DNS is going only in th tunnel. I am working in lab for this but...let's try to focus only on DNS request out of the firewall.
I see this parameter "outgoing network interface" in DNS resolver parameter in pfsense.
Perhaps it's the parameter we need in opnsense (would be the VPN interface not the WAN interface in this web capture) ?

[mimino]

This would probably work if you wanted all devices to route through VPN.
My use case is a little different, I only need certain devices VPN'ed, so the DNS traffic has to route through both WAN and VPN. However, to enforce all traffic (including DNS) for those devices I used FW rules as described here:https://www.infotechwerx.com/blog/Prevent-Any-Traffic-VPN-Hosts-Egressing-WAN. DNS leak test came back negative, so I'm guessing it works as expected.

If you think about it, it all makes sense. You're ignoring the settings OpenVPN server provides you with, so you're responsible for setting up the routes yourself. This includes DNS settings. DNS Resolver cannot respond to DNS queries from devices connected to VPN, so you have to manage these as well. That's at least how I picture things in my head. I'm not a networking expert, just trying to explain things to myself

[Rod_opnsense]

Thanks for reply and links.
Very interesting reading.There is 2 elements important i can summarized:

- First that we can not trust the security when it comes to policy based routing because "if the VPN tunnel is down, by default pfSense deletes the gateway from the rule which will cause the traffic to be routed according to the routing table"

-Second.The solution (workaround ?) suggested seems nice : Tag the packet on LAN sides and check them on WAN side  to delete them if they go there (instead of VPN) because of ...any reason (like this fucking bad mechanism explained before)

I would add that the solution seens good for ensuring all trafic from lan goes into tunnel. But this would not enough when it comes to DNS leacks. There is for example the risk that we must protect from that is when your software use another DNS that the one configured on OS. For example Chrome/ium can sometine used google public DNS. You believe that ? Make some test with capturing packet or log with your xxsense you will see. Sending my navigation to google (even throug an VPN,lol) is not what i planned when i bought a VPN for confidentiality. So my suggestion to protect from that is quite simple. Adding 2 rules BEFORE the rule from NAT to Internet through VPN gateway.
1st  with src:LAN dest:your DNS server/VPN DNS/your firewall (depending on your architecture) port:dns/53 action:accept, through the VPN gateway (and tag like explained before)
2nd with src:LAN dst:Any port:dns/53 action:drop.
So DNS traffic not desired will not be sent in your tunnel.
Ah and also change browser.

[mimino]

I don't think such a risk exists in this configuration. FW enforces ALL traffic through the tunnel and NO traffic through WAN. So even if your OS/browser overrides the DNS settings, to reach DNS server it still has to go through firewall (and tunnel), no way around that.

[Rod_opnsense]

Hello,
Yes you are right,
but

Risk of DNS leacks is that your private information (browsing) is sent to someone you don't want.
That being said there is quite a different risk:
- DNS request sent directly to the WAN. The operation said before protect of that.
- DNS request intercepted on internet and sent to DNS you don't want. Some (rare) internet provider do that (https://www.dnsleaktest.com/what-is-transparent-dns-proxy.html). Only current protection i see is ....confidence I have in my DNS provider. I don't like that but i don't see other way to protect (?)
- DNS request sent to another DNS provider because of internal coding of DNS in sofware. That is what i want to prevent with the 2 new rules. Otherwise the DNS request is sent to tunnel and finaly goes to ...google DNS in this case (but could be a hacker dns or a state dns...) . one could said, ok this is right but google DNS receive your information through IP of VPN so no way to connect to your identity. That's true for IP. But due to various technics that are currently use widely on internet (fingerprint...) this add a risk to finaly have confidentiality issue. We could also take the issue in the other side : What is your benefit to use a DNS you don't want ? Nothing for me. Or at least functionnality (DNS fail over officialy ?) i don't want compare to confidentiality risk. So i block it. This is some kind of security "best practice" like when don't open ports we don't need on firewalls...