On Wed, Jun 14, 2017 at 7:11 AM, Paul Wouters <[email protected]> wrote:
> On Tue, 13 Jun 2017, Evan Wheeler wrote: > > My understanding is that the "negotiationshunt=passthrough" option would >> allow traffic to pass in the clear between two hosts >> while the hosts are negotiating during Phase 1, and >> "negotiationshunt=passthrough" would allow packets to pass in the clear >> after negotiations had failed due to the differing PSK values on each >> host, but a simple ping test between the hosts shows no >> ICMP packets passing in either direction according to Wireshark. All I >> see are ISAKMP packets. Here are the contents of my >> ipsec.conf file for both hosts: >> > > That is the idea, yes. > > conn mytunnel >> left=192.168.1.2 >> right=192.168.1.3 >> authby=secret >> auto=start >> failureshunt=passthrough >> negotiationshunt=passthrough >> keyingtries=1 >> retransmit-timeout=3s >> >> Am I missing something ? Should failureshunt and negotiationshunt work in >> this configuration? >> > > That should do it. Possibly we have only enabled these shunts for > Opportunistic based connections. You could confirm that by using > right=%opportunisticgroup and adding 192.168.1.3/32 to a policy file, > eg /etc/ipsec.d/policies/private-or-clear and renaming your conn > mytunnel to "conn private-or-clear". > > If so, that is a bug. > > It is pretty rare that people want static VPN tunnels to "fail open", > and it is really only the "opportunistic" case where people want > this. > > Paul > I tried using right=%opportunisticgroup per your suggestion and indeed negotiationshunt=passthrough and failureshunt=passthrough seem to work as expected. Would you like me to create a new bugzilla entry? I am not sure which sub-component is affected. Actually I have a situation where I need multiple static VPN tunnels to "fail open". The failureshunt and negotiationshunt features would be very useful in certain mission-critical or safety-critical situations where having the data link go down has far greater consequences than losing confidentiality or authentication. For example, medical patient monitoring applications or avionics applications, etc. For that reason I would really like to be able to use these two options in non-OE configurations.
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
