DNS Leaks on VPN Fusion (AC RT5300)

[teddylabs]

Hi
Beem testing on two different providers (Nord, Express) and seem to be getting DNS leaks. It appears that I am connected to the correct server when checking my IP, and speedtests reflect that I am connecting to a server in that city. Yet the troubleshooting steps confirm that there is an issue with my connection. I have a couple of questions:

1. I have only used vpn fusion to assign VPN servers to specific devices; does anything need to be done in the regular VPN settings area ? When i download config files and assign to a device check marks appear and everything appears perfect...

2. The config files that i download from providers; do they need any editing beyond what the VPN provider is giving me? I see a box for that purpose but no idea what it means, something about a certificate?

3. I have been downloading Open VPN files for this router- is that correct?

4. Should i try to work backwards and blanket the house with VPN coverage and make exceptions for devices i do not wish to be connected? would this make a difference?

5. Are there any settings on the router that could ensure DNS is secure, beyond the WAN entry of the providers informatoin and addresses they gave me

 

[eibgrad]

I should say up front, I don't use VPN Fusion, and until I recently researched it, I didn't even know what it was or what it did. But it *appears* to be nothing more than an implementation of PBR (policy based routing), where you can control which devices do and don't use the VPN (normally, *all* traffic is sent over the VPN).

The problem w/ many (perhaps most) implementations of PBR is that in order to make it work, it requires taking the router itself off the VPN and back to the WAN. And if you're using the router's DNS proxy (DNSMasq) to access public DNS servers (which is typically the default configuration), there's a good chance you'll end up w/ a DNS leak, particularly if the DNS servers pushed by the VPN provider are public IPs (as opposed to IPs in the private space of the tunnel). This has always been a major complaint of mine when it comes to PBR. I doubt most ppl who use PBR are even aware of this potential problem.

One means to combat the problem is to explicitly bind the VPN provider's DNS server(s) to the VPN using the route directive.

route 8.8.8.8
route 1.1.1.1

Of course, this assumes you know which IPs the VPN provider is going to push. There isn't even a guarantee that the OpenVPN client will necessarily process the pushed DNS servers. You may have to define your own static DNS entries on the WAN (e.g., 8.8.8.8 and 1.1.1.1.), then bind those DNS servers using route directives in the OpenVPN client.

One final caveat. Sometimes PBR is implemented using a directive called route-noexec. And if that's the case, any route directives specified in the OpenVPN config file are ignored! Let's hope that's not the case.

 

[teddylabs]

I should say up front, I don't use VPN Fusion, and until I recently researched it, I didn't even know what it was or what it did. But it *appears* to be nothing more than an implementation of PBR (policy based routing), where you can control which devices do and don't use the VPN (normally, *all* traffic is sent over the VPN).

The problem w/ many (perhaps most) implementations of PBR is that in order to make it work, it requires taking the router itself off the VPN and back to the WAN. And if you're using the router's DNS proxy (DNSMasq) to access public DNS servers (which is typically the default configuration), there's a good chance you'll end up w/ a DNS leak, particularly if the DNS servers pushed by the VPN provider are public IPs (as opposed to IPs in the private space of the tunnel). This has always been a major complaint of mine when it comes to PBR. I doubt most ppl who use PBR are even aware of this potential problem.

One means to combat the problem is to explicitly bind the VPN provider's DNS server(s) to the VPN using the route directive.

route 8.8.8.8
route 1.1.1.1

Of course, this assumes you know which IPs the VPN provider is going to push. There isn't even a guarantee that the OpenVPN client will necessarily process the pushed DNS servers. You may have to define your own static DNS entries on the WAN (e.g., 8.8.8.8 and 1.1.1.1.), then bind those DNS servers using route directives in the OpenVPN client.

One final caveat. Sometimes PBR is implemented using a directive called route-noexec. And if that's the case, any route directives specified in the OpenVPN config file are ignored! Let's hope that's not the case.

Thanks for your response. I have since changrd dns settings at router level to those given to me by the provider. Daily checks seem to confirm all is well. The uncertainties you mentioned are unsettling however. No kill switch for DNS leaks ....does such a thing exist?

 

[eibgrad]

The uncertainties you mentioned are unsettling however. No kill switch for DNS leaks ....does such a thing exist?

