On Tue, Jun 09, 2020 at 01:11:38PM +0000, Leclerc, Sebastien wrote: > > > > 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 > > > > > > 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? > > > > Is there a tcpdump filter I can use to see this? If I filter only by the > > other endpoint IP, I see > > all the encrypted packets, without any way to know which ones are the > > INFORMATIONAL packets... > > I found it, INFORMATIONAL packets are sent on the external interface : > > # tcpdump -nnttti bge0 host 192.0.2.199 and udp port 500 > tcpdump: listening on bge0, link-type EN10MB > Jun 09 08:56:38.482789 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange > INFORMATIONAL > cookie: 46a71107f0a9486e->bccb051ab894a056 msgid: 00000002 len: 76 > Jun 09 08:58:36.363323 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange > IKE_SA_INIT > cookie: 844a443d5f49aaa5->0000000000000000 msgid: 00000000 len: 334 > Jun 09 08:58:36.399046 192.0.2.199.500 > 192.0.2.2.500: isakmp v2.0 exchange > IKE_SA_INIT > cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 00000000 len: 296 > Jun 09 08:58:36.409161 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange > IKE_AUTH > cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 00000001 len: 252 > Jun 09 08:58:36.442159 192.0.2.199.500 > 192.0.2.2.500: isakmp v2.0 exchange > INFORMATIONAL > cookie: 9225af3bb74cf5a1->b18ab2b3e82cdcdd msgid: 00000000 len: 76 > Jun 09 08:58:36.442161 192.0.2.199.500 > 192.0.2.2.500: isakmp v2.0 exchange > IKE_AUTH > cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 00000001 len: 204 > Jun 09 09:03:36.498344 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange > INFORMATIONAL > cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 00000002 len: 76 > Jun 09 09:03:38.507692 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange > INFORMATIONAL > cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 00000002 len: 76 > Jun 09 09:03:42.517680 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange > INFORMATIONAL > cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 00000002 len: 76 > Jun 09 09:03:50.527778 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange > INFORMATIONAL > cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 00000002 len: 76 > Jun 09 09:04:06.537979 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange > INFORMATIONAL > cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 00000002 len: 76 > Jun 09 09:04:38.548773 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange > INFORMATIONAL > cookie: 844a443d5f49aaa5->953838ec88d3c79e msgid: 00000002 len: 76 > Jun 09 09:06:36.448688 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange > IKE_SA_INIT > cookie: 883961cb08ca064c->0000000000000000 msgid: 00000000 len: 334 > Jun 09 09:06:36.487738 192.0.2.199.500 > 192.0.2.2.500: isakmp v2.0 exchange > IKE_SA_INIT > cookie: 883961cb08ca064c->4485c3c2a69d42d1 msgid: 00000000 len: 296 > Jun 09 09:06:36.497831 192.0.2.2.500 > 192.0.2.199.500: isakmp v2.0 exchange > IKE_AUTH > cookie: 883961cb08ca064c->4485c3c2a69d42d1 msgid: 00000001 len: 252 > Jun 09 09:06:36.533002 192.0.2.199.500 > 192.0.2.2.500: isakmp v2.0 exchange > INFORMATIONAL > cookie: bbdef3192a7832fc->8b3cbbe39d3ae970 msgid: 00000000 len: 76 > Jun 09 09:06:36.533004 192.0.2.199.500 > 192.0.2.2.500: isakmp v2.0 exchange > IKE_AUTH > cookie: 883961cb08ca064c->4485c3c2a69d42d1 msgid: 00000001 len: 204 > > Is there anything that may have changed between 6.6 and 6.7 concerning those > packets, that > may cause the Watchguard to not accept them? >
Before 6.7 iked didn't start DPD in this particular case. It kicks in if the tunnel is up and there haven't been any incoming ESP packets in the last 5 minutes. A possible workaround would be to ping through the tunnel to have at least one incoming packet every 5 minutes.
