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 _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
