1

When I connect to multiple VPN connections, I lose routes (of the first connected VPN)..

Setup

2 strongSwan servers - local_ts: 10.0.64.0/20 - local_ts: 10.0.80.0/20 1 osx client

Routing table before connecting

# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.0.1 UGSc 82 0 en0 127 127.0.0.1 UCS 0 0 lo0 127.0.0.1 127.0.0.1 UH 17 8937650 lo0 169.254 link#8 UCS 0 0 en0 192.168.0 link#8 UCS 4 0 en0 192.168.0.1/32 link#8 UCS 1 0 en0 192.168.0.1 40:d:10:73:1f:90 UHLWIir 24 120 en0 1177 192.168.0.10 f4:5f:d4:fb:24:4a UHLWI 0 185 en0 925 192.168.0.23 dc:a9:4:2a:21:db UHLWI 0 1 en0 714 192.168.0.31/32 link#8 UCS 0 0 en0 192.168.0.32 0:6d:52:13:65:63 UHLWIi 1 37 en0 73 192.168.0.33 link#8 UHLWI 0 1 en0 224.0.0/4 link#8 UmCS 2 0 en0 224.0.0.251 1:0:5e:0:0:fb UHmLWI 0 0 en0 239.255.255.250 1:0:5e:7f:ff:fa UHmLWI 0 104 en0 255.255.255.255/32 link#8 UCS 0 0 en0

Connected to 10.0.64/20 vpn server

# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.0.1 UGSc 88 0 en0 default link#13 UCSI 0 0 ipsec0 10.0.64/20 172.31.0.1 UGSc 0 0 ipsec0 18.130.230.56 192.168.0.1 UGHS 0 0 en0 127 127.0.0.1 UCS 0 0 lo0 127.0.0.1 127.0.0.1 UH 31 8937992 lo0 169.254 link#8 UCS 0 0 en0 172.31.0.1 172.31.0.1 UH 1 0 ipsec0 192.168.0 link#8 UCS 4 0 en0 192.168.0.1/32 link#8 UCS 1 0 en0 192.168.0.1 40:d:10:73:1f:90 UHLWIir 34 128 en0 1162 192.168.0.10 f4:5f:d4:fb:24:4a UHLWI 0 197 en0 872 192.168.0.23 dc:a9:4:2a:21:db UHLWI 0 1 en0 661 192.168.0.31/32 link#8 UCS 0 0 en0 192.168.0.32 0:6d:52:13:65:63 UHLWIi 1 38 en0 20 192.168.0.33 link#8 UHLWI 0 1 en0 224.0.0/4 link#8 UmCS 2 0 en0 224.0.0/4 link#13 UmCSI 1 0 ipsec0 224.0.0.251 1:0:5e:0:0:fb UHmLWI 0 0 en0 239.255.255.250 1:0:5e:7f:ff:fa UHmLWI 0 113 en0 239.255.255.250 link#13 UHmW3I 0 4 ipsec0 8 255.255.255.255/32 link#8 UCS 0 0 en0 255.255.255.255/32 link#13 UCSI 0 0 ipsec0

Connected to 10.0.80/20 vpn server (first still connected) - route 10.0.64/20 is gone!

# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.0.1 UGSc 81 0 en0 default link#15 UCSI 0 0 ipsec1 10.0.80/20 172.31.1.1 UGSc 0 0 ipsec1 18.130.140.63 192.168.0.1 UGHS 0 0 en0 127 127.0.0.1 UCS 0 0 lo0 127.0.0.1 127.0.0.1 UH 25 8938255 lo0 169.254 link#8 UCS 0 0 en0 172.31.0.1 172.31.0.1 UH 0 0 ipsec0 172.31.1.1 172.31.1.1 UH 1 0 ipsec1 192.168.0 link#8 UCS 3 0 en0 192.168.0.1/32 link#8 UCS 1 0 en0 192.168.0.1 40:d:10:73:1f:90 UHLWIir 28 148 en0 1190 192.168.0.10 f4:5f:d4:fb:24:4a UHLWI 0 203 en0 1190 192.168.0.23 dc:a9:4:2a:21:db UHLWI 0 1 en0 573 192.168.0.31/32 link#8 UCS 0 0 en0 192.168.0.32 0:6d:52:13:65:63 UHLWIi 1 40 en0 1186 224.0.0/4 link#8 UmCS 2 0 en0 224.0.0/4 link#15 UmCSI 1 0 ipsec1 224.0.0.251 1:0:5e:0:0:fb UHmLWI 0 0 en0 239.255.255.250 1:0:5e:7f:ff:fa UHmLWI 0 118 en0 239.255.255.250 link#15 UHmW3I 0 1 ipsec1 10 255.255.255.255/32 link#8 UCS 0 0 en0 255.255.255.255/32 link#15 UCSI 0 0 ipsec1

Why would that happen since the VPN servers are in different CIDR's?

If I manually add the route to 10.0.64/20 after, I can access either network.

Improve this question

1 Answer 1

Reset to default
0

The VPN clients are clearly competing, one with each other for the routing table.

They also muck around with routes and default gateways, with clearly the last one loaded having the advantage of being on position of modifying the routes created by the first.

Lastly, after the last VPN client gets loaded, the lack of routes/different communication paths might confuse the negotiation times/keepalive timers of the 1st one. (and that by itself might also explain routes disappearing).

As you find out, it is not entirely kosher running several VPN clients concurrently in the same client, and more if they are implementing full tunnel VPNs.

One of the chances that you might have to try to run them at the same time, is you messing around with the routing table after they are done. However, it must probably be scripted, as you have a very short time, if it is possible to do it.

I am afraid the synptoms you are describing in your question is plain standard behaviour.

PS. I am messing around with the routes of a Ckeckpoint client in Linux, and from empyrical and theorical knowledge, I know I do have a limited time before the client/firewall decides the connection has gone bad.

Improve this answer
3
  • Thanks, Rul. The idea of negotiation-times/keepalives is interesting which I will look into. I imagine this will be a challenging one without diving in to the source code and network monitoring. If I manually add the route after, it works as expected. Commented Aug 7, 2018 at 20:33
  • Where in the question is it stated that there are multiple clients? It seems to be just two connections initiated by the same client. That it's possible to fix traffic by manually adding the route clearly shows it has nothing to do with timers/keepalives as the SAs are still there. And I don't see why that should be standard behavior (in particular with multiple clients, because how should a second client know which routes were created by the first client so it could delete exactly those). It just seems to be a limitation of this particular client with handling multiple connections. Commented Aug 8, 2018 at 7:22
  • @ecdsa I can reword it for the special case of being one piece of software instead of two, the same comments apply. The last tunnel wins in routes. As for the connection of the 1st tunnel still being established it depends in what the last tunnel might do, and in reality we do not have much data for that. You might end up with two concurrent separate connections, with one VPN inside of the other, or with only one, tipically (but not exclusivly) the last. And nothing prevents you to play with routes. I am using here a CheckPoint VPN in my Linux, and I do change substantially the routes. Commented Aug 8, 2018 at 7:42

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.