What's new

Possible VPN Issue

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Bill S

New Around Here
I have a RT-AC86U running the latest merlin version. there has been a change in the VPN operation that I am concerned might indicate a leak and/or problem with my setup and/or openvpn.

I have a Sagecom 2864 modem running as a router and its own private network of 192.168.2.x. The merlin router is connected to this and gets IP 192.168.2.11, the firewall is enabled. On the merlin side the private lan is 192.168.1.x. I have a few computer IP addresses on 192.168.1.x lan redirected onto VPN via merlin. Ipleak site shows the appropriate IP address corresponding to the VPN. The problem is that I can also access the 192.168.2.x net of the modem. I didn't use to be able to do that, and I think that I shouldn't since it is outside the merlin firewall and technically is a "public" ip as far as asusmerlin knows.

Really the only thing that has changed in my setup is the merlin version being upgrade along the way, since 192.168.2.x was not accessible and it now being accessible by re-directed VPN clients.

I have VPNMGR and VPNdirector running, but that has been always the case I believe since before this issue started.

should I be worried?
 
This is the same on my router. I can't remember if it's always been that way. My guess is that this might have changed when they implemented static routes for the WAN DNS servers to bypass the VPN client. To do this the routing table needs to know how to get to the "normal" WAN gateway network, which in your case is 192.168.2.x.

This isn't really a problem IMHO (unless you're trying to block access to 192.168.2.x) as anything upstream of the 192.168.2.x network is still unreachable apart from the WAN DNS servers.
 
This is the same on my router. I can't remember if it's always been that way. My guess is that this might have changed when they implemented static routes for the WAN DNS servers to bypass the VPN client. To do this the routing table needs to know how to get to the "normal" WAN gateway network, which in your case is 192.168.2.x.

This isn't really a problem IMHO (unless you're trying to block access to 192.168.2.x) as anything upstream of the 192.168.2.x network is still unreachable apart from the WAN DNS servers.
thanks i'm suspecting something along that lines too, but I just want to be sure I don't have issue that is causing leaks.
 
Let's be precise here when it comes to exactly what it means to use selective routing, be it the VPN Director or Yes (all).

The use of selective routing does NOT mean the WAN is blocked in favor of the VPN. What it does is change the default gateway from that of the WAN, to that of the VPN. And the default gateway's only purpose is to provide a route for those situations where there is NOT a known route to a given destination. Typically, this is the internet. But if you have static routes to specific destinations over the WAN, then they become accessible because they are NOT dependent on the default gateway.

The same holds true for any *private* IP network that exists immediately upstream of the router, such as 192.168.2.0/24 in your case. This route is KNOWN. It's in the router's routing table. There is no need to use the default gateway in order to reach it. And therefore should be reachable.

All that said, prior to the VPN Director, we had options for selective routing based on Strict and non Strict. It's been too long now for me to remember precisely what Strict did, but as I recall, it would strip out any static routes defined on the WAN. But I don't recall if that also removed any routes to the immediate private network upstream of the WAN (such as in your situation). But if it did, perhaps that might explain the difference.

Regardless, I don't see having access to the immediately upstream private IP network being an issue. Seems to me you would want to continue having such access, even if the killswitch was invoked due to failure of the VPN. Access of that local IP network does NOT represent a threat since it remains local.
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top