<div dir="ltr">Dear Developers,<br><br>(I've discussed this preliminary with Paul Wouters today and he suggested that I'd share this on the mailing list.)<br><br>I'm running Libreswan as an XAUTH/ModeCfg client (IKEv1). The tunnel gets established fine, my client gets a remotely assigned address (10.30.0.6). After a while, the tunnel gets dropped by the ModeCfg server. This is a result of a conscious user action on the server, i.e. a config change that mandates tunnel reset. The remote party sends Libreswan delete payloads: for IPSec SA and for ISAKMP SA (in that order). Libreswan tears down the SAs and renegotiates the tunnel straight away. What happens though is that this time the ModeCfg server assigns it a different address: 10.30.0.4. And this causes a lot of trouble. This new address is never assigned to the interface and the corresponding route(s) never get added. The old address and routes are retained. The connectivity to the remote subnet is effectively dead. Also, there are inconsistencies in XFRM policy database, as it contains entries for both 10.30.0.6 and .4.<br><br>I did some log and code analysis and it looks as follows.<br><br>On tunnel deletion, Libreswan fires _updown only with the "down-client" verb; there is no script invocation with "unroute-client". So the previous routes and the server-assigned address remain in place. From code analysis, I can only see one remote possibility where pluto *might* trigger the "unroute"-"route" sequence as well (route_and_eroute() function), but this isn't happening either.<br><br>I also noticed that teardown_ipsec_sa() (formerly delete_ipsec_sa()) *may* unroute connections while deleting them. On the following condition: the policy is opportunistic (doesn't apply in my case) or the policy is "don't rekey". I did set my connection to rekey. I'm having other IKE rekeying issues and I'm effectively preventing IKE SAs from surviving beyond their lifetime (restarting the tunnel programmatically from outside Libreswan). I left "rekey" in place just to have IPSec SA rekey, albeit infrequently (8h).<br><br>I'm aware that the XAUTH+rekey combination isn't very welcome (as mentioned in ipsec.conf), but my impression has been that it isn't technically impossible to do XAUTH+rekey either. What I think I've bumped into is a de-facto limitation that prevents this combination from working, even if the event that triggers problems isn't exactly a rekey (the remote party just deletes the SAs). The combination has probably never been tested since it's been advised against.<br><br>Does this deserve attention to maybe adjust code to allow this, or the answer is to set rekey=no and forget about it? The code I've been looking at is mostly delete_ipsec_sa() (now refactored into teardown_ipsec_sa()) and route_and_eroute(). These functions are pretty much IKE version agnostic. I know IKEv2 also supports this kind of server-assigned addresses, so I wonder if IKEv2 could suffer from this limitation as well...<br><br>What do you think? <br>Thanks,<br>Oleg<br></div>