<div dir="auto">After a few days of testing, I think you're perfectly right Paul.<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Thank you, Paul</div></div><div class="gmail_extra"><br><div class="gmail_quote">בתאריך 29 בינו' 2018 0:00,‏ "Paul Wouters" <<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>> כתב:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, 27 Jan 2018, Alex K. wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
After a few days of running debugs, I finally found the culprit, it was PFS (strangely enough, both sides agreed on<br>
each other proposals and brought SAs up, prior to re-negotiations, but that's another issue).<br>
</blockquote>
<br>
There are known interop issues on rekeying if PFS settings don't match.<br>
One endpoint can accept pfs yes and no, but insist on sending no, and<br>
one end can accept yes and no, but insist on sending yes. So at rekey<br>
times things then break.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now, after configuring "pfs=no", the "auto" behaves as expected. With little exception, though - after<br>
re-negotiations, VTI never comes up by itself. I work around this issue by adding "vti-shared=yes", and now the<br>
whole thing behaves.<br>
</blockquote>
<br>
I'm not sure what you mean with re-negotiation. There is<br>
re-authentication which starts a new IKE SA, and there is<br>
rekeying that just rekeys (in IKEv2) without reauthenticate<br>
using the CREATE_CHILD_SA exchange.<br>
<br>
There might be an issue with routes if the connection is added, upped,<br>
downed and upped again, as the VTI is created in add and removed in<br>
down. This might require some improvements in the updown script for<br>
handling this better.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As there any debug options, I can use for troubleshoot VTI creation?<br>
</blockquote>
<br>
All VTI operations happen in the /usr/{local/}libexec/ipsec/_up<wbr>down.netkey<br>
shell script. So that should be easy to debug by adding some shell<br>
commands there.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As for "whack --listen", in fact the IP settings are configured statically so the IP address never changes, and<br>
yet, without "--listen", I do notice Pluto isn't listening (using "netstat -na | grep 500"). Maybe I'm wrong on<br>
that, so any suggestions will be welcomed.<br>
</blockquote>
<br>
The IP address has to exist on the machine before pluto can listen on<br>
it. If pluto starts before the IP is added to the system, you need to<br>
run "ipsec whack --listen" for pluto to re-examine the system for IPs<br>
that got added or removed.<br>
<br>
Paul<br>
</blockquote></div></div>