A typical kill switch does NOT block the router itself from accessing the WAN, only the local network devices behind it. And it has to be this way since the router needs access to the WAN to support other services (the OpenVPN client to server connection, DHCP renewal w/ the ISP, port forwarding, etc.).

Where the problem comes in is when those local network devices are using the router as a DNS proxy (DNSMasq). It is *very* common to have the DHCP server configure the local devices w/ the router's LAN ip as their DNS server (dumping the local ip config on the client will reveal whether this is the case). That DNS proxy then accesses various public IPs on the behalf of those clients. When you're NOT using PBR (policy based routing), it's a non-issue. The router's DNS proxy will access those public DNS servers over the VPN out of necessity. But since most PBR implementations take the router off the VPN, *now* you have the potential for a DNS leak. The DNS proxy may very well access those same public DNS servers over the WAN! Whether or not that actually happens depends on many other factors, which are too numerous to detail at the moment. And if you're using OEM firmware, I have no clue how that particular firmware deals w/ this problem (if at all; it may just punt and leave you w/ DNS leak).

That's why when I researched VPN Fusion and you reported a DNS leak, that's the first thing that came to mind. It wouldn't surprise me in the least that some OEM PBR implementation left you w/ a DNS leak. Manufacturers typically don't care. They just want to sell you on the fact that you can bypass the VPN for certain circumstances, like gaming, and place a bullet-item on the box proclaiming this wonderful new feature.

The only way I know to be sure that you don't have a DNS leak when using any kind of PBR is to NOT depend on the router's DNS proxy for DNS support, but instead assign public DNS servers (via DHCP) directly to the clients. But whether that's possible w/ OEM firmware is an open question. For reasons of simplicity, OEM firmware often limits your options. But using third-party firmware, that's a common feature.

 

[RedeyeAce]

A typical kill switch does NOT block the router itself from accessing the WAN, only the local network devices behind it. And it has to be this way since the router needs access to the WAN to support other services (the OpenVPN client to server connection, DHCP renewal w/ the ISP, port forwarding, etc.).

Where the problem comes in is when those local network devices are using the router as a DNS proxy (DNSMasq). It is *very* common to have the DHCP server configure the local devices w/ the router's LAN ip as their DNS server (dumping the local ip config on the client will reveal whether this is the case). That DNS proxy then accesses various public IPs on the behalf of those clients. When you're NOT using PBR (policy based routing), it's a non-issue. The router's DNS proxy will access those public DNS servers over the VPN out of necessity. But since most PBR implementations take the router off the VPN, *now* you have the potential for a DNS leak. The DNS proxy may very well access those same public DNS servers over the WAN! Whether or not that actually happens depends on many other factors, which are too numerous to detail at the moment. And if you're using OEM firmware, I have no clue how that particular firmware deals w/ this problem (if at all; it may just punt and leave you w/ DNS leak).

That's why when I researched VPN Fusion and you reported a DNS leak, that's the first thing that came to mind. It wouldn't surprise me in the least that some OEM PBR implementation left you w/ a DNS leak. Manufacturers typically don't care. They just want to sell you on the fact that you can bypass the VPN for certain circumstances, like gaming, and place a bullet-item on the box proclaiming this wonderful new feature.

The only way I know to be sure that you don't have a DNS leak when using any kind of PBR is to NOT depend on the router's DNS proxy for DNS support, but instead assign public DNS servers (via DHCP) directly to the clients. But whether that's possible w/ OEM firmware is an open question. For reasons of simplicity, OEM firmware often limits your options. But using third-party firmware, that's a common feature.

[QUOTE="eibgrad, post: 506239, member: 52181"QUOTE]

I think this is precisely hitting the nail on the head with where my head is at. It's been around 10 years since I've touched networking or a winblows box though...

So for the dns leak issues with vpn fusion on Asus Ax11000. Is the horrible workaround:
Find VPN supplier with local DNS
Set LAN, DHCP SERVER, DNS to their DNS Server 1.

Keep the custom DNS in WAN, but realise they're never going to be used.

Realise that you've just lost the router proxy dns. Bye bye speed advantage on caching prior requests.

However and hopefully, yay to fixing DNS leaks via VPN fusion on stock Asus firmware ?