Thanks Martin. Some follow-ups below... >By default, strongSwan keeps the IKE_SA up, unless the strongswan.conf >option charon.close_ike_on_child_failure is set to yes.
Well, whether close_ike_on_child_failure = yes or = no, does strongSwan keep trying to start the connection? Or is some manual intervention required? We have auto=start, dpdaction=restart, keyingtries=%forever, rekey=yes, if that matters... >I've pushed a patch [1] that improves the situation by just ignoring the >virtual IP, changing the behavior to the description below. We use install_virtual_ip = no and the up/down script/PLUTO_MY_SOURCEIP to learn of the assigned IP address. So I assume before your patch, the up/down script would be called with PLUTO_MY_SOURCEIP set to 0.0.0.0, and I wonder what else would happen? Would there be an IPSEC SA created? With install_virtual_ip = no and your patch, I assume no IPSEC SA is created and no up/down script is called? Is it true? >> 3. the SeGW does not generates a configuration payload reply nor a >> failure notification (e.g., it does not provide any support for >> configuration payload) > >It depends on how the responder narrows the Traffic Selector for the >client. If it gets narrowed to the physical IP (or something that >contains it), the CHILD_SA will get established using this IP for the >local IPsec policy. Sorry, I don't follow what you mean by "the physical IP (or something that contains it)". I don't understand what IP could be used or assumed, if the SeGW can not fulfill the client's request for an IP address assignment. >-----Original Message----- >From: Martin Willi [mailto:[email protected]] >Sent: Tuesday, June 26, 2012 12:04 PM >To: Pisano, Stephen G (Stephen) >Cc: [email protected] >Subject: Re: [strongSwan] Configuration Payload for IP Address Assignment >Error Cases > >Hi Stephen, > >> 2. the SeGW replies with an INTERNAL_ADDRESS_FAILURE notification > >This is how a responder should behave if it doesn't hand out internal >addresses. As a client, strongSwan does not create an associated >CHILD_SA, because the gateway usually does not include the SA/TS >payloads with this error. > >By default, strongSwan keeps the IKE_SA up, unless the strongswan.conf >option charon.close_ike_on_child_failure is set to yes. > >> 1. the SeGW replies with an configuration payload reply containing and >> "empty" address (length = 0) > >strongSwan interprets this as a 0.0.0.0 address, but still tries to >install it. This seems to be rather problematic with our netlink kernel >interface. The kernel seems to ACK the installation, but does never >confirm it by sending a notification. As we have to wait for this >confirmation to go on with the CHILD_SA installation, the thread hangs. > >I've pushed a patch [1] that improves the situation by just ignoring the >virtual IP, changing the behavior to the description below. > >> 3. the SeGW does not generates a configuration payload reply nor a >> failure notification (e.g., it does not provide any support for >> configuration payload) > >It depends on how the responder narrows the Traffic Selector for the >client. If it gets narrowed to the physical IP (or something that >contains it), the CHILD_SA will get established using this IP for the >local IPsec policy. > >Regards >Martin > >[1]http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=5def45b8 _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
