On 2021-11-03, naib+li...@xn--bimann-cta.de <naib+li...@xn--bimann-cta.de>
wrote:
> I'm running two remote 7.0 OpenBSD boxes at a hosting provider. Both are
> connected via LAN (vio1) over a shared switch. This is a connection I do not
> trust. Thus, I want to properly secure traffic flowing over this connection.
>
> Currently I managed to set up an SA with iked. I am not able to ping the
> other host. Utilizing tcpdump, no traffic is seen on enc0 and no esp traffic
> is seen on vio1.
>
> Is there anything I've missed?
>
> /etc/iked.conf@host1:
> ikev2 \
> passive esp proto tcp \
You only have TCP in the flow config, so ping won't be covered.
I have had very strange problems with IPsec flows restricted to certain
protocols/ports before so I would try without that restriction first.
Also try with net.inet.ip.forwarding=1 if you don't already have it, I
don't think you are actually forwarding in this configuration but you
might need "weak host model" and there's no way to change that on
OpenBSD other than enabling forwarding.
> enc chacha20-poly1305 \
> group curve25519 \
> ikelifetime 12h \
> lifetime 2h bytes 2G
It won't be stopping things working here, but a 2G lifetime is really low.
> ikectl show sa@host1:
btw "ipsecctl -sa" is way easier to read if you just want to check that
flows are setup, i"ikectl show sa" output is more formatted for code debug
than user fault diagnosis.
> iked_sas: 0xc8e656727b0 rspi 0xe3281f62f2f15c57 ispi 0x0df250d3e7e7d95c
> 192.168.1.1:500->192.168.1.2:500<FQDN/host2>[] ESTABLISHED r udpecap nexti
> 0x0 pol 0xc8e691ab000
> sa_childsas: 0xc8e65660b00 ESP 0x80127fcd in 192.168.1.2:500 ->
> 192.168.1.1:500 (LA) B=0x0 P=0xc8e65660100 @0xc8e656727b0
> sa_childsas: 0xc8e65660100 ESP 0xcfcdf2e0 out 192.168.1.1:500 ->
> 192.168.1.2:500 (L) B=0x0 P=0xc8e65660b00 @0xc8e656727b0
> sa_flows: 0xc8e65681000 ESP out 192.168.1.1/32 -> 192.168.1.2/32 [6]@-1 (L)
> @0xc8e656727b0
> sa_flows: 0xc8e65675400 ESP in 192.168.1.2/32 -> 192.168.1.1/32 [6]@-1 (L)
> @0xc8e656727b0
> iked_activesas: 0xc8e65660b00 ESP 0x80127fcd in 192.168.1.2:500 ->
> 192.168.1.1:500 (LA) B=0x0 P=0xc8e65660100 @0xc8e656727b0
> iked_activesas: 0xc8e65660100 ESP 0xcfcdf2e0 out 192.168.1.1:500 ->
> 192.168.1.2:500 (L) B=0x0 P=0xc8e65660b00 @0xc8e656727b0
> iked_flows: 0xc8e65675400 ESP in 192.168.1.2/32 -> 192.168.1.1/32 [6]@-1 (L)
> @0xc8e656727b0
> iked_flows: 0xc8e65681000 ESP out 192.168.1.1/32 -> 192.168.1.2/32 [6]@-1 (L)
> @0xc8e656727b0
> iked_dstid_sas: 0xc8e656727b0 rspi 0xe3281f62f2f15c57 ispi 0x0df250d3e7e7d95c
> 192.168.1.1:500->192.168.1.2:500<FQDN/host2>[] ESTABLISHED r udpecap nexti
> 0x0 pol 0xc8e691ab000
>
> /etc/pf.conf@host1:
> [...]
> set skip on lo
> set skip on enc0
> match in all scrub (no-df)
>
> block return
> block in from { $ipv4_exthost, $ipv6_exthost }
> block in quick on egress from $localIPs
> block out quick on egress to $localIPs
> block in quick from <abusive_hosts>
>
> pass in on $int_if proto udp from 192.168.1.2 to 192.168.1.1 port 500
> pass out on $int_if proto udp from 192.168.1.1 to 192.168.1.2 port 500
> pass in on $int_if proto esp from 192.168.1.2 to 192.168.1.1
> pass out on $int_if proto esp from 192.168.1.1 to 192.168.1.2
> [...]
That looks alright from what you've shown, but we can't check anything
about the macros or which interface/s are in the "egress" group.
Use "log" on the default block rule and check tcpdump -neipflog0.
--
Please keep replies on the mailing list.
