<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Perhaps I found my issue. These lines are in my logs:<div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">Nov 30 10:25:57: FIPS: ignored negotiationshunt=passthrough - packets MUST be blocked in FIPS mode</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">Nov 30 10:25:57: FIPS: ignored failureshunt=passthrough - packets MUST be blocked in FIPS mode</span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class="">I assume this means there can be no failover at all in FIPS mode? Or I need to add the unconfigured hosts to my clear policy at least temporarily to get what I am after?</span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div><blockquote type="cite" class=""><div class="">On Nov 30, 2017, at 7:06 AM, Paul Wouters <<a href="mailto:paul@nohats.ca" class="">paul@nohats.ca</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Thu, 30 Nov 2017, Matt Hilt wrote:<br class=""><br class=""><blockquote type="cite" class="">I'm having a bit of trouble with opportunistic IPSec, specifically getting failover to clear working. Here is my setup:<br class="">* Redhat 7 on AWS in FIPS mode, libreswan 3.20.<br class="">* An SSH jump box with:<br class=""> - the main eth0 interface is on a public subnet (10.0.0.0/24); This traffic need not be encrypted. This also has an elastic IP, but I<br class="">don’t think that matters here.<br class=""> - a second interface eth1 on a private subnet (10.0.1.0/24). This subnet should (almost) always be encrypted.<br class=""> - opportunistic configuration mostly taken from the Wiki example for the private-or-clear section. One important change<br class="">was left=10.0.1.100<br class=""> - the “clear” policy includes just the gateway (10.0.1.1/32)<br class=""> - the “private-or-clear” policy includes the rest of the subnet (10.0.1.0/24)<br class="">* A client configured for OE at 10.0.1.21.<br class=""> - the “private” policy is set to the subnet (10.0.1.0/24) <br class=""> - the “clear” policy is the gateway (10.0.1.1/32)<br class="">* A client without IPSEC at 10.0.1.22.<br class="">The idea here is that when starting new VMs in the private subnet I need to first go through the jump box to configure the IPSEC<br class="">tunnels. So I need to fail over to clear until they are setup. But once they are configured I should only use encrypted traffic. What I<br class="">am seeing is that I can connect to the properly configured host via the IPSEC tunnel, but I cannot get to the unconfigured host.<br class="">When I run “ipsec status” the connection list is interesting: specifically in the “clear” section the only interface listed is eth0<br class="">(see below). I have tried using both the “interfaces” and “listen” parameters in the main config section but even then the best I can<br class="">do is get a blank value for the interface in the clear section. Any ideas?<br class="">----------------------<br class="">000 Connection list:<br class="">000 <br class="">000 "clear": 10.0.0.100---10.0.0.1...%group; unrouted; eroute owner: #0<br class=""></blockquote><br class="">Have you tried adding left=10.0.1.X to the clear connection definition?<br class="">Opportunistic groups are currently only based on destination address, so<br class="">you have to get the right source address yourself. The default IP we<br class="">pick up is the one that is used as source for the default route. But<br class="">you can specify this to override as left=<br class=""><br class="">Currently, you cannot have multiple source IPs for opportunistic. It's<br class="">on our todo list.<br class=""><br class=""><blockquote type="cite" class="">000 #2: "private-or-clear#10.0.1.0/24"[1] ...10.0.1.21:500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_v2_SA_REPLACE_IF_USED in<br class="">2627s; newest IPSEC; eroute owner; isakmp#1; idle; import:local rekey<br class="">000 #2: "private-or-clear#10.0.1.0/24"[1] ...10.0.1.21 <a href="mailto:esp.5ea67249@10.0.1.21" class="">esp.5ea67249@10.0.1.21</a> <a href="mailto:esp.1248e35f@10.0.1.100" class="">esp.1248e35f@10.0.1.100</a> <a href="mailto:tun.0@10.0.1.21" class="">tun.0@10.0.1.21</a> <a href="mailto:tun.0@10.0.1.100" class="">tun.0@10.0.1.100</a><br class="">ref=0 refhim=0 Traffic: ESPin=4KB ESPout=5KB! ESPmax=0B <br class="">000 #1: "private-or-clear#10.0.1.0/24"[1] ...10.0.1.21:500 STATE_PARENT_I3 (PARENT SA established); EVENT_v2_SA_REPLACE_IF_USED_IKE in<br class="">2837s; newest ISAKMP; isakmp#0; idle; import:local rekey<br class="">000 #1: "private-or-clear#10.0.1.0/24"[1] ...10.0.1.21 ref=0 refhim=0 Traffic: <br class=""></blockquote><br class="">You have two tunnels to the same endpoint here? Normally that shouldn't<br class="">happen.<br class=""><br class=""><blockquote type="cite" class="">000 Bare Shunt list:<br class="">000 <br class="">000 10.0.1.100/32:0 -0-> 10.0.1.22/32:0 => %unk-0 0 oe-failed<br class=""></blockquote><br class="">That looks okay, since you said the .22 node did not support OE.<br class=""><br class="">Paul<br class=""></div></div></blockquote></div><br class=""></div></body></html>