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

[Alex K.]

After a few days of testing, I think you're perfectly right Paul.

Indeed, "auto" works as expected. With little exemption of VTI behavior (on
which I'll elaborate a little bit further), Libreswan indeed works like a
charm, PFS being the real culprit.

As a programmer, I understand that we indeed cannot bind() to an address
not yet present at the box, hence I placed a little bash script at
interface up/down events. And since it's already running the "whack
--listen" command, I've added "auto --add" & "auto --up" in there, either.
That brings the VTI interface up successfully. Yes, there might be a little
workaround to it (for re-establishing SA "whack --listen" is enough, as
shown by IP XFRM) but since we already MUST have a script, I think it's
perfectly acceptable to run both "whack" and "auto" commands in it.

Thank you, Paul

בתאריך 29 בינו' 2018 0:00,‏ "Paul Wouters" <paul at nohats.ca> כתב:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20180219/af8ec47e/attachment.html>