IPsec: incoming ESP packets dropped

C

cbbg

network_setup.jpg

I am trying to set-up an IPsec based VPN tunnel between my smartphone and my home server (192.168.0.42). The connection is established, but incoming (UDP-encapsulated) ESP packets are dropped on the server side. I'm using OpenIKED for the key exchange. The following output shows the dropped packets:

Code: 
duvel# netstat -ss -p esp
esp:
        2554 packets dropped; no TDB
        2332 packets out
        195888 bytes out
        ESP output histogram:
                aes-gcm-16: 2332

This output reveals that all incoming ESP packets are dropped due to the lack of a matching tunnel descriptor block (DTB). It seams that this means there is no SA matching with the incoming traffic. The SPI of incoming packets match the SPI in the SA database though. The destination address also matches, so I am baffled at the dropped packets. Who can point me in the right direction for a solution?

I have posted more relevant output and configurations below.
The OpenIKED configuration file.
Code: 
duvel# cat /usr/local/etc/iked.conf
ikev2 "bram" esp \
        from any to dynamic \
        local 192.168.0.42 peer any \
        srcid vpn.cbbg.nl \
        config address 10.0.5.100/32 \
        config name-server 192.168.0.42

The tcpdumps of a ping to 10.0.5.100.
Code: 
duvel# tcpdump -i em0 -n host 188.207.111.186 or 10.0.5.100
09:03:11.492055 IP 192.168.0.42.4500 > 188.207.111.186.62721: UDP-encap: ESP(spi=0xcd6c9c39,seq=0x2), length 120
09:03:11.778688 IP 188.207.111.186.62721 > 192.168.0.42.4500: UDP-encap: ESP(spi=0xb0ca0fa1,seq=0x19), length 120
# Note: there is a reply from the client

duvel# tcpdump -ni enc0
09:03:11.492018 (authentic,confidential): SPI 0xcd6c9c39: IP 192.168.0.42 > 10.0.5.100: ICMP echo request, id 60041, seq 1, length 64
# Note: no reply to the request

The policy database:
Code: 
duvel# setkey -PD
10.0.5.100[any] 0.0.0.0/0[any] any
        in ipsec
        esp/tunnel/188.207.111.186-192.168.0.42/require
        spid=164 seq=1 pid=35335 scope=global
        refcnt=1
0.0.0.0/0[any] 10.0.5.100[any] any
        out ipsec
        esp/tunnel/192.168.0.42-188.207.111.186/require
        spid=163 seq=0 pid=35335 scope=global
        refcnt=2

The SA database:
Code: 
duvel# setkey -D
192.168.0.42[4500] 188.207.111.186[62721]
        esp-udp mode=tunnel spi=3446447161(0xcd6c9c39) reqid=0(0x00000000)
        E: aes-gcm-16  4be7a019 5c7abd15 e6d28715 944764f0 09d8daab
        seq=0x00000013 replay=64 flags=0x00000000 state=mature
        created: Oct 31 08:59:48 2022   current: Oct 31 09:05:31 2022
        diff: 343(s)    hard: 10800(s)  soft: 9914(s)
        last: Oct 31 09:03:03 2022      hard: 0(s)      soft: 0(s)
        current: 2660(bytes)    hard: 4294967296(bytes) soft: 3942779977(bytes)
        allocated: 19   hard: 0 soft: 0
        sadb_seq=1 pid=35336 refcnt=1
188.207.111.186[4500] 192.168.0.42[62721]
        esp-udp mode=any spi=2966032289(0xb0ca0fa1) reqid=0(0x00000000)
        E: aes-gcm-16  ce982b44 c1898ea3 168d492b 278c3dc4 12647eb0
        seq=0x00000000 replay=64 flags=0x00000000 state=mature
        created: Oct 31 08:59:48 2022   current: Oct 31 09:05:31 2022
        diff: 343(s)    hard: 10800(s)  soft: 9633(s)
        last:                           hard: 0(s)      soft: 0(s)
        current: 0(bytes)       hard: 4294967296(bytes) soft: 3831110828(bytes)
        allocated: 0    hard: 0 soft: 0
        sadb_seq=0 pid=35336 refcnt=1

And perhaps relevant:
Code: 
duvel#: sysctl net.enc
net.enc.out.ipsec_bpf_mask: 1
net.enc.out.ipsec_filter_mask: 2
net.enc.in.ipsec_bpf_mask: 2
net.enc.in.ipsec_filter_mask: 2
 
Can you ping from 192.168.0.42 to 188.207.111.186
And can you ping from 188.207.111.186 to 143.176.182.190.
Or traceroute.
[ PS: It could be ping is firewalled on the phone ]
 
Alain De Vos I really think the issue is on the server side. I see an ESP packet corresponding to the reply to to the ping request coming back on the em0 interface, after this it is dropped (probably to a policy (?) mismatch).

covacat Thanks for the suggestion. I gave it a shot, but alas, no noticable changes in the setup (apart from the enc0 interface gone).
 
I have installed strongSwan and managed to have a functional IPsec tunnel. I have slightly modified my iked.conf to match the strongSwan configuration. Unfortunately the issue of dropped packets remains. I have provide both configurations below and the respective policy dumps setkey -PD.
Code: 
pools {
   rw-pool {
        addrs  = 10.0.5.100/32
        dns = 192.168.0.42
   }
}

connections {
   bram {
      local_addrs  = 192.168.0.42
      local {
         auth = pubkey
         certs = server.crt
         id = vpn.cbbg.nl
      }
      remote {
          auth = pubkey
      }
      children {
          vpn {
              remote_ts = 10.0.5.0/24
          }
      }
      pools = rw-pool
  }
}

Code: 
ikev2 "bram" esp \
        from 192.168.0.42 to 10.0.5.0/24 \
        local 192.168.0.42 peer any \
        srcid vpn.cbbg.nl \
        config address 10.0.5.100/32 \
        config name-server 192.168.0.42

Policy dump when using strongSwan:
Code: 
10.0.5.0/24[any] 192.168.0.42[any] any
        in ipsec
        esp/tunnel/188.207.111.186-192.168.0.42/unique:1
        created: Nov  5 11:48:14 2022  lastused: Nov  5 11:48:22 2022
        lifetime: 9223372036854775807(s) validtime: 0(s)
        spid=205 seq=1 pid=14203 scope=global
        refcnt=2
192.168.0.42[any] 10.0.5.0/24[any] any
        out ipsec
        esp/tunnel/192.168.0.42-188.207.111.186/unique:1
        created: Nov  5 11:48:14 2022  lastused: Nov  5 11:48:14 2022
        lifetime: 9223372036854775807(s) validtime: 0(s)
        spid=206 seq=0 pid=14203 scope=global
        refcnt=2


Policy dump when using OpenIKED:
Code: 
10.0.5.0/24[any] 192.168.0.42[any] any
        in ipsec
        esp/tunnel/188.207.111.186-192.168.0.42/require
        spid=204 seq=1 pid=14186 scope=global
        refcnt=1
192.168.0.42[any] 10.0.5.0/24[any] any
        out ipsec
        esp/tunnel/192.168.0.42-188.207.111.186/require
        spid=203 seq=0 pid=14186 scope=global
        refcnt=2

The only relevant discernable difference between both policies is the unique:1 vs require. It seems unique can be used to bind a policy to a specific SA, according to setkey(8). Though it remains a mystery why the OpenIKED policy does not match.
 
You must log in or register to reply here.
Back
Top