RT-AC68U: Unable to add 2nd OpenVPN client.

[Jack Yaz]

Would it actually make more sense to only clone routes that are specific to the tunnel interface? I.e, in vpnrouting.sh:

init_table(){
        logger -t "openvpn-routing" "Creating VPN routing table"
        ip route flush table $VPN_TBL

# Fill it with copy of existing main table
        ip route show table main dev $dev | while read ROUTE
        do
                ip route add table $VPN_TBL $ROUTE dev $dev
        done
}

This might however mean that any user-defined static route would be missing from that client's table.

Sorry to necro an old thread, but was @Martineau finding resolved?

 

[RMerlin]

Sorry to necro an old thread, but was @Martineau finding resolved?

No idea if his particular issue was addressed (it's been too long), but Policy Rules (strict mode) does what I was suggesting - it will only copy rules that are related to that tunnel's interface.

 

[Jack Yaz]

No idea if his particular issue was addressed (it's been too long), but Policy Rules (strict mode) does what I was suggesting - it will only copy rules that are related to that tunnel's interface.

Thanks. With Strict and 2 clients my routing tables are going a bit awry, and the default route 0.0.0.0/1 etc. end up back in main table. I suspect this is due to the same subnet of the VPN servers I'm connecting to, which I believe @Martineau surmised. Will try a different set of servers and see if this clears it.

 

[Jack Yaz]

Thanks. With Strict and 2 clients my routing tables are going a bit awry, and the default route 0.0.0.0/1 etc. end up back in main table. I suspect this is due to the same subnet of the VPN servers I'm connecting to, which I believe @Martineau surmised. Will try a different set of servers and see if this clears it.

@RMerlin I've taken a stab at improving vpnrouting.sh, diff here: https://www.diffchecker.com/wq6gnGNe

I found with multiple clients routes for 0.0.0.0/1 and 128.0.0.1/1 would remain for at least one tun interface in the main route table. I also found that the line responsible for adding a new default could pick up the wrong interface if VPN servers with identical gateways (in my case 10.8.8.1), would cause tun11 and tun12 defaults to end up in the wrong tables (ovpnc1 ovpnc2)

 

[RMerlin]

I also found that the line responsible for adding a new default could pick up the wrong interface if VPN servers with identical gateways (in my case 10.8.8.1)

You cannot have two different tunnels with the same gateway - this would lead to duplicate internal routes regardless of whether you used policy routing or not.

 

[Jack Yaz]

You cannot have two different tunnels with the same gateway - this would lead to duplicate internal routes regardless of whether you used policy routing or not.

Oh, it seemed to work in testing. I thought specifying the interface would help with preventing the duplicates. I'll switch it to Martineaus default via vpnendpoint from the script posted earlier in this thread.

Is there a way to see the internal routes?

 

[RMerlin]

Is there a way to see the internal routes?

Everything shown by "ip route" in all tables returned by "ip rule show". Those form the kernel's RPDB.

 

[Jack Yaz]

Everything shown by "ip route" in all tables returned by "ip rule show". Those form the kernel's RPDB.

Oh, in which case I haven't seen any duplicates. I'll post the outputs of the tables next time I'm on the computer. I could be mistaken however!

 

[Jack Yaz]

Sorry, think I was unclear, I meant gateway subnets not the gateway ip itself. Sorry, this is why i shouldn't work on scripts late at night particularly after a very emotionally demanding day!

 

[Jack Yaz]

Everything shown by "ip route" in all tables returned by "ip rule show". Those form the kernel's RPDB.

RPDB below.

admin@RT-AC87U:/tmp/home/root# ip rule
0:      from all lookup local
10101:  from 10.14.16.22 lookup ovpnc1
10301:  from 10.14.16.50 lookup ovpnc2
32766:  from all lookup main
32767:  from all lookup default

admin@RT-AC87U:/tmp/home/root# ip route show table main
81.92.203.44 via 22.222.22.1 dev eth0
22.222.22.1 dev eth0  proto kernel  scope link
95.141.37.164 via 22.222.22.1 dev eth0
111.111.11.0/24 dev br0  proto kernel  scope link  src 111.111.11.57
10.14.16.0/24 dev br0  proto kernel  scope link  src 10.14.16.1
22.222.22.0/24 dev eth0  proto kernel  scope link  src 22.222.22.163
10.8.8.0/24 dev tun12  proto kernel  scope link  src 10.8.8.154
10.8.8.0/24 dev tun11  proto kernel  scope link  src 10.8.8.176
10.16.14.0/24 dev tun21  proto kernel  scope link  src 10.16.14.1
127.0.0.0/8 dev lo  scope link
default via 22.222.22.1 dev eth0

admin@RT-AC87U:/tmp/home/root# ip route show table ovpnc1
111.111.11.0/24 dev br0  proto kernel  scope link  src 111.111.11.57
10.14.16.0/24 dev br0  proto kernel  scope link  src 10.14.16.1
10.8.8.0/24 dev tun11  proto kernel  scope link  src 10.8.8.176
default via 10.8.8.1 dev tun11


admin@RT-AC87U:/tmp/home/root# ip route show table ovpnc2
111.111.11.0/24 dev br0  proto kernel  scope link  src 111.111.11.57
10.14.16.0/24 dev br0  proto kernel  scope link  src 10.14.16.1
10.8.8.0/24 dev tun12  proto kernel  scope link  src 10.8.8.154
default via 10.8.8.1 dev tun12

I think there 2 potential duplicates are in table main, but I am unclear if the differing src will prevent route overlap?

10.8.8.0/24 dev tun12  proto kernel  scope link  src 10.8.8.154
10.8.8.0/24 dev tun11  proto kernel  scope link  src 10.8.8.176

 

[RMerlin]

I think there 2 potential duplicates are in table main, but I am unclear if the differing src will prevent route overlap?

They have the exact same subnet, which means only one of the two will work - whichever comes first in the routing table.

 

[Jack Yaz]

I'm yet to see any problems in my testing so far, will keep looking

 

[Jack Yaz]

Can you give me a test to run please to cause a failure? From what i can see, policy routed clients hit the right tunnel due to ip rule sending them to the correct routing table.

 

[RMerlin]

Can you give me a test to run please to cause a failure?

I can't give you a specific test case, sorry. It's just a fact that if you have multiple routes that have overlapping/conflicting routes, whichever has the highest priority will always be used. It might work when using policy rules because you actually create higher priority rules that get used before reaching the lower priority default rules.

 

[Jack Yaz]

I can't give you a specific test case, sorry. It's just a fact that if you have multiple routes that have overlapping/conflicting routes, whichever has the highest priority will always be used. It might work when using policy rules because you actually create higher priority rules that get used before reaching the lower priority default rules.

I understand, but what I'm not understanding is why the routed clients get the correct VPN Endpoint IP.

EDIT: Ah, I have found a way to see the problems caused. Watching the route tables when bringing up one of the clients shows the overlap and leak.