VPN bug

[dreba]

I use the latest merlin fw 380.65. I setup client5 with openvpn with a US server (us.vpn.ht) and client4 openvpn with a Norwegian server (no.vpn.ht).

Is it possible to have them both active at the same time? I was thinking using Norway for my macbook and US for my Apple TV.

 

[Fingers]

I use the latest merlin fw 380.65. I setup client5 with openvpn with a US server (us.vpn.ht) and client4 openvpn with a Norwegian server (no.vpn.ht).

Is it possible to have them both active at the same time? I was thinking using Norway for my macbook and US for my Apple TV.

Yes this is possible. I run three different vpn server locations depending on what the connected devices need

 

[wocram]

I use the latest merlin fw 380.65. I setup client5 with openvpn with a US server (us.vpn.ht) and client4 openvpn with a Norwegian server (no.vpn.ht).

Is it possible to have them both active at the same time? I was thinking using Norway for my macbook and US for my Apple TV.

Yes, works perfectly with several VPN tunnels at the same time!
You should be aware though that the total bandwidth might be limited by your router's processor power.
Also it depends on how many simultaneous connections your VPN provider allows.

 

[z3r0k3wl]

I'm not able to run 2 OpenVPN clients at the same time on my AC68U. With both enabled, client 1 and client 2, with police routing enabled for the specific devices I want to route, anything not routed through VPN has mixed up routing issues. Some will route through client 1 and use my ISP DNS even though it's not listed in the policy routing table. Very messed up! Can't seem to figure it out. Done factory reset too.

 

[Martineau]

Some will route through client 1 and use my ISP DNS even though it's not listed in the policy routing table. Very messed up! Can't seem to figure it out. Done factory reset too.

You will need to check the contents of the RPDB and route tables

Issue the following commands (assumes VPN Client 1 and VPN Client 2 are running concurrently etc.) when the VPN routing is working, and after when the routing is broken:

ip rule

ip route show table ovpnc1
ip route show table ovpnc2

 

[z3r0k3wl]

You will need to check the contents of the RPDB and route tables

Issue the following commands (assumes VPN Client 1 and VPN Client 2 are running concurrently etc.) when the VPN routing is working, and after when the routing is broken:

ip rule

ip route show table ovpnc1
ip route show table ovpnc2

Here you go.

