386.3_2 VPN Leak? How to ensure that all traffic on a device goes through VPN as soon as it connects?

[Lukium]

First of all, I want to thank everyone for all the great work on Asus-Merlin. I've been using it for years.

Here's the scenario I'm dealing with:

My router (GT-AX11000 running 386.3_2) is connected to Verizon WAN, and every time I reboot the router, I end up with a new IP address. This used to be fine until I added a device to the network that needs to have an IP that's not constantly changing. Long story short, DDNS and other similar solutions aren't an option. So I went ahead and setup a VPN server on Azure, and connected the router to the VPN using OpenVPN with the VPN Director option enabled so that not all traffic goes through the VPN (only want this specific device to have a dedicated IP). The device in question has a static IP setup on the router to 192.168.1.166, so I went ahead and setup VPN director to have all traffic to 192.168.1.166 to go through the VPN. Furthermore, all relevant traffic on this device happens on port 44158, so I added a simple script to jffs/scripts/ that's triggered by openvpn-event to forward the port through the VPN to the correct device. The command used is:

iptables -t nat -A PREROUTING -i tun+ -p tcp --dport 44158 -j DNAT --to-destination 192.168.1.166:44158

For the most part, the setup works great. After the device connects and boots, I can run a port checker to the VPN's Public IP and port 44158, and I get an open port, which is exactly what is necessary.

Here's the issue:

When the device first connects, it announces to the network it's on what its IP address is. Somehow, it's announcing the Verizon Public IP, instead of the Azure Public IP, which is leading me to believe that for some amount of time during boot it is exposed to the WAN IP instead of the VPN IP. Is there a way to ensure that this does not happen?

-----------------------------------------
EDIT:
I did a few more tests, here's some more relevant info:

Even if I set all traffic to go through the VPN, somehow the device is being exposed to the WAN IP and announcing it on its network.
------------------------------------------

Thanks,

Luke

 

[eibgrad]

VPN Kill Switch Doesn't Work Temporarily Immediately After Rebooting

I'm running Merlin 386.3_2 on an RT-AC68U. I'm using the OpenVPN client with it set to connect when booted. The kill switch is enabled, and all internet traffic is set to be redirected over the VPN. I've noticed that traffic is allowed to go over the WAN immediately after rebooting for a short...

www.snbforums.com

 

[Lukium]

VPN Kill Switch Doesn't Work Temporarily Immediately After Rebooting

I'm running Merlin 386.3_2 on an RT-AC68U. I'm using the OpenVPN client with it set to connect when booted. The kill switch is enabled, and all internet traffic is set to be redirected over the VPN. I've noticed that traffic is allowed to go over the WAN immediately after rebooting for a short...

www.snbforums.com

Hi eibgrad,

Just to make sure that I'm understanding this right, and that it applies to what I'm experiencing:

In my case, neither the router or VPN are being turned off or back on. In this case, it's the connected device in question that seems to be exposed to the WAN while it's booting up. Do you think that this is the same thing? I apologize if this seems like an obvious question, but there are definitely a lot of this that I'm new to.

Thanks again,

Luke

 

[eibgrad]

During router bootup, there is a known issue w/ the WAN being exposed for a brief period when using "Yes (all)" for your routing policy. But the OP in that other thread indicated he was NOT having a problem when using the VPN Director and policy rules. However, there have been reports of "leakage" by other users even when using the VPN Director. I have had trouble reproducing those same situations, but I have to assume that such reports are accurate. I can only reproduce this behavior reliably in the case of the "Yes (all)" routing policy.

 

[Lukium]

During router bootup, there is a known issue w/ the WAN being exposed for a brief period when using "Yes (all)" for your routing policy. But the OP in that other thread indicated he was NOT having a problem when using the VPN Director and policy rules. However, there have been reports of "leakage" by other users even when using the VPN Director. I have had trouble reproducing those same situations, but I have to assume that such reports are accurate. I can only reproduce this behavior reliably in the case of the "Yes (all)" routing policy.

I think I understand. But in this Scenario, both the router/VPN have already been up and running for 10+ minutes. Then when I turn the connected device on, it still seems to be temporarily exposed to the WAN. I feel like the events are occurring in the following order:

1. Router/VPN are turned on, everything is running fine

2. Connected device is turned on and starts booting.

