[Swan] IPComp and xfrmi

[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 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.

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