[Swan] What ways're possible for bringing a VTI up?

[Paul Wouters]

On Sat, 27 Jan 2018, Alex K. wrote:

> After a few days of running debugs, I finally found the culprit, it was PFS (strangely enough, both sides agreed on
> each other proposals and brought SAs up, prior to re-negotiations, but that's another issue).

There are known interop issues on rekeying if PFS settings don't match.
One endpoint can accept pfs yes and no, but insist on sending no, and
one end can accept yes and no, but insist on sending yes. So at rekey
times things then break.

> Now, after configuring "pfs=no", the "auto" behaves as expected. With little exception, though - after
> re-negotiations, VTI never comes up by itself. I work around this issue by adding "vti-shared=yes", and now the
> whole thing behaves.

I'm not sure what you mean with re-negotiation. There is
re-authentication which starts a new IKE SA, and there is
rekeying that just rekeys (in IKEv2) without reauthenticate
using the CREATE_CHILD_SA exchange.

There might be an issue with routes if the connection is added, upped,
downed and upped again, as the VTI is created in add and removed in
down. This might require some improvements in the updown script for
handling this better.

> As there any debug options, I can use for troubleshoot VTI creation?

All VTI operations happen in the /usr/{local/}libexec/ipsec/_updown.netkey
shell script. So that should be easy to debug by adding some shell
commands there.

> As for "whack --listen", in fact the IP settings are configured statically so the IP address never changes, and
> yet, without "--listen", I do notice Pluto isn't listening (using "netstat -na | grep 500"). Maybe I'm wrong on
> that, so any suggestions will be welcomed.

The IP address has to exist on the machine before pluto can listen on
it. If pluto starts before the IP is added to the system, you need to
run "ipsec whack --listen" for pluto to re-examine the system for IPs
that got added or removed.

Paul