What's new

VPN Director not applying rules to right VPN profile

  • 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!

TheSNAKE

New Around Here
Hi,

I'm running into a routing issue when configuring multiple VPN profiles using VPN Director on my LINKSYS (base model: RT-AC68U) firmware version 386.3_2.

I have 2 VPN profiles with the following external addresses:
OVPN1) Connected (Local: 10.16.0.43 - Public: 185.240.246.99)
OVPN3) Connected (Local: 10.16.0.25 - Public: 89.46.223.251)

In VPN Director I have configured:
- OVPN1: Fastest VPN - US
- OVPN3: Fastest VPN - NL2

- Enabled Roblox 128.116.0.0/17 OVPN1
- Enabled Kodi 192.168.1.231 OVPN3
- Enabled PC1 192.168.1.203 OVPN3

When I check PC1's external address is is showing 185.240.246.99 and not 89.46.223.251 as it supposed to.

Any help would be appreciated.

Thanks!
 
Hi,

I'm running into a routing issue when configuring multiple VPN profiles using VPN Director on my LINKSYS (base model: RT-AC68U) firmware version 386.3_2.

I have 2 VPN profiles with the following external addresses:
OVPN1) Connected (Local: 10.16.0.43 - Public: 185.240.246.99)
OVPN3) Connected (Local: 10.16.0.25 - Public: 89.46.223.251)

In VPN Director I have configured:
- OVPN1: Fastest VPN - US
- OVPN3: Fastest VPN - NL2

- Enabled Roblox 128.116.0.0/17 OVPN1
- Enabled Kodi 192.168.1.231 OVPN3
- Enabled PC1 192.168.1.203 OVPN3

When I check PC1's external address is is showing 185.240.246.99 and not 89.46.223.251 as it supposed to.

Any help would be appreciated.

Thanks!
It seems both your VPN client have the same local 10.16.0.0 subnet. If you want to have two different VPN sessions from the same provider perhaps can try use one as UDP and the other as TCP. Depends on your VPN provider, you could get local IP with different subnet.
 
Under normal circumstances, where the OP reported using the Merlin software on an unsupported platform (I'm not even sure that's the case, frankly), I would NOT reply. But I'm going to make a rare exception in this case because it's a good opportunity to identify a bug in how the router appears to be mishandling the default gateway w/ the VPN Director.

The problem here is that the OP is using the same OpenVPN provider for each OpenVPN client. And as often happens, that can lead to routing ambiguity when more than one tunnel is using the same IP network (e.g., 10.16.0.0/255.255.0.0).

In this case, I believe FastestVPN is using a subnet topology and the same gateway IP (10.16.0.1). What ends up happening is the ovpnc1 and ovpnc3 routing tables are *both* pointing to the same network interface (either tun11 or tun13, just depends which gets established first) when establishing 10.16.0.1 as the default gateway, when normally each would be pointing to its own unique gateway IP on its respective tunnel (tun11 and tun13). But the routing system gets confused because of the network overlap.

All that said, w/ the new VPN Director, this shouldn't matter anymore, provided the router includes the tunnel's network interface when creating the default route for each table.

IOW, presently, the router seems to be using the following command for adding the default route to these tables.

Code:
ip route add default via 10.16.0.1 table ovpnc1
ip route add default via 10.16.0.1 table ovpnc3

… when it should really include the network interface as well.

Code:
ip route add default via 10.16.0.1 dev tun11 table ovpnc1
ip route add default via 10.16.0.1 dev tun13 table ovpnc3

NOW it doesn't matter that the tunnels overlap, since each is managed separately, within its own routing table. But failing to include the network interface means the routing system is left to determine which network interface is relevant. And as such, it's defaulting to the one that established a route to 10.16.0.1 first, either opvnc1 or ovpnc3, for both tables. If you dump the respective tables, you'll see what I mean.

Code:
ip route show table ovpnc1
ip route show table ovpnc3


