Project

General

Profile

Actions

Bug #5355

open

on Dynamic WAN IP (DHCP Client) it takes 10 minutes before Phase1 reconnects

Added by Vitali Kari about 9 years ago. Updated over 8 years ago.

Status:
New
Priority:
High
Assignee:
-
Category:
IPsec
Target version:
-
Start date:
10/29/2015
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:

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

Actions #2

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.

Actions

Also available in: Atom PDF