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