> > > 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?
No comments:
Post a Comment