On Mon, Jun 08, 2020 at 05:28:48PM +0000, Leclerc, Sebastien wrote: > After an upgrade to 6.7 on amd64 this weekend, iked keeps reconnecting every > 8 minutes, but only for one tunnel, to a Watchguard firewall. The tunnel has > been functioning properly for 5 years. Other tunnels to OpenBSD devices do > not reconnect every 8 minutes. I confirmed there a no dropped packets by pf. > Here is part of the log (anonymized) : > > Jun 8 12:10:22 hv-fw-inf-02 iked[50153]: ikev2_init_ike_sa: initiating > "TUNNELNAME" > Jun 8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: send > IKE_SA_INIT req 0 peer 192.0.2.199:500 local 192.0.2.2:500, 334 bytes > Jun 8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: recv > IKE_SA_INIT res 0 peer 192.0.2.199:500 local 192.0.2.2:500, 296 bytes, policy > 'TUNNELNAME' > Jun 8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: send > IKE_AUTH req 1 peer 192.0.2.199:500 local 192.0.2.2:500, 252 bytes > Jun 8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: recv > IKE_AUTH res 1 peer 192.0.2.199:500 local 192.0.2.2:500, 204 bytes, policy > 'TUNNELNAME' > Jun 8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: > ikev2_childsa_enable: loaded SPIs: 0x4cd06a6a, 0xa749d359 > Jun 8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: > ikev2_childsa_enable: loaded flows: ESP-10.0.1.0/24=10.0.100.0/24(0), > ESP-10.0.1.0/24=10.0.150.0/24(0), ESP-192.0.2.2/32=192.0.2.199/32(0) > Jun 8 12:10:22 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: established > peer 192.0.2.199:500[IPV4/192.0.2.199] local 192.0.2.2:500[IPV4/192.0.2.2] > policy 'TUNNELNAME' as initiator > Jun 8 12:15:24 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: retransmit > 1 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 > Jun 8 12:15:28 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: retransmit > 2 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 > Jun 8 12:15:36 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: retransmit > 3 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 > Jun 8 12:15:52 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: retransmit > 4 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 > Jun 8 12:16:24 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: retransmit > 5 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 > Jun 8 12:17:28 hv-fw-inf-02 iked[50153]: spi=0x73cd01a5c65aa870: sa_free: > retransmit limit reached > Jun 8 12:18:22 hv-fw-inf-02 iked[50153]: ikev2_init_ike_sa: initiating > "TUNNELNAME" > Jun 8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: send > IKE_SA_INIT req 0 peer 192.0.2.199:500 local 192.0.2.2:500, 334 bytes > Jun 8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: recv > IKE_SA_INIT res 0 peer 192.0.2.199:500 local 192.0.2.2:500, 296 bytes, policy > 'TUNNELNAME' > Jun 8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: send > IKE_AUTH req 1 peer 192.0.2.199:500 local 192.0.2.2:500, 252 bytes > Jun 8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: recv > IKE_AUTH res 1 peer 192.0.2.199:500 local 192.0.2.2:500, 204 bytes, policy > 'TUNNELNAME' > Jun 8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: > ikev2_childsa_enable: loaded SPIs: 0x4cd06a6b, 0xf20c662c > Jun 8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: > ikev2_childsa_enable: loaded flows: ESP-10.0.1.0/24=10.0.100.0/24(0), > ESP-10.0.1.0/24=10.0.150.0/24(0), ESP-192.0.2.2/32=192.0.2.199/32(0) > Jun 8 12:18:22 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: established > peer 192.0.2.199:500[IPV4/192.0.2.199] local 192.0.2.2:500[IPV4/192.0.2.2] > policy 'TUNNELNAME' as initiator > Jun 8 12:23:24 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: retransmit > 1 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 > Jun 8 12:23:28 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: retransmit > 2 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 > Jun 8 12:23:37 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: retransmit > 3 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 > Jun 8 12:23:53 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: retransmit > 4 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 > Jun 8 12:24:25 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: retransmit > 5 INFORMATIONAL req 2 peer 192.0.2.199:500 local 192.0.2.2:500 > Jun 8 12:25:29 hv-fw-inf-02 iked[50153]: spi=0xa84faba012c73dce: sa_free: > retransmit limit reached > > And here is the configuration of the tunnel : > > ikev2 "TUNNELNAME" active esp \ > from 10.0.1.0/24 to 10.0.100.0/24 \ > from 10.0.1.0/24 to 10.0.150.0/24 \ > from 192.0.2.2/32 to 192.0.2.199/32 \ > local 192.0.2.2 peer 192.0.2.199 \ > ikesa auth hmac-sha1 enc aes-128 group grp5 \ > childsa auth hmac-sha1 enc aes-128 group grp5 \ > srcid 192.0.2.2 dstid 192.0.2.199 \ > ikelifetime 28800 \ > psk THISISTHEPSK > > Other tunnels have basically the same configuration, only omitting ikesa, > childsa and ikelifetime parameters. > I don't have control over the Watchguard firewall. > Any idea what could cause this?
Those INFORMATIONAL messages are the dead peer detection. It looks like the Watchguard firwall ignores them, which causes the reconnect after a retransmit timeout (as intended). Can you see the outgoing INFORMATIONAL pings in tcpdump? > > OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun 4 09:55:08 MDT 2020 > > r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > Sébastien Leclerc >
