[strongSwan-dev] Strongswan 5.3, IKEv2 & "make before break" - losing DNS configuration on Initiator after IKE lifetime expires

[Tobias Brunner]

Hi Ken,

> Questions
> 
> 1.  How to prevent Charon from removing the name server configuration
> from /etc/resolv.conf in the IKA_SA re-authentication case?

You currently can't.  I guess the resolve plugin could do some
refcounting for installed DNS servers (like we do for virtual IPs in
other plugins), which would workaround that problem.

> 2.  Why does the up/down script get invoked during IKE_SA
> re-authentication?  When “make before break” is enabled, the up/down
> script invocation seems backward/awkward.  That is, up/down is invoked
> with an ‘up’ notification at the initial establishment of the tunnel,
> then again with a second ‘up’ notification during the “make before
> break”, then finally with a ‘down’ notification even though the tunnel
> is up?!?

Reauthentication in IKEv2 creates a new IKE_SA and a new set of the
already existing CHILD_SAs.  Either the old stuff gets torn down first
(break-before-make) or that's done after completing the new stuff
(make-before-break).  Since every CHILD_SA gets an "up" event when it is
installed, and a "down" event when it is uninstalled what you see is a
logical consequence.  There is no relationship between the SAs unlike
when rekeying is used (where these events are suppressed), so you get an
initial "up" then an "up" for the newly created SA and then a "down" for
the old SA.  While a client that initiates a make-before-break
reauthentication could probably pretend there is some kind of
relationship between these SAs, a server can't do that without using
heuristics to detect reauthentications, like the ones we use for IKEv1
(which might not always work as expected).  If you don't _need_
reauthentication you should probably use rekeying instead.

> 3. Aside:  why does /usr/libexec/strongswan/_updown fail to find iptables?

No idea.  Perhaps your PATH does not include its location or the user
has no permission to access it (or perhaps due to some hardening
mechanism like SELinux/AppArmor).

Regards,
Tobias