Strange issue with OVPN routing

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

tgab_b

Occasional Visitor
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:

1628349140247.png


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:

Code:
[email protected]:/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

Code:
[email protected]:/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
[email protected]:/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

Code:
[email protected]:/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

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

ColinTaylor

Part of the Furniture
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.
 
Last edited:

eibgrad

Very Senior Member
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

Occasional Visitor
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.
 

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