[Swan] IPComp and xfrmi

[Wolfgang Nothdurft]

Am 21.07.23 um 13:44 schrieb Andrew Cagney:
> On Fri, 21 Jul 2023 at 06:01, Wolfgang Nothdurft <wolfgang at linogate.de> wrote:
>>
>> 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)
> 
> An established permanent connection should have installed kernel
> policy covering the entire range:
> 
>          rightsubnet=192.0.2.0/24
>          leftsubnet=192.0.3.0/24
> 
> so the acquire shouldn't happen.
> 

I tried again with  ../../guestbin/ping-once.sh --medium --up -I 
192.0.3.254 192.0.2.254, a newer kernel 6.2.15-100.fc36.x86_64 and 
Libreswan v4.9-1972-g70612043a9-main

These are the policies before the medium ping

  ip xfrm policy
src 192.0.3.0/24 dst 192.0.2.0/24
         dir out priority PRIORITY ptype main
         tmpl src 192.1.3.33 dst 192.1.2.23
                 proto comp reqid REQID mode tunnel
         tmpl src 0.0.0.0 dst 0.0.0.0
                 proto esp reqid REQID mode transport
         if_id 0x1
src 192.0.2.0/24 dst 192.0.3.0/24
         dir fwd priority PRIORITY ptype main
         tmpl src 192.1.2.23 dst 192.1.3.33
                 proto comp reqid REQID mode tunnel
                 level use
         tmpl src 0.0.0.0 dst 0.0.0.0
                 proto esp reqid REQID mode transport
         if_id 0x1
src 192.0.2.0/24 dst 192.0.3.0/24
         dir in priority PRIORITY ptype main
         tmpl src 192.1.2.23 dst 192.1.3.33
                 proto comp reqid REQID mode tunnel
                 level use
         tmpl src 0.0.0.0 dst 0.0.0.0
                 proto esp reqid REQID mode transport
         if_id 0x1

The ping also fails and it still acquires

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

and there is this state added

src 192.1.3.33 dst 192.1.2.23
         proto comp spi 0x00000000 reqid REQID mode tunnel
         replay-window 0
         if_id 0x1
         sel src 192.0.3.254/32 dst 192.0.2.254/32 proto icmp type 8 
code 0 dev eth1

>> 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
> 
> 
>> 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?
> 
> While different:
> 
> - github/716 is about combining IP Comp with IPv4-in-IPv6 and
> IPv6-in-IPv4 encapsulation (Tobias Brunner was circulating a patch to
> fix it)
> - here IP Comp is being combined with ipsec-interfaces
> 
> they certainly have the same feel.  The small packet doesn't end up
> using the compression template.  Try a guestbin/ping-once.sh --medium
> packet.
> 
> I'd file a bug.  I'll ping Tobais.

Filing a bug on the libreswan github or the kernel list?