Hi Patricia, > 00[DMN] Starting IKEv2 charon daemon (strongSwan 4.4.1)
Can you try your scenario with a newer version? We actually changed several aspects of the MOBIKE implementation with 4.5.0 (some details below). > If I disable the eth0 interface, strongswan updates at first the IP > available pool sending an INFORMATIONAL[ N(ADD_4_ADDR) ] from the eth1 > interface (the unique interface available) and then sends the update > address (INFORMATIONAL [ N(UPD_SA_ADDR) N(NATD_S_IP) N(NATD_D_IP) > N(COOKIE2) ]. The first INFORMATIONAL exchange you are seeing is a path probe message to check if a specific combination of local and remote addresses is valid. Before 4.5.0 ADDITIONAL_IP*_ADDRESS payloads were added to these exchanges. In newer releases you would only see empty INFORMATIONAL exchanges and then the exchange containing the UPDATE_SA_ADDRESSES etc. > Why it doesn't send the N(UPD_SA_ADDR) first of all? Charon first checks for a valid path between the two peers. Only if it finds one it sends an UPDATE_SA_ADDRESSES payload to update the endpoints of the IPsec SA. > The responder peer can accept packets from other IPs without receive > the N(UPD_SA_ADDR)? I'm not sure what you are referring to here. If you refer to the dynamic updates as described in RFC 5996, Section 2.23, then the answer is no since MOBIKE explicitly disallows updates for messages that do not contain an UPDATE_SA_ADDRESSES payload. For ESP packets the answer might be yes, that is, responders may accept authenticated packets from a different IP address than originally configured. But charon actually does not update the locally installed IPsec policies until it sends the UPD_SA_ADDR. > Finally, when the initiator peer has only one interface available and it > sends the INFORMATIONAL[ N(ADD_4_ADDR) ] to update the list, why doesn't > send a INFORMATIONAL[ N(NO_ADD_ADDR) ]? As I wrote above these path probe exchanges do not contain any ADD_*_ADDR or NO_ADD_ADDR payloads in newer releases. That an ADD_*_ADDR payload was added instead of a NO_ADD_ADDR payload was simply a bug. Regards, Tobias _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
