On 2020-06-16 12:32, Tobias Heider wrote:
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.
Thanks for the suggestion, unfortunately it did not solve my issue. I
also tried, for the sake of it:
flow from 10.200.200.0/24 to 10.100.100.0/24 type bypass
but it did not help either.
I've tried similar rules myself (however, not with "type bypass"). I've
tried:
flow esp from 10.200.200.0/24 to 10.100.100.0/24 peer <CLIENT EXTERNAL IP> type
use
flow esp from 10.200.200.0/24 to 10.100.100.0/24 peer <CLIENT EXTERNAL IP> type
use
flow esp from 10.200.200.3 to 10.100.100.0/24 peer <CLIENT EXTERNAL IP> type use
flow esp from 10.100.100.0/24 to 10.200.200.3 peer <CLIENT EXTERNAL IP> type use
flow esp from 10.100.100.0/24 to 10.200.200.0/24 peer <CLIENT EXTERNAL IP> type
use
I've tried them, one at a time, on the passive gateway, on the active
gateway, on both gateways, but no combination have restored the previous
behavior of being able to reach the passive gateway.
