On Fri, Jun 12, 2020 at 09:27:18PM +0200, Tobias Heider wrote: > On Fri, Jun 12, 2020 at 03:31:56PM +0200, Patrik Ragnarsson wrote: > > Hi, > > > > We have two OpenBSD machines acting as gateways for our network using > > CARP and IPsec (IKEv2). > > > > When the machines were running OpenBSD 6.6, from an IPSec client, you > > were able to reach the passive gateway while being connected to the > > active gateway. On OpenBSD 6.7, it seems this is no longer possible. > > > > The setup looks like this: > > > > - The two servers share <SHARED EXTERNAL IP> using CARP (carp10 > > (carpdev trunk1)) > > - The two servers share 10.200.200.1 using CARP (carp20 (carpdev > > vlan2000)) > > - The active (MASTER) gateway has 10.200.200.2 (vlan2000 (parent trunk0)) > > - The passive (BACKUP) gateway has 10.200.200.3 (vlan2000 (parent trunk0)) > > > > iked.conf looks like this on both machines: > > > > $ cat /etc/iked.conf > > local_endpoint = "<SHARED EXTERNAL IP>" > > roadwarrior_net = "10.100.100.0/24" > > > > ikev2 "roadwarrior-psk" ipcomp esp \ > > from 10.200.200.0/24 to 0.0.0.0/0 \ > > peer any local $local_endpoint \ > > srcid $local_endpoint \ > > psk "<SECRET>" \ > > config address $roadwarrior_net \ > > config netmask 255.255.255.0\ > > tag "$name-$id" > > > > sasyncd.conf from the active gateway: > > > > $ cat /etc/sasyncd.conf > > interface carp10 > > listen on 10.200.200.2 > > peer 10.200.200.3 > > control iked > > sharedkey <SECRET> > > > > sasyncd.conf from the passive gateway: > > > > $ cat /etc/sasyncd.conf > > interface carp10 > > listen on 10.200.200.3 > > peer 10.200.200.2 > > control iked > > sharedkey <SECRET> > > > > The PF rules on both gateways looks like this: > > > > block drop log all > > pass on vlan2000 proto carp all keep state (no-sync) > > pass on trunk1 proto carp all keep state (no-sync) > > pass on vlan2000 all no state > > pass out on trunk1 all flags S/SA > > pass in on trunk1 inet proto tcp from any to (trunk1:0) port = 22 > > flags S/SA keep state (no-sync) > > pass in on trunk1 inet proto udp from any to (trunk1:0) port > > 60000:61000 keep state (no-sync) > > pass out on trunk1:0 all flags S/SA keep state (no-sync) > > pass in on trunk1 inet proto icmp all > > block return in on trunk1 proto udp from any to any port 33434:33534 > > pass out on trunk1 from (vlan2000:network) to any flags S/SA > > nat-to (carp10:0) > > pass in on trunk1 inet proto udp from any to <SHARED EXTERNAL IP> port > > = 500 > > pass in on trunk1 inet proto udp from any to <SHARED EXTERNAL IP> > > port = 4500 > > pass out on trunk1 inet proto udp from <SHARED EXTERNAL IP> to any > > port = 500 > > pass out on trunk1 inet proto udp from <SHARED EXTERNAL IP> to any > > port = 4500 > > pass in on trunk1 inet proto esp from any to <SHARED EXTERNAL IP> > > pass out on trunk1 inet proto esp from <SHARED EXTERNAL IP> to any > > pass in on enc0 inet from 10.100.100.0/24 to 10.200.200.0/24 flags > > S/SA keep state (if-bound) > > pass in on enc0 inet proto ipencap from any to <SHARED EXTERNAL > > IP> keep state (if-bound) > > pass out on enc0 inet from 10.200.200.0/24 to 10.100.100.0/24 > > flags S/SA keep state (if-bound) > > pass out on enc0 inet proto ipencap from <SHARED EXTERNAL IP> to > > any keep state (if-bound) > > > > On both gateways, I can see that the same flows and SAs have been > > created after the client have connected to the VPN. (ipsecctl -s all) > > > > A client (macOS) can reach 10.200.200.1 and 10.200.200.2 (and other > > servers in 10.200.200.0/24) but not 10.200.200.3: > > > > $ ping -c5 10.200.200.3 > > PING 10.200.200.3 (10.200.200.3): 56 data bytes > > Request timeout for icmp_seq 0 > > Request timeout for icmp_seq 1 > > Request timeout for icmp_seq 2 > > Request timeout for icmp_seq 3 > > > > --- 10.200.200.3 ping statistics --- > > 5 packets transmitted, 0 packets received, 100.0% packet loss > > > > I can see the ICMP echo requests reach the vlan2000 interface on the > > passive gateway (tcpdump -netti vlan2000 icmp) > > > > 1591718254.738903 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: > > 10.100.100.173 > 10.200.200.3: icmp: echo request > > 1591718255.740275 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: > > 10.100.100.173 > 10.200.200.3: icmp: echo request > > 1591718256.740455 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: > > 10.100.100.173 > 10.200.200.3: icmp: echo request > > 1591718257.743593 ac:1f:6b:6b:65:c6 ac:1f:6b:6b:64:a6 0800 98: > > 10.100.100.173 > 10.200.200.3: icmp: echo request > > > > Running iked in the foreground (iked -dv) on the passive gateway, I > > can see the following when I try to ping 10.200.200.3 from the client: > > > > pfkey_process: acquire request (peer <CLIENT EXTERNAL IP>) > > pfkey_process: flow in from 10.200.200.0/255.255.255.0 to > > 10.100.100.173/255.255.255.255 via <CLIENT EXTERNAL IP> > > ikev2_acquire_sa: flow wasn't found > > > > I've also tried disabling PF on the passive gateway, I still couldn't > > reach 10.200.200.3. > > > > Appreciate it if anyone has any ideas of what's going on. > > > > Thanks! > > Probably related to the following change documented in > https://www.openbsd.org/faq/upgrade67.html: > > iked(8)/isakmpd(8). The type of incoming ipsec(4) flows installed by iked(8) > or > isakmpd(8) was changed from "use" to "require". This means unencrypted traffic > matching the flows will no longer be accepted. Flows of type "use" can still > be > set up manually in ipsec.conf(5). > > The problem is that the incoming packet on 10.200.200.3 matches the installed > IPsec flow which only accepts encrypted packets. >
You could try adding the following flow to ipsec.conf on 10.200.200.3: flow from 10.100.100.0/24 to 10.200.200.0/24 type bypass This should explicitly match and allow traffic coming from the internal roadwarrior_net.
