Bug #5355
openon Dynamic WAN IP (DHCP Client) it takes 10 minutes before Phase1 reconnects
0%
Description
2.2.4-RELEASE (i386)
built on Sat Jul 25 19:56:41 CDT 2015
FreeBSD 10.1-RELEASE-p15
It seems that charon do not care or is being not informed after WAN IP address changes
it try still use the old IP address and cannot bind this.
i see this messages after IP adress is changed: (the XXX.XXX.180.28 is an old IP address)
Logs are in reverse order!
...
Oct 26 09:43:49 charon: 09[IKE] <con1000|2> sending DPD request
Oct 26 09:43:49 charon: 09[IKE] <con1000|2> sending DPD request
Oct 26 09:43:48 charon: 05[NET] error writing to socket: Can't assign requested address
Oct 26 09:43:48 charon: 09[NET] <con1000|3> sending packet: from XXX.XXX.180.28500 to XXX.XXX.183.110500 (391 bytes)
Oct 26 09:43:48 charon: 09[IKE] <con1000|3> sending retransmit 4 of request message ID 0, seq 1
Oct 26 09:43:48 charon: 09[IKE] <con1000|3> sending retransmit 4 of request message ID 0, seq 1
Oct 26 09:43:39 charon: 09[IKE] <con1000|2> sending DPD request
Oct 26 09:43:39 charon: 09[IKE] <con1000|2> sending DPD request
Oct 26 09:43:29 charon: 09[IKE] <con1000|2> sending DPD request
Oct 26 09:43:29 charon: 09[IKE] <con1000|2> sending DPD request
Oct 26 09:43:24 charon: 05[NET] error writing to socket: Can't assign requested address
Oct 26 09:43:24 charon: 09[NET] <con1000|3> sending packet: from XXX.XXX.180.28500 to XXX.XXX.183.110500 (391 bytes)
Oct 26 09:43:24 charon: 09[IKE] <con1000|3> sending retransmit 3 of request message ID 0, seq 1
Oct 26 09:43:24 charon: 09[IKE] <con1000|3> sending retransmit 3 of request message ID 0, seq 1
Oct 26 09:43:19 charon: 09[IKE] <con1000|2> sending DPD request
Oct 26 09:43:19 charon: 09[IKE] <con1000|2> sending DPD request
...
after i while (10 - 15 minutes) IPsec realizes that the WAN address is changed and reconnects successfully:
...
Oct 26 09:53:32 charon: 12[IKE] <con1000|4> IKE_SA con10004 established between XXX.XXX.180.42[XXX]...XXX.XXX.183.110[XXX.XXX.183.110]
Oct 26 09:53:32 charon: 12[ENC] <con1000|4> received unknown vendor ID: 69:93:69:22:87:41:c6:d4:ca:09:4c:93:e2:42:c9:de:19:e7:b7:c6:00:00:00:05:00:00:05:00
Oct 26 09:53:32 charon: 12[IKE] <con1000|4> received NAT-T (RFC 3947) vendor ID
Oct 26 09:53:32 charon: 12[IKE] <con1000|4> received NAT-T (RFC 3947) vendor ID
Oct 26 09:53:32 charon: 12[IKE] <con1000|4> received DPD vendor ID
Oct 26 09:53:32 charon: 12[IKE] <con1000|4> received DPD vendor ID
Oct 26 09:53:32 charon: 12[ENC] <con1000|4> parsed AGGRESSIVE response 0 [ SA KE No ID HASH V V V NAT-D NAT-D ]
Oct 26 09:53:32 charon: 12[NET] <con1000|4> received packet: from XXX.XXX.183.110500 to XXX.XXX.180.42500 (388 bytes)
Oct 26 09:53:32 charon: 12[NET] <con1000|4> sending packet: from XXX.XXX.180.42500 to XXX.XXX.183.110500 (391 bytes)
Oct 26 09:53:32 charon: 12[ENC] <con1000|4> generating AGGRESSIVE request 0 [ SA KE No ID V V V V V V ]
Oct 26 09:53:32 charon: 12[IKE] <con1000|4> initiating Aggressive Mode IKE_SA con10004 to XXX.XXX.183.110
Oct 26 09:53:32 charon: 12[IKE] <con1000|4> initiating Aggressive Mode IKE_SA con10004 to XXX.XXX.183.110
Oct 26 09:53:32 charon: 16[KNL] creating acquire job for policy XXX.XXX.180.42/32|/0 === XXX.XXX.183.110/32|/0 with reqid {2}
Oct 26 09:51:15 charon: 16[IKE] <con1000|3> establishing IKE_SA failed, peer not responding
Oct 26 09:51:15 charon: 16[IKE] <con1000|3> establishing IKE_SA failed, peer not responding
Oct 26 09:51:15 charon: 16[IKE] <con1000|3> giving up after 5 retransmits
Oct 26 09:51:15 charon: 16[IKE] <con1000|3> giving up after 5 retransmits
Oct 26 09:50:00 charon: 05[NET] error writing to socket: Can't assign requested address
...
If more debug information is needed, I can provide this.
Files
Updated by Vitali Kari about 9 years ago
- File config-kx-old-fw1.cmn.local-20151029083535-pw-cleared.xml config-kx-old-fw1.cmn.local-20151029083535-pw-cleared.xml added
add config file with cleared pw
Updated by Chris Buechler over 8 years ago
- Assignee deleted (
Chris Buechler) - Affected Version changed from 2.2.4 to All
- Affected Architecture added
- Affected Architecture deleted (
i386)
The root cause here is likely that the SA that exists at the time of the IP change is still hanging around afterwards, and until it's torn down and it rekeys, it fails because its outer IP is gone.