3. During boot process, device checks its public IP address (ends up getting the WAN IP because it's not yet behind the VPN), stores it to announce once fully booted.

4. Router puts the device behind the VPN

5. Device finishes booting, is now correctly listening for connections on the VPN

6. Device announces the WAN IP to the network.

7. Other devices on the network fail to connect to the device, because while the device is correctly listening through the VPN, it was exposed the the WAN when it got its public IP.

Thanks,

Luke

 

[eibgrad]

I understand how it might *feel* like step 3 is preceding step 4, but I don't see how that could be. If the router is up and connected (esp. for 10+ minutes), then the VPN Director rules should be in effect, which is presumably *before* the device comes up. And as long as the kill switch is enabled, I have no idea how its public IP could be anything other than that of the VPN. That's the whole point of using routing policy and the kill switch.

I assume you're autostarting the OpenVPN client on bootup, correct?

 

[Lukium]

I understand how it might *feel* like step 3 is preceding step 4, but I don't see how that could be. If the router is up and connected (esp. for 10+ minutes), then the VPN Director rules should be in effect, which is presumably *before* the device comes up. And as long as the kill switch is enabled, I have no idea how its public IP could be anything other than that of the VPN. That's the whole point of using routing policy and the kill switch.

I assume you're autostarting the OpenVPN client on bootup, correct?

Yes, so far I have been auto-starting the OpenVPN client on bootup, but I just now re-did the whole process without auto-starting the VPN. Here are the steps I followed:

Turned off the Device that needs to be in the VPN
Rebooted the router at 15:27 EST
Reboot completed at 15:29 EST
Waited until 15:35 EST to enable the VPN
Enabled the VPN, I can see that the VPN is connected, up and running.
Waited until 15:40 to turn the device back on
15:43 - Device is fully booted, issue persists.

The same observed behavior happened, i.e., after fully booting the device can be reached via the VPN IP, not the WAN IP, but the IP announced to the network is the WAN IP, which the device must have been exposed to, and once fully booted. Also note that every time I reboot I get a new IP from my ISP, so it's impossible for the device to have known the IP without the router exposing the device to it.



Below are the settings being used:

 

[eibgrad]

At this point, I'm just guessing. Because everything I see so far seems correct. There are no obvious errors.

All I can think is *maybe* the device is NOT getting the public IP from the VPN, but some other local source. Do you know for *certain* it's making an internet request (http/https) for that information? Maybe it's using some other local source, like UPnP.

 

[Lukium]

At this point, I'm just guessing. Because everything I see so far seems correct. There are no obvious errors.

All I can think is *maybe* the device is NOT getting the public IP from the VPN, but some other local source. Do you know for *certain* it's making an internet request (http/https) for that information? Maybe it's using some other local source, like UPnP.

I just tried turning off UPNP, same results. Is there anything else that can be turned off that might be available to the device to get the WAN IP? Though more importantly, if a device is set to be behind the VPN, shouldn't the router know not to give the WAN IP to the device under no circumstances?

Thanks,

Luke

 

[eibgrad]

I just tried turning off UPNP, same results. Is there anything else that can be turned off that might be available to the device to get the WAN IP? Though more importantly, if a device is set to be behind the VPN, shouldn't the router know not to give the WAN IP to the device under no circumstances?

Depends on the circumstances. UPnP was just a guess. I figured that if that was enabled, *maybe* it was a source for the WAN ip, since it's the WAN that's getting reconfgured w/ port forwarding. After all, if the device is allowed to open ports on the WAN, the fact it might also be the source of the WAN ip seems trivial in comparison.

 

[eibgrad]

Try changing "Accept DNS configuration" from Relaxed to Exclusive.

 

[Lukium]

Try changing "Accept DNS configuration" from Relaxed to Exclusive.

Just tried it, still same thing.

Here's something interesting though, I just had another similar - though from a different manufacturer - device delivered, and upon swapping the new device for the other one in the network, the new device is announcing the VPN address. So now I'm starting to think that the original device is doing something unusual, to try and get the WAN IP by any means necessary, though ultimately, I think that the router shouldn't be giving the WAN IP. I think I'm gonna give up on it for today, maybe a good night's sleep will give me some fresh ideas.

Thanks for all the help so far, I really appreciate it, especially considering I'm brand new here.

 

[SunSkyPi]

I have been having a similar issue with some leak occurring in VPN Client mode. I am using AC68U and AC86U with Merlin 386.3.2. To check my IP when router VPN client is on, I use a variety of ip checking tools, but have mostly relied on https://nordvpn.com/ip-lookup/ Other IP checking tools I use for example, are https://www.dnsleaktest.com/ DNS leak test (as it also gives IP) or just googling “whats mp IP address” and get google’s response, or other IP checkers like https://whatismyipaddress.com/ to cross check. What is interesting is that many times only the Nord IP check detects the leak when no other tools do.

On my ddwrt’s, and on PC/Chromebook's running OpenVPN etc., when I turn VPN Client on, the IP address reflects the VPN Server consistently and instantly after the VPN connection is established. When I turn it off (if no kill switch currently active) it switches right back to WAN. This has been solid, consistent behavior, never delays on switching or any leaks, rock solid in all my testing.

What is odd, when I do testing with 386.3.2 Merlin’s, when turn VPN client on, I observe these issues:

1. Most of time WAN IP never goes away when checking IP with Nord only, or Nord only ip check switches to VPN Server IP after a really long time (+15min), but other IP checking tools report switching right away.
   • other IP checking tools will say the IP address has changed to the VPN Server, but yet the https://nordvpn.com/ip-lookup/ will still be reporting the WAN, and sometimes will never report the VPN Server IP. Sometimes, after 15 minutes or longer the nord check will eventually report the VPN Server IP.
   • Even https://www.dnsleaktest.com/ shows the correct VPN Server IP, and leak test is fine (only VPN Server DNS--I have DNS Servers set to Exclusive so that is working fine), but Nord still reporting WAN.
2. If Nord IP checker happens to report the correct VPN Server IP, then when turn VPN Client off, the IP check instantly and consistently falls back and reports WAN (provided no kill switches are active). All the other IP checking tools also consistently report WAN after client is turned off. So, it is weird that when turn client OFF behavior seems consistent and instant, but laggy or buggy or not working at all (at least for Nord) when turning client ON?
3. However, If VPN Client is set to autoboot, everything works fine the first time client is on. As soon as VPN Client connection is established, all IP checking tools including Nord will report the correct VPN Server IP. This is case on both AC68U (no kill switch script) and AC86U (with recent kill switch script--which is working excellently by the way!).
   • In auto boot case, the VPN Client works, all IP checks are good, and then when turn off, all IP check tools report the WAN IP, all good. But now, if turn VPN Client back ON, have same failure as before, in issue #1 above.
4. On AC86U, with ks script activated, with at least one VPN Client set to auto boot, all VPN Clients work fine: when turning VPN clients on or off (off which ks activates so no WAN), switching to different VPN Clients, all IP check tools report instant and consistent new IP of different VPN Servers. If no VPN clients set to auto boot, then have issue #1.

So it seems IP leak depends on some type of interaction between a VPN Client set to auto boot start, and the ks script.

Questions:

1) Somehow the Nord IP checking tool is detecting a leak from the Merlin routers, and yet no other IP checking tool or DNS leak test is. What is special about how Nord is detecting IP? (Edit: sometimes the DNS leak test would also report the WAN.)