In my own case, I'm using ovpnc2 and ovpnc3, but the effects are the same. Each table points to 10.16.0.1 on the tun12 network interface.

Code:
admin@lab-merlin1:/tmp/home/root# ip route show table ovpnc2
185.240.246.99 via 192.168.63.1 dev vlan2
192.168.63.1 dev vlan2  proto kernel  scope link
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
10.16.0.0/16 dev tun12  proto kernel  scope link  src 10.16.0.24
127.0.0.0/8 dev lo  scope link
default via 10.16.0.1 dev tun12

admin@lab-merlin1:/tmp/home/root# ip route show table ovpnc3
185.240.246.99 via 192.168.63.1 dev vlan2
192.168.63.1 dev vlan2  proto kernel  scope link
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
10.16.0.0/16 dev tun12  proto kernel  scope link  src 10.16.0.24
127.0.0.0/8 dev lo  scope link
default via 10.16.0.1 dev tun12 # WRONG!!  Should be tun13

But if you manually replace the errant default route in ovpnc3 w/ the proper network interface, things will start working correctly.

Code:
ip route rep default via 10.16.0.1 dev tun13 table ovpnc3

Again, I'm only mentioning it in this thread because it's the best opportunity to explain the problem w/ the VPN Director and how to correct it. The VPN Director, if it handles this properly, can eliminate these IP tunnel overlaps *provided* it includes the network interface when adding the default route to the ovpncx tables. At present, it doesn't seem to be doing so.
 
Specifying the interface name in the default route might possibly be doable, it will require further investigation.
 
Under normal circumstances, where the OP reported using the Merlin software on an unsupported platform (I'm not even sure that's the case, frankly), I would NOT reply. But I'm going to make a rare exception in this case because it's a good opportunity to identify a bug in how the router appears to be mishandling the default gateway w/ the VPN Director.

The problem here is that the OP is using the same OpenVPN provider for each OpenVPN client. And as often happens, that can lead to routing ambiguity when more than one tunnel is using the same IP network (e.g., 10.16.0.0/255.255.0.0).

In this case, I believe FastestVPN is using a subnet topology and the same gateway IP (10.16.0.1). What ends up happening is the ovpnc1 and ovpnc3 routing tables are *both* pointing to the same network interface (either tun11 or tun13, just depends which gets established first) when establishing 10.16.0.1 as the default gateway, when normally each would be pointing to its own unique gateway IP on its respective tunnel (tun11 and tun13). But the routing system gets confused because of the network overlap.

All that said, w/ the new VPN Director, this shouldn't matter anymore, provided the router includes the tunnel's network interface when creating the default route for each table.

IOW, presently, the router seems to be using the following command for adding the default route to these tables.

Code:
ip route add default via 10.16.0.1 table ovpnc1
ip route add default via 10.16.0.1 table ovpnc3

… when it should really include the network interface as well.

Code:
ip route add default via 10.16.0.1 dev tun11 table ovpnc1
ip route add default via 10.16.0.1 dev tun13 table ovpnc3

NOW it doesn't matter that the tunnels overlap, since each is managed separately, within its own routing table. But failing to include the network interface means the routing system is left to determine which network interface is relevant. And as such, it's defaulting to the one that established a route to 10.16.0.1 first, either opvnc1 or ovpnc3, for both tables. If you dump the respective tables, you'll see what I mean.

Code:
ip route show table ovpnc1
ip route show table ovpnc3


In my own case, I'm using ovpnc2 and ovpnc3, but the effects are the same. Each table points to 10.16.0.1 on the tun12 network interface.

Code:
admin@lab-merlin1:/tmp/home/root# ip route show table ovpnc2
185.240.246.99 via 192.168.63.1 dev vlan2
192.168.63.1 dev vlan2  proto kernel  scope link
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
10.16.0.0/16 dev tun12  proto kernel  scope link  src 10.16.0.24
127.0.0.0/8 dev lo  scope link
default via 10.16.0.1 dev tun12

