VPN director Multiple OpenVPN clients

[Jamee]

I have multiple OpenVPN clients configured to route specific devices to various places. I have all of the clients set to Redirect Internet traffic through tunnel to VPN director (policy rules) and then each device has its own rule set to the corresponding OpenVPN client I want it to route through.

I am running into an issue where I will have a device on Client 2, and a DNS leak test shows it where it supposed to be, but an IP.me lookup puts it where Client 1 is routing, even though it is not in the rules to be running through that tunnel and both clients are up and connected.

Is my understanding that all of these tunnels are separate and the devices running through them should only be going through whichever one I assign it to? I don’t understand how to keep it from seemingly crossing over somehow?

 

[eibgrad]

Make sure each OpenVPN client has "Accept DNS configuration" set to Exclusive.

 

[Jamee]

Make sure each OpenVPN client has "Accept DNS configuration" set to Exclusive.

All of them are set to exclusive

 

[eibgrad]

What router model and firmware version?

I assume these OpenVPN clients are connected to commercial OpenVPN providers (e.g., NordVPN). Perhaps even the same one. How do you KNOW what the public IP is supposed to be for any given connection? Just because you connect to a given remote IP address (or domain name) doesn't necessarily tell you what the public IP will be. It might just be a proxy server, in which case the exit server can only be determined after the connection. In fact, given the same OpenVPN provider, it's possible many different remote IPs exit the same server.

I've seen ppl get confused by this in the past because they're assuming the remote IP and public IP are one and the same. Not necessarily.

In any situation like this, it's a good idea to dump the internals (with the system active wrt the configuration in question) so we can at least confirm there isn't anything that appears out of order, then work from there.

ifconfig
brctl show
ip route show table main
ip route show table ovpnc1
ip route show table ovpnc2
ip route show table ovpnc3
ip route show table ovpnc4
ip route show table ovpnc5
ip rule
iptables -t mangle -vnL
iptables -t nat -vnL
iptables -vnL
cat /tmp/etc/openvpn/client1/config.ovpn
cat /tmp/etc/openvpn/client2/config.ovpn
cat /tmp/etc/openvpn/client3/config.ovpn
cat /tmp/etc/openvpn/client4/config.ovpn
cat /tmp/etc/openvpn/client5/config.ovpn
cat /jffs/openvpn/vpndirector_rulelist

I included all the OpenVPN clients since I'm not sure which ones are relevant here.

Feel free to mask your public IP. Just do so in an obvious and consistent manner.

 

[Jamee]

What router model and firmware version?

I assume these OpenVPN clients are connected to commercial OpenVPN providers (e.g., NordVPN). Perhaps even the same one. How do you KNOW what the public IP is supposed to be for any given connection? Just because you connect to a given remote IP address (or domain name) doesn't necessarily tell you what the public IP will be. It might just be a proxy server, in which case the exit server can only be determined after the connection. In fact, given the same OpenVPN provider, it's possible many different remote IPs exit the same server.

I've seen ppl get confused by this in the past because they're assuming the remote IP and public IP are one and the same. Not necessarily.

In any situation like this, it's a good idea to dump the internals (with the system active wrt the configuration in question) so we can at least confirm there isn't anything that appears out of order, then work from there.

ifconfig
brctl show
ip route show table main
ip route show table ovpnc1
ip route show table ovpnc2
ip route show table ovpnc3
ip route show table ovpnc4
ip route show table ovpnc5
ip rule
iptables -t mangle -vnL
iptables -t nat -vnL
iptables -vnL
cat /tmp/etc/openvpn/client1/config.ovpn
cat /tmp/etc/openvpn/client2/config.ovpn
cat /tmp/etc/openvpn/client3/config.ovpn
cat /tmp/etc/openvpn/client4/config.ovpn
cat /tmp/etc/openvpn/client5/config.ovpn
cat /jffs/openvpn/vpndirector_rulelist

I included all the OpenVPN clients since I'm not sure which ones are relevant here.

Feel free to mask your public IP. Just do so in an obvious and consistent manner.

I can tell what they’re supposed to be because one routes to one country and the other routes to another so then when I’m checking ip.me and seeing the country for client 1 even though I’m routing through client 3 it’s pretty clear. It also resolves when I turn off client 1.

It does seem to be that the commercial VPN I have is giving them the same subset. I searched some more after your comment and it seems like this explains it

https://www.snbforums.com/threads/vpn-director-not-applying-rules-to-right-vpn-profile.74386/

I’m going to check if their TCP/UDP options are different if that can resolve it since my internet provider drops pretty often so going in and adding code like the above thread lists as a workaround isn’t really going to be feasible every time it drops.

Thanks for the suggestions, I’ve been trying to figure this out for months!

 

[eibgrad]

That's why I asked about your router and current firmware. I thought there might be a chance you were using older firmware before Merlin made the changes I suggested in that link. With those changes, it should be possible to support the same IP network across different tunnels. But I can only confirm it by seeing a dump of your internals (specifically the OpenVPN client routing tables).

 

[Jamee]

Asus RT-AC86U Merlin vs 386.14

Should this not be an issue anymore with the current firmware? I switched one to TCP and it’s using a different subnet but if there’s something else I should be looking at I’ll
dig into it more

 

[eibgrad]

Until you finally provided the firmware version, I had no idea if in fact you were having the same problem as in that link. I was holding back until I could confirm one way or the other, either based on the firmware version or a dump of the routing tables. I didn't want to get too deeply into the weeds if it proved unnecessary. I thought it unlikely to be the same problem knowing how long ago it was fixed. Then again, it's not as if I haven't seen users w/ old firmware from time to time.

So 386.14 should be fine. Not unless there's been a regression. Again, w/o being able to see the internals, I can't confirm if it is the same problem (seems unlikely), a possible regression, or something else entirely.