[Swan-dev] SA deletion and unrouting/rerouting issue

[Oleg Rosowiecki]

Dear Developers,

(I've discussed this preliminary with Paul Wouters today and he suggested
that I'd share this on the mailing list.)

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.

I did some log and code analysis and it looks as follows.

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.

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).

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.

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...

What do you think?
Thanks,
Oleg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20220712/d0d27758/attachment.htm>