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

[Anthony DeRobertis]

On 11/30/20 4:02 PM, Paul Wouters wrote:

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

I think I didn't explain enough -- the only way Libreswan finds out
about that session ID is that its passed as the xauth password (and
Libreswan then checks it via PAM). This is a session ID (a UUID)
generated by a different system, obtained by the client, and the
presented to Libreswan.

This is in a roadwarrior connection, with left/right=%any config with an
addresspool, with a bunch of clients connecting to the same Libreswan
"conn" block. They identify with a username (their client ID) and
"password" (the session ID, from the other system).

The updown script is integrating with that other system, which needs to
know when the VPN connection for each if its sessions is up/down.

>
>> 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://urldefense.com/v3/__https://github.com/Telmate/libreswan/commit/960533723fb6c7666636251679ddf22195a2e1b2__;!!Cct94QWR6ksoXOc!FIeKXujtKbLdNmfNDiMg_wVpCkSYoE3iDzWXGVbk7xLo_UadxC5HG2pPTnEOdzKNP4BAMg$
>
>
> 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,

In our case, we just want it to analyze why the connection dropped (and
eventually to figure out the time interval in which the VPN stopped
working).

Once a connection is DPD'd, we never want it to come back. It needs to
go through that other system again in order to reconnect (and will get a
different session ID). We've actually seen an issue around that which I
haven't fully tracked down yet (where Libreswan tries to re-initiate the
connection, and ultimately gets confused and forgets about one of the
IPs, this is in 3.32).

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

That makes sense, we're only using roadwarrior connections. I'll take a
look at fixing it to work for static connections as well.


This electronic mail transmission is intended for the use of the individual or entity to which it is addressed and may contain confidential information belonging to the sender. If you have received this transmission in error, please notify the sender immediately and delete the original message. Unless explicitly noted above, this e-mail should not, in any way, be considered evidence of the sender’s intent to be bound to any agreement.