[Swan-dev] Passing xauth password, DPD status to updown script

[Paul Wouters]

On Mon, 30 Nov 2020, Anthony DeRobertis wrote:

> Quick background, on our client devices, authentication is done via a
> separate program, which returns a session ID. Our clients then their
> client ID & that session ID via IKEv1 xauth, as the username and
> "password". We need to get it passed out of Libreswan to track session
> up/down, and so (locally) we've patched Libreswan to add the "password"
> to the updown script environment.
>
> Our local patch isn't something that can be upstreamed, but I'm
> wondering if a cleaned up version, controlled by a config option
> (default do not export it, of course), could be.
>
> https://github.com/Telmate/libreswan/commit/1f5cd32f22e00ef6ce7ce091977079b2fc15975f

In general we could support something like this. But better would be if
we could support your generic method of taking a session id and
displaying that in the updown?

Then the fact that you use that as password is your own thing only. Eg
if we added: ipsec whack --sessionid <id> --name <connname>
Then we can expose that in updown. This way there is no relationship
with password. The fact that you also use if for that is up to you.

> We also track if the connection was shut down due to Libreswan's DPD
> detecting the client dead, and export that to the updown script as well:
>
> https://github.com/Telmate/libreswan/commit/960533723fb6c7666636251679ddf22195a2e1b2

We almost added something like this a few weeks ago, but there is a
catch here. People who want this information tend to want to use it
to re-trigger the connection, and modifying the connection state
of the same connection within that connection's updown face is not
safe. Also, with the revive code added to 3.28 the most common case
for this was addressed (auto=start + receiving a delete would not
bring the tunnel back up, but as of 3.28 it does)

We also just added auto=keep, which will be in libreswan 4.2, which
has a meaning of auto=add, but if the remote peer initiates to you,
then from then on it treats it like auto=start (eg it will revive
on receiving a delete). This is useful when the remote peer is behind
NAT and has to be the initiator, but you want the tunnel to always
remain up. Once it goes down (via delete request or DPD), it tries
to quickly initiate a new one over the existing NAT mapping.

So before we do this, do the above changes already address why you
want this information in the updown phase?

Note that the 2nd patch looks to have an issue still. It seems to be
meant for the server side of roadwarrior connections. those connections,
once a delete is received, are deleted because they are instances. But
static site-to-site connections don't have their connections deleted,
those are re-used. And your patch does not seem to again clear the
c->dpd_killed value in that case.

Paul