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

[Alex K.]

Hello Paul,

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

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.

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

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.

Thank you.


בתאריך 23 בינו' 2018 4:15 AM,‏ "Paul Wouters" <paul at nohats.ca> כתב:

> On Fri, 19 Jan 2018, Alex K. wrote:
>
> I tried to delete SAs on both sides (till there's no SA shown on my side,
>> using "ip xfrm state"), playing with right/left subnets and then
>> generating traffic accordingly (now the subnets are 0.0.0.0/0), issuing
>> "ipsec whack --listen", since sometimes I bring the tunnel down by
>> unplugging the cable and then Pluto does not resume listening
>> automatically. All to no avail, unfortunately. As far as I remember, debugs
>> on Cisco side does not indicate incoming re-establishment tries. At
>> least, not full IKE negotiations (maybe there's something, but very
>> limited at most). What I discovered, is that re-adding the connection and
>> then using "--up" will bring it up, restarting the IPSEC service
>> will also bring it up automatically and (surprisingly, to some extent)
>> shutting Pluto down ("ipsec whack --shutdown").
>>
>> Maybe I'm doing something wrong, that's why I'm seeking help here. Thank
>> you.
>>
>
> auto=start should work. If you lose and gain the same IP, you should not
> need whack --listen. If an IP changes, you will need whack --listen to
> start using the new IP. Then you should also have left=%defaultroute so
> that pluto knows it needs to re-orient this connection.
>
> I recommend you test with 3.23rc4 (from download.libreswan.org/develop
> ment/) as we
> did make some changes to the auto= behaviour.
>
> Paul
>
> בתאריך 19 בינו' 2018 4:11 AM, "Paul Wouters" <paul at nohats.ca> כתב:
>>       On Thu, 18 Jan 2018, Alex K. wrote:
>>
>>             What are the possible ways to bring a Libreswan VTI up?
>>
>>             Let me elaborate the situation a little bit - I have a
>> Libreswan 3.21 compiled from sources on Debian Stretch as.
>>             Anyhow, I have a
>>             basic VTI setup according to the example on Libreswan website.
>>
>>
>>       Using the vti options in the connection is the best way. Then,
>>       the VTI interfaces are created/deleted when the tunnels go up
>>       or down. You can do things manually too using the "ip tun"
>>       command, but I wouldn't recommend it.
>>
>>             On system startup, everything works just fine. The question
>> is, how can I bring the tunnel up (after say, a restart
>>             to the opposite
>>             end), *without* manual intervention?
>>
>>             Sure, I can always get to the box, get the terminal up and
>> run "sudo ipsec auto --add vti1", following "--up". But
>>             say I'm not on
>>             site right now or wish to plan for better VPN recovery setup,
>> what are my possibilities? Can some traffic bring the
>>             VTI up? Is there
>>             a keep alive/always up setting?
>>
>>
>>       If you have auto=start, whenever the tunnel goes down, it will
>>       automatically try to restart. Even if the other end send you
>>       a delete request.
>>
>>       When using auto=ondemand, if the tunnel goes down, it will only
>>       be brought back up when there is traffic to trigger the tunnel.
>>
>>       Paul
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20180127/742e7360/attachment.html>