Perhaps I found my issue. These lines are in my logs: Nov 30 10:25:57: FIPS: ignored negotiationshunt=passthrough - packets MUST be blocked in FIPS mode Nov 30 10:25:57: FIPS: ignored failureshunt=passthrough - packets MUST be blocked in FIPS mode
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? > On Nov 30, 2017, at 7:06 AM, Paul Wouters <[email protected]> wrote: > > On Thu, 30 Nov 2017, Matt Hilt wrote: > >> I'm having a bit of trouble with opportunistic IPSec, specifically getting >> failover to clear working. Here is my setup: >> * Redhat 7 on AWS in FIPS mode, libreswan 3.20. >> * An SSH jump box with: >> - 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 >> don’t think that matters here. >> - a second interface eth1 on a private subnet (10.0.1.0/24). This subnet >> should (almost) always be encrypted. >> - opportunistic configuration mostly taken from the Wiki example for the >> private-or-clear section. One important change >> was left=10.0.1.100 >> - the “clear” policy includes just the gateway (10.0.1.1/32) >> - the “private-or-clear” policy includes the rest of the subnet >> (10.0.1.0/24) >> * A client configured for OE at 10.0.1.21. >> - the “private” policy is set to the subnet (10.0.1.0/24) >> - the “clear” policy is the gateway (10.0.1.1/32) >> * A client without IPSEC at 10.0.1.22. >> 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 >> 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 >> am seeing is that I can connect to the properly configured host via the >> IPSEC tunnel, but I cannot get to the unconfigured host. >> When I run “ipsec status” the connection list is interesting: specifically >> in the “clear” section the only interface listed is eth0 >> (see below). I have tried using both the “interfaces” and “listen” >> parameters in the main config section but even then the best I can >> do is get a blank value for the interface in the clear section. Any ideas? >> ---------------------- >> 000 Connection list: >> 000 >> 000 "clear": 10.0.0.100---10.0.0.1...%group; unrouted; eroute owner: #0 > > Have you tried adding left=10.0.1.X to the clear connection definition? > Opportunistic groups are currently only based on destination address, so > you have to get the right source address yourself. The default IP we > pick up is the one that is used as source for the default route. But > you can specify this to override as left= > > Currently, you cannot have multiple source IPs for opportunistic. It's > on our todo list. > >> 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 >> 2627s; newest IPSEC; eroute owner; isakmp#1; idle; import:local rekey >> 000 #2: "private-or-clear#10.0.1.0/24"[1] ...10.0.1.21 >> [email protected] [email protected] [email protected] >> [email protected] >> ref=0 refhim=0 Traffic: ESPin=4KB ESPout=5KB! ESPmax=0B >> 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 >> 2837s; newest ISAKMP; isakmp#0; idle; import:local rekey >> 000 #1: "private-or-clear#10.0.1.0/24"[1] ...10.0.1.21 ref=0 refhim=0 >> Traffic: > > You have two tunnels to the same endpoint here? Normally that shouldn't > happen. > >> 000 Bare Shunt list: >> 000 >> 000 10.0.1.100/32:0 -0-> 10.0.1.22/32:0 => %unk-0 0 oe-failed > > That looks okay, since you said the .22 node did not support OE. > > Paul
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
