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

Paul Wouters paul at nohats.ca
Tue Dec 1 00:36:04 UTC 2020

On Mon, 30 Nov 2020, Anthony DeRobertis 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.

How are you getting the XAUTH password into pluto? There are three
methods. One is via a secrets file with XAUTH entry. The second is
via ipsec whack --initiate --name XXX --xauthpass PASSWORD. and the
third is via ipsec whack --initiate without --xauthpass and waiting
for the whack prompt and then type it in.

If you use whack, you can also just add a new --session SESSIONID
(even if that means using --xauthpass PASSWD --session PASSWD with
the same argument)

Only if you use a temp secrets file entry with XAUTH, then adding a
whack --sessionid would not help.

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

Okay. So let's add it but then we should also cover some other cases
such as the DPD RESTART event, received delete from peer, and received
delete from administrator as reasons, and use a little more generic
named variable. It should probably go into c->temp_vars, so that any
instantiating of the connection wouldn't accidentally copy the reason.

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

More information about the Swan-dev mailing list