Messages

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

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.

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

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 !