I tried the same subnet case with out offloads and that works very cleanly.
# ip x s s src 192.167.0.2 dst 192.167.0.3 proto esp spi 0xcdc36e21 reqid 16413 mode transport replay-window 0 flag esn aead rfc4106(gcm(aes)) 0x0c9b5d0069a4f64db6a76e31e13e7ce798b0675d2e16cce2c2f4b9a0629e6c17b327a24e 128 lastused 2024-02-16 00:01:51 anti-replay esn context: seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0x2 replay_window 128, bitmap-length 4 00000000 00000000 00000000 00000000 sel src 192.167.0.2/32 dst 192.167.0.3/32 src 192.167.0.3 dst 192.167.0.2 proto esp spi 0xa6ce11bc reqid 16413 mode transport replay-window 0 flag esn aead rfc4106(gcm(aes)) 0x11be460f2a3cab41ecaf50aac68e1374d9b73001f77923e5ec5fa90d45671b1f9ab9ffc2 128 lastused 2024-02-16 00:01:51 anti-replay esn context: seq-hi 0x0, seq 0x2, oseq-hi 0x0, oseq 0x0 replay_window 128, bitmap-length 4 00000000 00000000 00000000 00000003 sel src 192.167.0.3/32 dst 192.167.0.2/32 src 192.167.0.1 dst 192.167.0.4 proto esp spi 0x3f97df8e reqid 16409 mode transport replay-window 0 flag esn aead rfc4106(gcm(aes)) 0x8026c8ed144f78386ac40c6d7a32047a236ae38029361742809db79548e004c05381424b 128 lastused 2024-02-15 23:57:57 anti-replay esn context: seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0x3 replay_window 128, bitmap-length 4 00000000 00000000 00000000 00000000 sel src 192.167.0.1/32 dst 192.167.0.4/32 src 192.167.0.4 dst 192.167.0.1 proto esp spi 0xc3a3702f reqid 16409 mode transport replay-window 0 flag esn aead rfc4106(gcm(aes)) 0x3a6c08d7ee49d3221a9a01686ba3cceb574b5db2dfb586565e3c6f9779cbfeb0a66db19e 128 lastused 2024-02-15 23:57:57 anti-replay esn context: seq-hi 0x0, seq 0x3, oseq-hi 0x0, oseq 0x0 replay_window 128, bitmap-length 4 00000000 00000000 00000000 00000007 sel src 192.167.0.4/32 dst 192.167.0.1/32 src 192.167.0.1 dst 192.167.0.3 proto esp spi 0xe005d94b reqid 16405 mode transport replay-window 0 flag esn aead rfc4106(gcm(aes)) 0x9142c62ff83768ffd98db490d2a56be113b5842cf94c88276354963484151e69f72b6731 128 lastused 2024-02-15 23:57:50 anti-replay esn context: seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0x2 replay_window 128, bitmap-length 4 00000000 00000000 00000000 00000000 sel src 192.167.0.1/32 dst 192.167.0.3/32 src 192.167.0.3 dst 192.167.0.1 proto esp spi 0x7aaa3901 reqid 16405 mode transport replay-window 0 flag esn aead rfc4106(gcm(aes)) 0x65e0c16685a69928773161aa8aba0e1d399b0f8ac483fc4e8821b570ab2bfd2fea214dd1 128 lastused 2024-02-15 23:57:50 anti-replay esn context: seq-hi 0x0, seq 0x2, oseq-hi 0x0, oseq 0x0 replay_window 128, bitmap-length 4 00000000 00000000 00000000 00000003 sel src 192.167.0.3/32 dst 192.167.0.1/32 However both crypto and packet offloads don’t work with same subnets on two interfaces. I am using libreswan (from the daily build of 29th Jan) . Is there any other missing commits? Thanks Mamta From: Mamta Gambhir <mamta.gamb...@oracle.com> Date: Thursday, February 15, 2024 at 10:30 AM To: Paul Wouters <p...@nohats.ca> Cc: swan@lists.libreswan.org <swan@lists.libreswan.org> Subject: Re: nic-offload, was Re: [External] : Re: [Swan] Question on opportunistic ipsec for multiple interfaces on same subnet Thanks Paul Regarding your questions- * No I was able to get it working without nic-offload in the past with same .conf files with two private-or-clear sections on same subnet, few weeks ago. * I will try nic-offload=crypto(also without nic-offload) and soon update. * But What I wanted to bring up here is that two private-or-clear sections work with different subnets but not with same subnet.(both with same .conf file nic-offload=packet) Also Just to ensure if ipsec policies aren’t there it works with same config(both interfaces on same subnet) too. I will upload “journalctl -u ipsec” to check on errors. From: Paul Wouters <p...@nohats.ca> Date: Wednesday, February 14, 2024 at 2:13 PM To: Mamta Gambhir <mamta.gamb...@oracle.com> Cc: swan@lists.libreswan.org <swan@lists.libreswan.org> Subject: Re: nic-offload, was Re: [External] : Re: [Swan] Question on opportunistic ipsec for multiple interfaces on same subnet On Wed, 14 Feb 2024, Mamta Gambhir wrote: > I have no issues now with nic-offload=packet , but do see issues with > communication when I use same subnet in the two > private-or-clear sections. > Above had worked for me in the past on both interfaces. You mean without nic-offload? > I am now using 6.7 , Nvidia CX7 NICs with full offload and libreswan rc2. > > Even though I see below SA’s but only one interface 192.166.0.1 can > communicate.. > > # ip x s s > > src 192.166.0.2 dst 192.166.0.4 > proto esp spi 0x95c4305d reqid 16409 mode transport > replay-window 0 flag esn > aead rfc4106(gcm(aes)) > 0x11c6235b5fc0a13b8978ab112d4a8ede882dd70930fa0650afb996f18f722cd74aefe6aa 128 > anti-replay esn context: > seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0x0 > replay_window 128, bitmap-length 4 > 00000000 00000000 00000000 00000000 > crypto offload parameters: dev eth101 dir out > sel src 192.166.0.2/32 dst 192.166.0.4/32 > > src 192.166.0.4 dst 192.166.0.2 > proto esp spi 0x1fa69d08 reqid 16409 mode transport > replay-window 0 flag esn > aead rfc4106(gcm(aes)) > 0xcadab4aaa383bf46afe8ae39b54e289b0c4ab082ebda373face91d998c49c58f2fc6c5a1 128 > anti-replay esn context: > seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0x0 > replay_window 128, bitmap-length 4 > 00000000 00000000 00000000 00000000 > crypto offload parameters: dev eth101 dir in > sel src 192.166.0.4/32 dst 192.166.0.2/32 These two seem a valid IPsec SA pair, but with no traffic? > src 192.166.0.2 dst 192.166.0.4 > proto esp spi 0x00000000 reqid 0 mode transport > replay-window 0 > anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000 > crypto offload parameters: dev eth101 dir out > sel src 192.166.0.2/32 dst 192.166.0.4/32 proto icmp type 8 code 0 dev > eth100 this is a %trap (ACQUIRE), notice the 0 spi. This one is negotiating still - possibly failing negotiation? > src 192.166.0.1 dst 192.166.0.3 > proto esp spi 0xb97f970a reqid 16405 mode transport > replay-window 0 flag esn > aead rfc4106(gcm(aes)) > 0xa7b8e04ae34c2a3c9beb468fa05cec734a2f393d4f7d1f31965850423ff93f2591983356 128 > anti-replay esn context: > seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0x0 > replay_window 128, bitmap-length 4 > 00000000 00000000 00000000 00000000 > crypto offload parameters: dev eth100 dir out > sel src 192.166.0.1/32 dst 192.166.0.3/32 > > src 192.166.0.3 dst 192.166.0.1 > proto esp spi 0xf9606933 reqid 16405 mode transport > replay-window 0 flag esn > aead rfc4106(gcm(aes)) > 0xa5eb4d64d5823f5fd0db2afaaa757d9a7ed2be24291bbc511deccece13e10003084fc6be 128 > anti-replay esn context: > seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0x0 > replay_window 128, bitmap-length 4 > 00000000 00000000 00000000 00000000 > crypto offload parameters: dev eth100 dir in > sel src 192.166.0.3/32 dst 192.166.0.1/32 Another one that looks valid but 0 traffic counters? > src 192.166.0.1 dst 192.166.0.3 > proto esp spi 0x00000000 reqid 0 mode transport > replay-window 0 > anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000 > crypto offload parameters: dev eth100 dir out > sel src 192.166.0.1/32 dst 192.166.0.3/32 proto udp sport 48400 dport > 1025 dev eth100 Another one that is negotiating? > Is there any known issue? Can't really tell without log files on what happened. Does it work with nic-offload=crypto ? Eg can we see if packet offload is the problem here? Paul
_______________________________________________ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan