[Swan] Can't get failureshunt & negotiationshunt to work in passthrough mode

[Evan Wheeler]

On Wed, Jun 14, 2017 at 7:11 AM, Paul Wouters <paul at nohats.ca> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20170614/14497bd3/attachment.html>