Am 21.07.23 um 13:44 schrieb Andrew Cagney:
On Fri, 21 Jul 2023 at 06:01, Wolfgang Nothdurft <[email protected]> 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?
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