I validate the Nord IP check is working fine, as verified when turn VPN Client on, on all other non Merlin devices, OpenVPN apps on ddwrt routers, PC/Chromebooks, etc., the IP address switches instantly and consistently without fail.

2) Why when turning VPN Client OFF all IP check tools work instantly and consistently (reporting WAN) but not when turning ON? When turning on, Nord will still usually report the WAN IP.

3) Why would having a VPN Client auto start on boot make everything work fine (at least the first on/off cycle)?

4) Does having the new kill switch script protect the WAN from ever being exposed? But in the case where no clients are set to auto boot, get same issue #1.

Current workaround:
At least with the ks script running, and having at least one VPN client set to auto boot, I can protect the WAN from being exposed. I can switch to different VPN clients, turn on/off, and all the IP check tools work instantly and consistently as expected reporting the correct IP.

Thank you for any help, ideas or suggestions.

 

[Lukium]

Just an update on this issue.

I pretty much gave up and built my own router using Raspberry Pi. Problem solved.

 

[eibgrad]

Obviously those sites correctly reporting your OpenVPN public IP and NordVPN reporting your WAN ip can't both be right. And given NordVPN is the exception, it's clear (to me anyway) you can't fully trust the results. Whenever you're depending on a remote site to tell your public IP or detect a DNS leak, there's no guarantee this will always be accurate. You only *assume* you know what the server is doing. There's always the risk of a reverse proxy by the OpenVPN provider, or even an ISP placing a proxy between you and certain websites. Even the browser's own cache could distort the results.