Both Clients Running (Doesn't work)
######@########:/tmp/home/root# ip route show table ovpnc1
184.75.221.162 via 174.114.238.1 dev eth0
174.114.238.1 dev eth0 proto kernel scope link
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
174.114.238.0/23 dev eth0 proto kernel scope link src 174.114.238.38
10.4.0.0/16 dev tun11 proto kernel scope link src 10.4.17.74
127.0.0.0/8 dev lo scope link
0.0.0.0/1 via 10.4.0.1 dev tun11
128.0.0.0/1 via 10.4.0.1 dev tun11
default via 10.4.0.1 dev tun11
######@########:/tmp/home/root# ip route show table ovpnc2
184.75.221.162 via 174.114.238.1 dev eth0
104.243.24.235 via 174.114.238.1 dev eth0
174.114.238.1 dev eth0 proto kernel scope link
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
174.114.238.0/23 dev eth0 proto kernel scope link src 174.114.238.38
10.4.0.0/16 dev tun11 proto kernel scope link src 10.4.17.74
127.0.0.0/8 dev lo scope link
0.0.0.0/1 via 10.4.0.1 dev tun11
128.0.0.0/1 via 10.4.0.1 dev tun11
default via 10.4.0.1 dev tun11

ovpnc1 client running by itself. (Works fine)
######@########:/tmp/home/root# ip route show table ovpnc1
184.75.221.162 via 174.114.238.1 dev eth0
174.114.238.1 dev eth0 proto kernel scope link
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
174.114.238.0/23 dev eth0 proto kernel scope link src 174.114.238.38
10.4.0.0/16 dev tun11 proto kernel scope link src 10.4.17.74
127.0.0.0/8 dev lo scope link
0.0.0.0/1 via 10.4.0.1 dev tun11
128.0.0.0/1 via 10.4.0.1 dev tun11
default via 10.4.0.1 dev tun11

 

[Martineau]

Here you go.

Both Clients Running (Doesn't work)

ip route show table ovpnc2
0.0.0.0/1 via 10.4.0.1 dev tun11
128.0.0.0/1 via 10.4.0.1 dev tun11
default via 10.4.0.1 dev tun11

When you start VPN Client 2, it incorrectly copies all the VPN Client 1 routes (see /usr/sbin/vpnrouting.sh)

For most users, each VPN Client ovpncX table effectively only requires 1 entry.

default via xxx.xxx.xxx.xxx dev tun1X

So when it next fails issue the following:

ip route flush table ovpnc1
ip route add default via `ip route show table main | grep tun11 | cut -d" " -f12` dev tun11 table ovpnc1

ip route flush table ovpnc2
ip route add default via `ip route show table main | grep tun12 | cut -d" " -f12` dev tun12 table ovpnc2

ip route flush cache

If this fixes the problem, then you can create openvpn-event scripts vpnclient1-route-up and vpnclient2-route-up to correct the tables when you start the 2nd VPN Client instance.

P.S. You should also check table main, to see if the following entries exist:

ip route show table main
0.0.0.0/1 via 10.4.0.1 dev tun1X
128.0.0.0/1 via 10.4.0.1 dev tunX

if they are then this means ALL traffic will be routed via the VPN Client.

Q. I assume you have Selected Policy routing for both Clients?

 

[z3r0k3wl]

When you start VPN Client 2, it incorrectly copies all the VPN Client 1 routes (see /usr/sbin/vpnrouting.sh)

For most users, VPN Client tables effectively only require 1 entry.

default via xxx.xxx.xxx.xxx dev tun11
default via xxx.xxx.xxx.xxx dev tun12

So when it next fails issue the following:

ip route flush table ovpnc1
ip route add default via `ip route show table main | grep tun11 | cut -d" " -f12` dev tun11 table ovpnc1

ip route flush table ovpnc2
ip route add default via `ip route show table main | grep tun12 | cut -d" " -f12` dev tun12 table ovpnc2

ip route flush cache

If this fixes the problem, then you can create openvpn-event scripts vpnclient1-route-up and vpnclient2-route-up to correct the tables when you start the 2nd VPN Client instance.

Would this be considered a bug or fault in the firmware code as to why the routes are being copied from ovpnc1?

 

[Martineau]

Would this be considered a bug or fault in the firmware code as to why the routes are being copied from ovpnc1?

Welll...it depends, - @RMerlin / @john9527 maintain the /usr/sbin/vpnrouting.sh code, and both forks have slightly different versions.
But since you can use the openvpn-event scripts to customise your multi-VPN Client environment then it's not really a fault of the firmware? -or is it?

 

[john9527]

Would this be considered a bug or fault in the firmware code as to why the routes are being copied from ovpnc1?

The routes are actually copied from table main so any custom routing you have in place is also available on the VPN clients (for example if you have custom routing to access your modem setup).

So, a couple of things I think you need to check if you want to run 2 clients together...
- Use Policy based routing for both clients
- Make sure neither client has a 'global' rule for the VPN, for example 192.168.1.0/24 to default route everything over the VPN. Enter the clients you want to use each VPN separately.

Finally, as @Martineau mentioned, my fork and Merlin have a slightly different vpnrouting.sh
I just double checked on my fork, and the tables look right for two clients. You may want to try a copy of my vpnrouting.sh to see if it makes a difference (it should be compatible). If you would like to try and need a copy/instructions, reply back.

 

[z3r0k3wl]

The routes are actually copied from table main so any custom routing you have in place is also available on the VPN clients (for example if you have custom routing to access your modem setup).

So, a couple of things I think you need to check if you want to run 2 clients together...
- Use Policy based routing for both clients
- Make sure neither client has a 'global' rule for the VPN, for example 192.168.1.0/24 to default route everything over the VPN. Enter the clients you want to use each VPN separately.

Finally, as @Martineau mentioned, my fork and Merlin have a slightly different vpnrouting.sh
I just double checked on my fork, and the tables look right for two clients. You may want to try a copy of my vpnrouting.sh to see if it makes a difference (it should be compatible). If you would like to try and need a copy/instructions, reply back.

I don't have any custom routing.

Policy base routing for the specific devices I want to send though the tunnel is setup. It's the devices I don't want run through the tunnels and not added to policy based routing that have messed up routing.

No such global settings set.

 

[Martineau]

You may want to try a copy of my vpnrouting.sh to see if it makes a difference

Sadly your vpnrouting.sh will still clone incorrect tun1X entries for the 2nd VPN Client instance started i.e. under @RMerlin's fork VPN Client 2,3,4 or 5.

I have used this patch.....

# Fill it with copy of existing main table
- ip route show table main | while read ROUTE
+########################################################################################## Martineau Hack 1 of 2
+ #ip route show table main | while read ROUTE
+ ip route show table main | grep -v "tun1" | while read ROUTE
  do
   ip route add table $VPN_TBL $ROUTE
  done
+##########################################################################################
 }

 

[john9527]

Sadly your vpnrouting.sh will still clone incorrect tun1X entries for the 2nd VPN Client instance started i.e. under @RMerlin's fork VPN Client 2,3,4 or 5.

Hmmm.....wonder what the difference is. I did double check on my fork and it only had the correct entries....

table main
- other routes
127.0.0.0/8 dev lo scope link
default via 70.171.xxx.xxx dev eth0

table ovpnc1
- other routes
127.0.0.0/8 dev lo scope link
default via 10.10.10.5 dev tun11

table ovpnc2
- other routes
127.0.0.0/8 dev lo scope link
default via 10.10.0.113 dev tun12

 

[john9527]

@Martineau
Did you run on your AC68 or the AC56? There were some fixes picked up on VPN start/stop in 380.65 that I can speculate may affect this.

 

[Martineau]

@Martineau
Did you run on your AC68 or the AC56? There were some fixes picked up on VPN start/stop in 380.65 that I can speculate may affect this.

RT-AC68 but my vpnrouting.sh hacks have been necessary on both AC68/56.

I suspect this issue only exists for certain VPN providers i.e. I use HMA.
Also, I recall that previously 'inappropriate' Custom directives can also cause table main to be 'corrupted' prior to vpnrouting.sh attempting the cloning - been like this for years in my experience.

Suffice to say, the logic behind my hack is whichever VPN client is started first e.g. VPN Client3, it will never contain the routing info for any other subsequent VPN Client that is started, so why not level the playing field and ensure no VPN Client knows about its siblings?

 

[RMerlin]

Might be worth looking at the new OpenVPN 2.4.0 parameters that allows you to reject specific parameter that get pushed to you (like the IPv6 fix I posted). Would allow someone to reject the problematic routes as they get pushed.

 

[john9527]

RT-AC68 but my vpnrouting.sh hacks have been necessary on both AC68/56.

I only asked about the router based on your sig which indicated different code levels. Have you actually tried on 380.65 or working from past experience? One of the things fixed in 380.65 could fix spurious added routes in table main not being deleted when openvpn was restarted.