2

I have a linux (netkey) instance with openswan installed, the instance has two connection to the same IPSec peer that needs to act as redundant connections. both connections' properties are the same (except for the peer's IP addresses and the right id)...

ipsec version is Linux Openswan U2.6.37/K3.2.0-65-generic (netkey)

conn con1
    dpdtimeout=25
    salifetime=28800s
    overlapip=yes
    ike=aes128-sha1
    rightsubnets=172.28.0.0/24
    dpddelay=30
    leftid=<linux box id>
    pfs=no
    rightid=<peer's id>
    leftsubnets=172.28.2.0/24
    phase2alg=aes128-sha1
    dpdaction=restart_by_peer
    auto=ignore
    forceencaps=yes
    keyingtries=3
    left=<linux ip>
    ikelifetime=86400s
    right=<peer's public IP A>

conn con2
    dpdtimeout=25
    salifetime=28800s
    overlapip=yes
    ike=aes128-sha1
    rightsubnets=172.28.0.0/24
    dpddelay=30
    leftid=<linux box id>
    pfs=no
    rightid=<peer's id>
    leftsubnets=172.28.2.0/24
    phase2alg=aes128-sha1
    dpdaction=restart_by_peer
    auto=ignore
    forceencaps=yes
    keyingtries=3
    left=<linux ip>
    ikelifetime=86400s
    right=<peer's public IP B>

Since openswan installs the xfrm policy as part of Quick Mode negotiation, one of the connection will always fail QuickMode since linux doesn't allow 2 xfrm policies that have the same classification (note my left and right subnets are the same).

This by itself is not the issue.

My question is how can I use openswan to create an automated quick failover behaviour between the two connections that will switch to the 2nd connection once the first one fails (due to DPD kicking in for example).

I tried using dpdaction=restart or restart_by_peer but it doesn't delete the original xfrm policy upon restart of the connection (is this a bug?) and therefore doesn't allow the 2nd connection to kick in. and dpdaction=clean will delete the xfrm policy but will not restart the connection. is there a recommended approach for how to setup these connections so they'll act as a redundant pair?

Is there a way to tell pluto to not install routing policies and offload xfrm policy installation to a side process that will manage xfrm policies.

Amir
  • 21
  • 1
  • 4
  • Don't use quick mode, it is not secure. Also don't use IKEv1, it is also not secure (at least, the NSA has broken it). – Michael Hampton Sep 21 '14 at 07:55
  • will ikev2 provide means for handling redundant connections? – Amir Sep 21 '14 at 15:27
  • HA/Failover isn't natively supported on Openswan; however, you can still accomplish this by using a method such as demonstrated in this video https://youtu.be/5aARFvO8aVo – user1998671 Nov 04 '16 at 21:59

0 Answers0