Hello,
i'm having a problem with a test-setup i'm running at the moment:
<192.168.0/24>-------OpenBSD------<172.23.92/24>--------MachineA
| |
+----- IPsec tunnel ---------+
The OpenBSD (running 3.8 generic) should run an IPsec tunnel to
MachineA and encapsulate all traffic from 192.168.0/24 destined for
172.23.92.166 (IP of MachineA). This needs to be done using pre shared
keys. The packets are encrypted and decrypted properly (as far as i can
tell), but the incoming traffic from MachineA on the OpenBSD box are
not handled correctly.
The IPs are as follows:
OpenBSD xl0 192.168.0.1 and xl1 172.23.92.9
MachineA 172.23.92.9
The SAs and flows have been configured as follows:
# ipsecadm show
sadb_dump: satype esp vers 2 len 25 seq 0 pid 0
sa: spi 0x000011d7 auth hmac-md5 enc 3des-cbc
state mature replay 0 flags 4
lifetime_cur: alloc 0 bytes 13008 add 1133455215 first
1133455272
x_lifetime_lastuse: alloc 0 bytes 0 add 0 first 1133456020
address_src: 172.23.92.166
address_dst: 172.23.92.9
key_auth: bits 128: 22222222222222222222222222222222
key_encrypt: bits 192:
111111111111111111111111111111111111111111111111
sadb_dump: satype esp vers 2 len 25 seq 0 pid 0
sa: spi 0x000011d7 auth hmac-md5 enc 3des-cbc
state mature replay 0 flags 4
lifetime_cur: alloc 0 bytes 12324 add 1133455215 first
1133455271
x_lifetime_lastuse: alloc 0 bytes 0 add 0 first 1133455954
address_src: 172.23.92.9
address_dst: 172.23.92.166
key_auth: bits 128: 22222222222222222222222222222222
key_encrypt: bits 192:
111111111111111111111111111111111111111111111111
# netstat -rnf encap
Routing tables
Encap:
Source Port Destination Port Proto
SA(Address/Proto/Type/Direction)
172.23.92.166/32 0 192.168.0/24 0 0
172.23.92.9/50/require/in
192.168.0/24 0 172.23.92.166/32 0 0
172.23.92.166/50/require/out
I have done a ping as follows:
# ping -c 3 -I 192.168.0.1 172.23.92.166
PING 172.23.92.166 (172.23.92.166): 56 data bytes
--- 172.23.92.166 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
#
and traced at the same time both the enc0 and xl1 interfaces. On xl1 it
can be seen that the traffic is encrypted properly and that return
packets are received from MachineA.
# tcpdump -n -i xl1 esp
tcpdump: listening on xl1, link-type EN10MB
17:55:59.754336 esp 172.23.92.9 > 172.23.92.166 spi 0x000011D7 seq 149
len 116
17:55:59.755702 esp 172.23.92.166 > 172.23.92.9 spi 0x000011D7 seq 152
len 116
17:56:00.760226 esp 172.23.92.9 > 172.23.92.166 spi 0x000011D7 seq 150
len 116
17:56:00.761323 esp 172.23.92.166 > 172.23.92.9 spi 0x000011D7 seq 153
len 116
17:56:01.770127 esp 172.23.92.9 > 172.23.92.166 spi 0x000011D7 seq 151
len 116
17:56:01.771183 esp 172.23.92.166 > 172.23.92.9 spi 0x000011D7 seq 154
len 116
^C
6 packets received by filter
0 packets dropped by kernel
#
On the enc0 interface it can be seen that the packets coming in from
MachineA are decrypted properly. The ping does not show these packets
however.
# tcpdump -i enc0 -n
tcpdump: WARNING: enc0: no IPv4 address assigned
tcpdump: listening on enc0, link-type ENC
17:55:59.754190 (authentic,confidential): SPI 0x000011d7: 192.168.0.1 >
172.23.92.166: icmp: echo request (encap)
17:55:59.755764 (authentic,confidential): SPI 0x000011d7: 172.23.92.166
> 192.168.0.1: icmp: echo reply (encap)
17:56:00.760124 (authentic,confidential): SPI 0x000011d7: 192.168.0.1 >
172.23.92.166: icmp: echo request (encap)
17:56:00.761381 (authentic,confidential): SPI 0x000011d7: 172.23.92.166
> 192.168.0.1: icmp: echo reply (encap)
17:56:01.770054 (authentic,confidential): SPI 0x000011d7: 192.168.0.1 >
172.23.92.166: icmp: echo request (encap)
17:56:01.771238 (authentic,confidential): SPI 0x000011d7: 172.23.92.166
> 192.168.0.1: icmp: echo reply (encap)
^C
6 packets received by filter
0 packets dropped by kernel
#
A netstat shows the following:
# netstat -ss -p esp
esp:
285 input ESP packets
237 output ESP packets
88 packets for which no TDB was found
16840 input bytes
19260 output bytes
#
The 88 packets with the TDB problem are from previous tests and have
nothing to do with this ping.
Does anybody know what is wrong or what else i can check?
Regards,
Stefan