admin@lab-merlin1:/tmp/home/root# ip route show table ovpnc3
185.240.246.99 via 192.168.63.1 dev vlan2
192.168.63.1 dev vlan2  proto kernel  scope link
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
10.16.0.0/16 dev tun12  proto kernel  scope link  src 10.16.0.24
127.0.0.0/8 dev lo  scope link
default via 10.16.0.1 dev tun12 # WRONG!!  Should be tun13

But if you manually replace the errant default route in ovpnc3 w/ the proper network interface, things will start working correctly.

Code:
ip route rep default via 10.16.0.1 dev tun13 table ovpnc3

Again, I'm only mentioning it in this thread because it's the best opportunity to explain the problem w/ the VPN Director and how to correct it. The VPN Director, if it handles this properly, can eliminate these IP tunnel overlaps *provided* it includes the network interface when adding the default route to the ovpncx tables. At present, it doesn't seem to be doing so.
Thanks for taking the time to reply and it makes sense! I'll try your manual solution till this is sorted!
 
Thanks for taking the time to reply and it makes sense! I'll try your manual solution till this is sorted!

For completeness, realize the 10.16.0.0/16 route should be changed as well. It's pointing to the wrong network interface for the same reasons. It's probably not going to matter when dealing w/ a commercial OpenVPN provider since the only thing typically referenced and accessible is the default gateway (maybe a DNS server from the OpenVPN provider too). But in the more general case of private servers, where you commonly access numerous devices on the remote network behind that server, it would make a difference.

Remember too, it's not uncommon for OpenVPN to force a restart for numerous reasons, which risks these tables being reinitialized, and requiring you reapply the fix. So it might be better to follow the advice of @chongnt and change the protocol in the hope you end up w/ different IP networks on the tunnels.
 
Last edited:
While specifying the explicit interface in the default route, having overlapping tunnel subnets will still be unreliable, as there will still be conflicts in your routing tables. Your provider may also very well end up handing you the same IP address for both tunnels, making things even more confusing for the router's routing. Take the main table for instance, where I have tun11 and tun12 connected to two different NordVPN servers with both the same subnet:

Code:
admin@rtac66b1:/tmp/home/root# ip route show table main
192.168.10.1 dev eth0  proto kernel  scope link
192.168.50.0/24 dev br0  proto kernel  scope link  src 192.168.50.1
10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1
192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.202
10.7.2.0/24 dev tun11  proto kernel  scope link  src 10.7.2.5
10.7.2.0/24 dev tun12  proto kernel  scope link  src 10.7.2.2
127.0.0.0/8 dev lo  scope link
default via 192.168.10.1 dev eth0

The same crossed routes will also be present in each of the client tables. So even if I do specify the default gateway interface (which will fix the issue of the wrong interface being added to the client table), it won't guarantee that routing will work properly for everyone.
 
While specifying the explicit interface in the default route, having overlapping tunnel subnets will still be unreliable, as there will still be conflicts in your routing tables. Your provider may also very well end up handing you the same IP address for both tunnels, making things even more confusing for the router's routing. Take the main table for instance, where I have tun11 and tun12 connected to two different NordVPN servers with both the same subnet:

Code:
admin@rtac66b1:/tmp/home/root# ip route show table main
192.168.10.1 dev eth0  proto kernel  scope link
192.168.50.0/24 dev br0  proto kernel  scope link  src 192.168.50.1
10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1
192.168.10.0/24 dev eth0  proto kernel  scope link  src 192.168.10.202
10.7.2.0/24 dev tun11  proto kernel  scope link  src 10.7.2.5
10.7.2.0/24 dev tun12  proto kernel  scope link  src 10.7.2.2
127.0.0.0/8 dev lo  scope link
default via 192.168.10.1 dev eth0

