Multiple VPN Clients and Local IP Subnet Question

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

Chez

Occasional Visitor
I'm using an AX88U with Merlin installed.

I have multiple VPN Clients setup (1 NY, 1 Dallas and 1 UK) using NordVPN OpenVPN and working, however every now and then I run into an issue whereby more than one of the VPN Client connections gets the same Local IP Subnet (for example 2 will have 10.8.1.x). When this happens, the clients don't route to the correct VPN reliably.

I can fix it by disconnecting/reconnecting one of them or by hitting apply on the client setup page, which usually makes one change to a different subnet, but was wondering why this happens and if there's a way to force them to use different subnets (for example 10.8.0.x for the first, 10.8.1.x for the second, etc)?

Thanks!
 
Last edited:

Jack Yaz

Part of the Furniture
For NordVPN, you will always get a different local subnet for TCP and UDP. TCP is 10.7.x.x and UDP is 10.8.x.x. This isn't something you can control, the VPN Server is the thing responsible for dishing out IP addresses.

I /think/ the dedicated IP (paid add-on) for NordVPN provide a 3rd subnet, but I don't subscribe to that addon to check
 

Chez

Occasional Visitor
I'm using UDP for all.

I always get 10.8.x.x, however the issue comes when at some random point down the line (after working fine), 2 of the connections get the same subnet.

For example, it may start out with :

NY 10.8.1.x
Dallas 10.8.2.x
UK 10.8.3.x

At some point, one changes so I may end up with:

NY 10.8.1.x
Dallas 10.8.1.x
UK 10.8.3.x

Hope that makes it clearer?
 

Chez

Occasional Visitor
Side note: I asked the moderators to delete this as I reposted in the VPN forum, could you reply there (if you reply), in case this one gets deleted?

Thank you!

 

Jack Yaz

Part of the Furniture
I'm using UDP for all.

I always get 10.8.x.x, however the issue comes when at some random point down the line (after working fine), 2 of the connections get the same subnet.

For example, it may start out with :

NY 10.8.1.x
Dallas 10.8.2.x
UK 10.8.3.x

At some point, one changes so I may end up with:

NY 10.8.1.x
Dallas 10.8.1.x
UK 10.8.3.x

Hope that makes it clearer?
It /may/ work some of the time, but you run the risk of conflicts as you've already seen. Entirely depends on which server you connect to and how NordVPN have configured it. The problem occurs with matching subnets as there then become 2 matching routes. You can test this by running
Code:
ip route show | grep tun1

If the mods move/delete one of the posts hopefully they'll merge my posts :)
 

Chez

Occasional Visitor
It /may/ work some of the time, but you run the risk of conflicts as you've already seen. Entirely depends on which server you connect to and how NordVPN have configured it. The problem occurs with matching subnets as there then become 2 matching routes. You can test this by running
Code:
ip route show | grep tun1

If the mods move/delete one of the posts hopefully they'll merge my posts :)
Thanks!

What's confusing me is that I'm not changing the servers.

I set them up and leave them. Initially they all have different 'Local IP' subnets.. then at some point one changes to match another.
 

eibgrad

Very Senior Member
Thanks!

What's confusing me is that I'm not changing the servers.

I set them up and leave them. Initially they all have different 'Local IP' subnets.. then at some point one changes to match another.

That does seem unusual. But nonetheless, the fact remains. This is *always* a risk when dealing w/ multiple, concurrent OpenVPN clients, esp. when they are the same provider. There's just no escaping it. This is an inherent limitation of depending so much on NAT as we do (and something that IPv6 in the future promises to eliminate).

It's like users who setup their own OpenVPN server for remote access to their LAN. No matter what you specify for your home network, there's always a risk, no matter how small, your OpenVPN client will end up using the same local network, making your home network inaccessible. There's just nothing you can do about it.
 
Last edited:

Chez

Occasional Visitor
That does seem unusual. But nonetheless, the fact remains. This is *always* a risk when dealing w/ multiple, concurrent OpenVPN clients, esp. when they are the same provider. There's just no escaping it. This is an inherent limitation of depending so much on NAT as we do (and something that IPv6 in the future promises to eliminate).

It's like users who setup their own OpenVPN server for remote access to their LAN. No matter what you specify for your home network, there's always a risk, no matter how small, your OpenVPN client will end up using the same local network, making your home network inaccessible. There's just nothing you can do about it.
Is it theoretically possible to use some kind of script/job to detect when the subnets match and refresh one of the connections until it differs?
 

eibgrad

Very Senior Member
Theoretically? I suppose so. It's a computer. It can be programmed. You can probably create some sort of script that interrogates the state of the OpenVPN client, and when it's not to your liking, force a restart. I can certainly imagine it. It would probably have to be some sort of watchdog/monitoring process that worked entirely outside the confines of OpenVPN itself.
 
Last edited:

eibgrad

Very Senior Member
This is one of those cases where it helps to think differently.

Rather than forcing both OpenVPN clients to be supported on one device, why not have them supported on different devices? In that way, since the OpenVPN clients never share a common routing table, it doesn't matter if both clients do or don't end up w/ the same IP network on the tunnel!

In my own case, I run my OpenVPN client on a small form-factor PC for performance reasons. I then configure DHCP so certain clients are routed to the PC (based on their default gateway setting), while others are routed normally over the WAN of the primary router. But nothing would stop me from creating an OpenVPN client on the primary router too. In effect, I've created a "routing policy" that has certain LAN clients using one OpenVPN client vs. the other. Or you could even go so far as to create your own routing policy tables on the primary router and route certain clients to the secondary OpenVPN client.

Now granted, that seems like a lot of work to just avoid this IP conflict on the tunnel, esp. if it can be circumvented reliably using UDP for one and TCP for the other. But if for some reason that's not possible or acceptable, the above is a viable option. At least if it was *me*, that's the approach I would probably take knowing that trying to script a solution on the primary router will present its own difficulties.
 
Last edited:

Chez

Occasional Visitor
This is one of those cases where it helps to think differently.

Rather than forcing both OpenVPN clients to be supported on one device, why not have them supported on different devices? In that way, since the OpenVPN clients never share a common routing table, it doesn't matter if both clients do or don't end up w/ the same IP network on the tunnel!

In my own case, I run my OpenVPN client on a small form-factor PC for performance reasons. I then configure DHCP so certain clients are routed to the PC (based on their default gateway setting), while others are routed normally over the WAN of the primary router. But nothing would stop me from creating an OpenVPN client on the primary router too. In effect, I've created a "routing policy" that has certain LAN clients using one OpenVPN client vs. the other. Or you could even go so far as to create your own routing policy tables on the primary router and route certain clients to the secondary OpenVPN client.

Now granted, that seems like a lot of work to just avoid this IP conflict on the tunnel, esp. if it can be circumvented reliably using UDP for one and TCP for the other. But if for some reason that's not possible or acceptable, the above is a viable option. At least if it was *me*, that's the approach I would probably take knowing that trying to script a solution on the primary router will present its own difficulties.
Worth some thought, for sure.. I just like the theoretical convenience of having it all happen on one device without the overhead of another PC/router/thing to maintain.

In fact, it would probably be cheaper to just sign up for a second VPN provider to run one of the tunnels on (assuming, for example that ExpressVPN use different subnets to NordVPN?).

The only reason I have them all running UDP is that the performance seems slightly better (which is in line with what NordVPN and common logic dictates too, I believe).
 

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