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.

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.

  • 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. – Christian Aug 7 '18 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. – ecdsa Aug 8 '18 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. – Rui F Ribeiro Aug 8 '18 at 7:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.