The same crossed routes will also be present in each of the client tables. So even if I do specify the default gateway interface (which will fix the issue of the wrong interface being added to the client table), it won't guarantee that routing will work properly for everyone.

Yes, assuming you're NOT using routing policy (i.e., the VPN Director). But that's always been the case. It's why I don't ever recommend using anything but routing policy when you have multiple, concurrent OpenVPN clients. It creates a level of unpredictability. But if you use only the VPN Director, there won't be any such conflicts since the routing for each OpenVPN client will be totally confined to its own routing table (ovpnc1, ovpnc2, etc.). That's why I mentioned in a followup that you need to change the 10.16.0.0/16 route in each of the ovpncx tables as well. Then whatever exists in the main table wrt tun1x is never referenced.
 
That's why I mentioned in a followup that you need to change the 10.16.0.0/16 route in each of the ovpncx tables as well.
That's just a direct copy of the main table content. Trying to automatically decide what to copy and what not to copy might get tricky. And it will still result in routing conflict in the main table. Remember, that subnet traffic does not come from a LAN client, it comes from the openvpn client itself running on the router.

People should simply NOT have two different tunnels with the same subnet on both.
 
Imagine you're the router itself, and you are trying to ping the remote server to ensure that the tunnel is up and running.

Code:
ping 10.7.2.1

Your main routing table contains this:

Code:
10.7.2.0/24 dev tun11  proto kernel  scope link  src 10.7.2.5
10.7.2.0/24 dev tun12  proto kernel  scope link  src 10.7.2.2

Only the first matching route will get used, so you will probably never be able to successfully ping the second tunnel's server, which will eventually lead to a ping timeout, and that tunnel may go down.
 
That's just a direct copy of the main table content. Trying to automatically decide what to copy and what not to copy might get tricky. And it will still result in routing conflict in the main table. Remember, that subnet traffic does not come from a LAN client, it comes from the openvpn client itself running on the router.

People should simply NOT have two different tunnels with the same subnet on both.

I agree. Ideally, you don't want duplication in addressing of the tunnels. But given the way the VPN Director works, it's at least plausible for it to work for the LAN clients. Yes, anything the router itself does wrt the tunnels risks using the wrong tunnel (or at least not the preferred tunnel). A good example is if the user chooses to bind DNSMasq to a push'd DNS server by the OpenVPN server. Most likely it will be within the scope of both tunnels, and unless a routing policy rule is added to bind it to one specific OpenVPN client, it will be determined by the main routing table. Even so, I consider it a minor issue.

As far as ping, and as I understand it, OpenVPN's keepalive doesn't use a traditional ping as we know it. It's an *internal* mechanism with the OpenVPN process itself. So the routing happens within the control channel, NOT the data channel. So I don't see this being a problem (when I examine my own configuration, I don't see any restarts due to inactivity).

But again, I agree in principle that the whole mess be avoided. But when I examined the entire layout of how the VPN Director works, as I said, it seemed plausible. Or that we could at least do better, w/ the knowledge it won't be perfect.
 
Thanks all for your support. the workaround of eibgrad works for now, but you'll have to re-apply this after each restart of your VPN Profile/router.
 
Is there a reason I'm not thinking of not to assign a different metric to routes that overlap? It shouldn't affect the LAN clients and it will advise the router which to choose. Barring additional information it would make sense that the last added/updated route has priority.
 
Metrics only allows you to establish priority. It still means that only the first route (or the highest metric priority) will ever get used.
 
Right. That will end the ambiguity for the router. It shouldn't affect the LAN clients with the interface specified.
 
Right. That will end the ambiguity for the router. It shouldn't affect the LAN clients with the interface specified.

The ambiguity is always resolved, even if you do nothing. Without a metric, the routing system will still make a decision and use one of the two tunnels exclusively (most likely the one that got connected first). All the metric does is allow YOU to choose how it's resolved. Whatever problems result from having two or more tunnels bound to the same IP network remain the same. At least from the perspective of the router.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

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