<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 14, 2017 at 7:11 AM, Paul Wouters <span dir="ltr"><<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, 13 Jun 2017, Evan Wheeler wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My understanding is that the "negotiationshunt=passthrough" option would allow traffic to pass in the clear between two hosts<br>
while the hosts are negotiating during Phase 1, and "negotiationshunt=passthrough" would allow packets to pass in the clear<br>
after negotiations had failed due to the differing PSK values on each host, but a simple ping test between the hosts shows no<br>
ICMP packets passing in either direction according to Wireshark.  All I see are ISAKMP packets.   Here are the contents of my<br>
ipsec.conf file  for both hosts:<br>
</blockquote>
<br></span>
That is the idea, yes.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
conn mytunnel<br>
    left=192.168.1.2<br>
    right=192.168.1.3<br>
    authby=secret<br>
    auto=start<br>
    failureshunt=passthrough<br>
    negotiationshunt=passthrough<br>
    keyingtries=1<br>
    retransmit-timeout=3s<br>
<br>
Am I missing something ? Should failureshunt and negotiationshunt work in this configuration?<br>
</blockquote>
<br></span>
That should do it. Possibly we have only enabled these shunts for<br>
Opportunistic based connections. You could confirm that by using<br>
right=%opportunisticgroup and adding <a href="http://192.168.1.3/32" rel="noreferrer" target="_blank">192.168.1.3/32</a> to a policy file,<br>
eg /etc/ipsec.d/policies/private-<wbr>or-clear and renaming your conn<br>
mytunnel to "conn private-or-clear".<br>
<br>
If so, that is a bug.<br>
<br>
It is pretty rare that people want static VPN tunnels to "fail open",<br>
and it is really only the "opportunistic" case where people want<br>
this.<span class="HOEnZb"><font color="#888888"><br>
<br>
Paul<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">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.  </div><div class="gmail_extra"><br></div><div class="gmail_extra">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. </div></div>