[Swan] IPComp and xfrmi

[Wolfgang Nothdurft]

Hi,

i have a problem that if ipcomp is active using xfrmi (either ikev1 and 
ikev2), packets through the tunnel trigger a new connection.

This is reproducible if I use the test ikev1-xfrmi-01 and activate 
compress=yes in ipsec.conf. The test fails and I see following log 
message after the tunnel was established:

initiate on-demand for packet 192.0.3.254:8-ICMP->192.0.2.254:0
| routing: dispatch ACQUIRE to ROUTED_TUNNEL PERMANENT $1 routing#2 
IPsec#2 IKE#1 (initiate_ondemand() +145 programs/pluto/acquire.c)
EXPECTATION FAILED: routing: unhandled ACQUIRE to ROUTED_TUNNEL 
PERMANENT $1 routing#2 IPsec#2 IKE#1 (initiate_ondemand() +145 
programs/pluto/acquire.c)

I also added ip xfrm monitor to northrun.sh:

  ping -n -q -w 4 -c 4 192.0.2.254
PING 192.0.2.254 (192.0.2.254) 56(84) bytes of data.
--- 192.0.2.254 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time

acquire proto comp
   sel src 192.0.3.254/32 dst 192.0.2.254/32 proto icmp type 8 code 0 
dev eth1
   policy src 192.0.3.0/24 dst 192.0.2.0/24
         dir out priority 1757393 ptype main
         tmpl src 192.1.3.33 dst 192.1.2.23
                 proto comp reqid 16390 mode tunnel
         tmpl src 0.0.0.0 dst 0.0.0.0
                 proto esp reqid 16389 mode transport
         if_id 0x1

Test was running with nsrun --ns on Kernel is 5.11.22-100.fc32.x86_64.

This seems the same problem described in 
https://github.com/libreswan/libreswan/issues/716 where andrew commented 
"This is a linux kernel bug.".
Can you tell me which one?

If this is a new one, i will create an issue on github.

Regards
Wolfgang