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 _______________________________________________ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan