Strange issue with OVPN routing

[tgab_b]

My setup is RT-AX56U (fw: 386.3_2) as Router and RT-AC88U (fw: 3.0.0.4.386_43129-g60defb2) as AIMesh Node.

I have 2 OVPN client activated, one is used by Transmission and other is used by Nvidia Shield TVs. The VPN Director is used to routing rules:

However, it seems the routing is not working and both devices are routed OVPN1. I have tried many hard reset of router, including going back to 386_2_6, overlaying with original ASUS firmware and the reverted back to RMerline fw. But this problem is not going away.It was working few days back and all of a sudden it is lost.First I suspected VPN director but later concluded that it was not.

Here are outputs from various commands:

RT-User@RT-AX56U-xxxx:/tmp/home/root# ip rule show
0:      from all lookup local
10210:  from 192.168.2.15 lookup ovpnc1
10410:  from 192.168.2.180 lookup ovpnc2
32766:  from all lookup main
32767:  from all lookup default

seem to be missing lines like below:
9994: from all fwmark 0x2000/0x2000 lookup ovpnc2
9995: from all fwmark 0x1000/0x1000 lookup ovpnc1

RT-User@RT-AX56U-xxxx:/tmp/home/root# iptables -nvL PREROUTING -t mangle --line
Chain PREROUTING (policy ACCEPT 2112K packets, 423M bytes)
num   pkts bytes target     prot opt in     out     source               destination
RT-User@RT-AX56U-xxxx:/tmp/home/root# iptables -nvL POSTROUTING -t nat --line
Chain POSTROUTING (policy ACCEPT 14506 packets, 1235K bytes)
num   pkts bytes target     prot opt in     out     source               destination
1      553 65051 MASQUERADE  all  --  *      tun11   0.0.0.0/0            0.0.0.0/0
2        1    68 MASQUERADE  all  --  *      tun12   0.0.0.0/0            0.0.0.0/0
3    29298 3665K PUPNP      all  --  *      eth0    0.0.0.0/0            0.0.0.0/0
4        0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            policy match dir out pol ipsec
5    17815 2743K MASQUERADE  all  --  *      eth0   !132.147.95.64        0.0.0.0/0
6     5957  614K MASQUERADE  all  --  *      br0     192.168.2.0/24       192.168.2.0/24

RT-User@RT-AX56U-xxxx:/tmp/home/root# netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         fnet1-f95-acces 0.0.0.0         UG        0 0          0 eth0
10.16.0.0       *               255.255.0.0     U         0 0          0 tun11
10.16.0.0       *               255.255.0.0     U         0 0          0 tun12
127.0.0.0       *               255.0.0.0       U         0 0          0 lo
132.147.95.0    *               255.255.255.0   U         0 0          0 eth0
132.147.95.1    *               255.255.255.255 UH        0 0          0 eth0
192.168.2.0     *               255.255.255.0   U         0 0          0 br0
192.168.101.0   *               255.255.255.0   U         0 0          0 br1
239.0.0.0       *               255.0.0.0       U         0 0          0 br0

I am running of ideas and thus seek help to fix it. Please let me know if need to provide some other info and what can I try.

 

[ColinTaylor]

Both of your VPN clients appear to be using the same subnet (10.16.0.0) so I suspect that's your problem.

 

[tgab_b]

Both of your VPN clients appear to be using the same subnet (10.16.0.0) so I suspect that's your problem.

I felt too but I do not know how to change it.

 

[ColinTaylor]

I felt too but I do not know how to change it.

You can't change it your end. The subnet is pushed from the server side. All you can do is reconnect one of the clients and hope it gets pushed a different subnet or try using a different VPN profile from the provider.

 

[eibgrad]

Something interesting here for users of VPNs to keep in mind when choosing a VPN provider.

Notice the routing table in this case has 10.16.0.0/16 for both tunnels, but in this other thread, the user has also connected to the same OpenVPN provider multiple times, but the routing table is different. And he's NOT complaining of problems. Each tunnel has been associated w/ a unique host (/32), specifically 10.200.0.45 and 10.200.0.69.

What I suspect is the OP in this thread is using an OpenVPN provider who push's a subnet topology, whereas the OpenVPN provider in the link push's a net30 topology (essentially a point-to-point connection). By using net30, the other user avoids the routing ambiguity made possible w/ subnet.

This is a great example of how it makes a difference which OpenVPN provider you use should you need multiple, concurrent OpenVPN clients from the same provider. Something I doubt most users would even think to consider. It's like users who later decide they need remote access over the VPN, but discover the lack of capability only *after* making a purchase.

As @ColinTaylor says, you can't do anything about the IP network chosen, nor topology required by the OpenVPN server. Best you can do is see if perhaps different servers use different IP networks, which is often the case when you change protocols (UDP vs. TCP).

 

[tgab_b]

Perhaps I can raise a incident to VPN provider. Let's see if they can do something. Otherwise UDP/TCP is also valid option. Thanks a lot for quick support.