On 4 November 2014 17:06, Martin Larsson martin.larss...@gmail.com wrote:
Hello!
I've setup a tunnel between OpenBSD 5.6 using iked and an openwrt router
running strongswan.
The tunnel works great with ping and other traffic but traffic between the
two external ip's dies.
This is a site-to-site connection and nothing fancy.
iked.conf on OpenBSD.
ikev2 esp from $10.11.12.0/24 to $194.168.4.0/24 peer $tcgw srcid sippan.se
# ipsecctl -sa
FLOWS:
flow esp in from 192.168.4.0/24 to 10.11.12.0/24 peer 82.17.12.21 srcid
FQDN/sippan.se dstid FQDN/sswan.sippan.se type use
flow esp out from 10.11.12.0/24 to 192.168.4.0/24 peer 82.17.12.21 srcid
FQDN/sippan.se dstid FQDN/sswan.sippan.se type require
flow esp out from ::/0 to ::/0 type deny
SAD:
esp tunnel from 82.17.12.21 to 130.51.23.4 spi 0x67483925 auth hmac-sha1
enc aes
esp tunnel from 130.51.23.4 to 82.17.12.21 spi 0xcf1f39d1 auth hmac-sha1
enc aes
# netstat -nr
Routing tables
Internet:
DestinationGatewayFlags Refs Use Mtu Prio
Iface
default130.51.23.4 UGS 10 30430256 - 8 em0
10/8 link#5 UC 10 - 4
vether0
10.11.12.13fe:e1:ba:d0:d6:1c UHLl 01 - 1 lo0
10.255.255.255 link#5 UHLc 3 570 - 4
vether0
82.17.12.21 130.51.23.4 UGHD 0 30430251 - L 56 em0
127/8 127.0.0.1 UGRS 00 32768 8 lo0
127.0.0.1 127.0.0.1 UH 16 32768 4 lo0
194.48.213.128/27 link#1 UC 10 - 4 em0
130.51.23.4 00:00:cd:19:95:16 UHLc 20 - 4 em0
130.51.23.4 00:02:b3:aa:cc:c3 HLl00 - 1 lo0
224/4 127.0.0.1 URS00 32768 8 lo0
Internet6:
-removed, dont use it-
Encap:
Source Port DestinationPort Proto
SA(Address/Proto/Type/Direction)
192.168.4/24 0 10.11.12/240 0
82.17.12.21/esp/use/in
10.11.12/240 192.168.4/24 0 0
82.17.12.21/esp/require/out
default0 default
0 0 none/esp/deny/out
# tcpdump on openbsd while trying to connect with ssh to the external ip of
the OpenBSD host from the exernal ip of the other end.
# tcpdump host 82.17.12.21
tcpdump: listening on em0, link-type EN10MB
tcpdump: WARNING: compensating for unaligned libpcap packets
16:49:55.539903 egget.priv.lamest.se.54158 loller.sippan.se.ssh: S
2729317717:2729317717(0) win 8192 mss 1460,nop,wscale 8,nop,nop,sackOK
(DF)
16:49:55.539932 loller.sippan.se.ssh egget.priv.lamest.se.54158: S
2317435827:2317435827(0) ack 2729317718 win 16384 mss
1240,nop,nop,sackOK,nop,wscale 3
16:49:55.545936 egget.priv.lamest.se.54158 loller.sippan.se.ssh: . ack 1
win 256 (DF)
16:49:55.553927 esp loller.sippan.se egget.priv.lamest.se spi 0xcf1f39d1
seq 190 len 100
16:50:01.553883 esp loller.sippan.se egget.priv.lamest.se spi 0xcf1f39d1
seq 191 len 100
16:50:05.977468 esp egget.priv.lamest.se loller.sippan.se spi 0x67483925
seq 127 len 84 (DF)
16:50:05.977519 esp loller.sippan.se egget.priv.lamest.se spi 0xcf1f39d1
seq 192 len 84
# tcpdump on enc0 while trying ssh and https
tcpdump: listening on enc0, link-type ENC
tcpdump: WARNING: compensating for unaligned libpcap packets
17:01:01.578622 (authentic,confidential): SPI 0xc31749f4:
loller.sippan.se.ssh egget.priv.lamest.se.54158: R
2317435850:2317435850(0) ack 2729317718 win 0 (encap)
17:01:05.786123 (authentic,confidential): SPI 0xc31749f4:
loller.sippan.se.ssh egget.priv.lamest.se.54792: P
3813334764:3813334785(21) ack 2711749548 win 2170 (encap)
17:01:05.968654 (authentic,confidential): SPI 0xc31749f4:
loller.sippan.se.https egget.priv.lamest.se.54793: P
3540908942:3540909100(158) ack 1840586787 win 2170 (encap)
17:01:06.265543 (authentic,confidential): SPI 0xc31749f4:
loller.sippan.se.https egget.priv.lamest.se.54793: . ack 1 win 2170
(encap)
17:01:06.876165 (authentic,confidential): SPI 0xc31749f4:
loller.sippan.se.https egget.priv.lamest.se.54793: . ack 1 win 2170
(encap)
17:01:08.095189 (authentic,confidential): SPI 0xc31749f4:
loller.sippan.se.https egget.priv.lamest.se.54793: . ack 1 win 2170
(encap)
17:01:10.459116 (authentic,confidential): SPI 0xc31749f4:
loller.sippan.se.https egget.priv.lamest.se.54793: . ack 1 win 2170
(encap)
So it appears that OpenBSD tries to send back traffic with ESP when it
shouldn't.
I'd also like to add that the exact same setup works with with isakmpd.
Best regards
Martin
This is a known issue. The reason why it happens is not
strictly documented. The change to the stack was introduced
as part of the cleanup long time ago. Supposedly it's there
to support TCP MD5 signatures, but I didn't verify that yet.
There's this code in the
