0

I have a IPSec tunnel between two machines, one of which (the initiator) has two interfaces (data0 and data1). The data0 interfaces has a metric of 100 and the data1 has 70, so when initially creating a connection the data1 interfaces is used because it has better metric.

After the connection is up and I take down the data1 interface's ip the connection should be reestablished with a new CHILD_SA and a new virtual ip using the data0 interface.

But that doesn't happen. What happens is the data0 inteface tries to keep the first CHILD_SA alive sending DPD requests infinitely.

How can I make the CHILD_SA get closed and a new one to be created where the data0 interface is used ?

data0 - 10.3.219.27/16
data1 - 10.3.219.28/16
initiator's vti0 ip: 173.164.0.1
responder's vti0 ip: 192.168.169.1

The initiators' config DPD and rekeying config:

version=1
keyingtries=0
aggressive=no
dpd_delay=10
dpd_timeout=50
policies=yes
dpd_action=restart
close_action=start

Journalctl logs in the pastecode: https://pastecode.xyz/view/3f89dfdd

ipsec statusall before I take down the interface:

Listening IP addresses:
  10.3.219.27
  10.3.219.28
  173.164.0.1
Connections:
   conn-vti0:  0.0.0.0...94.26.49.38  IKEv1, dpddelay=10s
   conn-vti0:   local:  [tve53] uses pre-shared key authentication
   conn-vti0:   local:  [loc-2] uses XAuth authentication: any with XAuth identity 'config4'
   conn-vti0:   remote: [fortinetconfig4] uses pre-shared key authentication
     ch_vti0:   child:  dynamic === 192.168.169.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
   conn-vti0[80]: ESTABLISHED 15 minutes ago, 10.3.219.28[tve53]...94.26.49.38[fortinetconfig4]
   conn-vti0[80]: IKEv1 SPIs: ac8dfb7c5f24676a_i* 1fc2d2d23231b5ed_r, rekeying in 3 hours
   conn-vti0[80]: IKE proposal: AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_4096
     ch_vti0{51}:  INSTALLED, TUNNEL, reqid 32, ESP in UDP SPIs: c44c6569_i bda13b22_o
     ch_vti0{51}:  AES_CBC_128/HMAC_SHA2_256_128/ECP_384_BP, 4276555 bytes_i (9500 pkts, 0s ago), 1913489 bytes_o (8751 pkts, 0s ago), rekeying in 39 minutes
     ch_vti0{51}:   173.164.0.1/32 === 192.168.169.0/24

ipsec statusall after I do it:

Listening IP addresses:
  10.3.219.27
  173.164.0.1
Connections:
   conn-vti0:  0.0.0.0...94.26.49.38  IKEv1, dpddelay=10s
   conn-vti0:   local:  [tve53] uses pre-shared key authentication
   conn-vti0:   local:  [loc-2] uses XAuth authentication: any with XAuth identity 'config4'
   conn-vti0:   remote: [fortinetconfig4] uses pre-shared key authentication
     ch_vti0:   child:  dynamic === 192.168.169.0/24 TUNNEL, dpdaction=restart
Security Associations (2 up, 0 connecting):
   conn-vti0[81]: ESTABLISHED 8 seconds ago, 10.3.219.27[tve53]...94.26.49.38[fortinetconfig4]
   conn-vti0[81]: IKEv1 SPIs: 8425e35cef48f8b5_i* 490188becb87d6ad_r, rekeying in 3 hours
   conn-vti0[81]: IKE proposal: AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_4096
     ch_vti0{51}:  INSTALLED, TUNNEL, reqid 32, ESP in UDP SPIs: c44c6569_i bda13b22_o
     ch_vti0{51}:  AES_CBC_128/HMAC_SHA2_256_128/ECP_384_BP, 7958755 bytes_i (17317 pkts, 9s ago), 3480780 bytes_o (15870 pkts, 9s ago), rekeying in 24 minutes
     ch_vti0{51}:   173.164.0.1/32 === 192.168.169.0/24
   conn-vti0[80]: REKEYING, 10.3.219.27[tve53]...94.26.49.38[fortinetconfig4]
   conn-vti0[80]: IKEv1 SPIs: ac8dfb7c5f24676a_i* 1fc2d2d23231b5ed_r
   conn-vti0[80]: IKE proposal: AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_4096
1

When you want to implement failover on WAN connections, you need to configure interfaces with the correct metric/priority, and then manually switch over, or implement a ping/http connect automatic switch over... but also suitable static routes.

When interface data1 goes down, both ipv4 and ipv6 IP's must change over/renew:

ip a (newer tool)
ifconfig -a (older tool)

and the route needs to change too, so that traffic uses data0. Check with:

ip r (using newer ip tool)
route -n (older command)

Specifically, check for any left over IP's, for example, an ipv6 IP, even if the ipv4 IP has gone.

  • It does change, the route -n command shows that before me taking down the data1 interface the default route is through it. And after I take it, the default route is through data0. – Kostadin Krushkov Oct 2 at 7:01
  • 1
    Ok, and are there any specific (eg. /32) routes left over? I ask because I had an issue with VPN client that created single static IP route, so that VPN did not use the default route (which changed correctly). Disabled the static route entry in client, and it then used the default route. – sarlacii Oct 2 at 8:11
  • No, but I found that the problem came from the ipv6 address, because it still had one it tries to reconnect. After I removed it i connected properly. – Kostadin Krushkov Oct 2 at 9:05
  • Aha, perfect. Glad you got it sorted. I'll edit my answer. – sarlacii Oct 2 at 11:53

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.