So don't become obsessed with why one site is returning oddball results. As I said, given it's the exception, I'd be far less concerned about it.

Now thinking about this for bit, I do have a guess as to why *maybe* you're seeing these strange results from NordVPN.

Once the router gets connected to the OpenVPN server, it creates a static route for the server's IP and binds it to the WAN (as illustrated below w/ my own VPN provider (and it's NOT NordVPN). The first line is the server IP, 162.218.229.106, being bound to the WAN (vlan2)).

admin@lab-merlin1:/tmp/home/root# ip route show table ovpnc1
162.218.229.106 via 192.168.63.1 dev vlan2
10.200.0.1 via 10.200.0.33 dev tun11
10.200.0.33 dev tun11  proto kernel  scope link  src 10.200.0.34
192.168.63.1 dev vlan2  proto kernel  scope link
192.168.101.0/24 dev br1  proto kernel  scope link  src 192.168.101.1
192.168.102.0/24 dev br2  proto kernel  scope link  src 192.168.102.1
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
192.168.63.0/24 dev vlan2  proto kernel  scope link  src 192.168.63.102
192.168.61.0/24 via 192.168.63.1 dev vlan2  metric 1
127.0.0.0/8 dev lo  scope link
default via 10.200.0.33 dev tun11

It has to do this in order to prevent the control channel from being routed through the tunnel.

By coincidence, it's possible the website for the NordVPN IP checker and the OpenVPN server are running on the same machine. Or at least sometimes that's the case (maybe the website and/or OpenVPN server are getting different IPs from DNS as it round-robin's the multiple IPs associated w/ those domain names, and every once in a while they end up being the same). If that happens, you will necessarily access the NordVPN IP checker over the WAN!

To say that's highly speculative is an understatement. But it illustrates how sometimes things are not necessarily working as you expect. That's the sort of oddball situation most ppl would easily miss. But I can at least imagine it being a possibility. It would be incredibly stupid for NordVPN to let that happen, but I've seen stranger things by OpenVPN providers over the years.

Of course, this doesn't explain why you see different results w/ autoboot enabled vs. disabled. But I don't know how many times you tested it, and whether you can rightly claim it's 100% consistent. Over 2-3 tests, it's possible you're assuming you've established a predicable pattern that might not necessarily be the case.

I believe the above addresses questions 1, 2, and 3.

4) Does having the new kill switch script protect the WAN from ever being exposed? But in the case where no clients are set to auto boot, get same issue #1.

The advantage of using the firewall for the kill switch is that it runs completely independent of the VPNs, and is established in conjunction w/ the WAN. In theory, that means the firewall should be established before the WAN is even available, never mind any VPNs that get established later. So that's the best you can do.

 

[SunSkyPi]

Thanks so much for the info @eibgrad!

I should have added the VPN Server I am using is a private one, not associated with Nord at all. I have just been using the Nord ip checker as one of main sources to check ip, b/c no ads and has always seemed responsive and accurate as far as I can tell. I just get uncomfortable if any ip checker reveals the WAN. Other than the merlin routers, on all other instances of OpenVPN (ddwrt's PC's etc.) Nord and all other ip testing report the same, so I am still thinking there is something going on with merlins that exposes the WAN, and for some reason only Nord really detects it (although I have noticed a few times that DNS leaktest will also detect it).

This is where I take solace in your firewall ks script--no leaks, thank you again! And long as I do the workaround of having at least one VPN client autoboot (which I think activates the ks script at all times), this keeps the merlin routers from exposing the WAN at all. Granted I can't access the WAN without setting all cilents not to autoboot, but that is small price to pay for safety, and since the intent is to always be operating as VPN client not an issue in my application.

Thank you again!

 

[SunSkyPi]

Just an update on this issue.

I pretty much gave up and built my own router using Raspberry Pi. Problem solved.

Lukium, could you please share how you are building a router with the Raspberry Pi? Hardware and software specs. Have you been able to successfully lock down the WAN with no leaks?

Thank you