[Swan] nic-offload, was Re: [External] : Re: Question on opportunistic ipsec for multiple interfaces on same subnet
Mamta Gambhir
mamta.gambhir at oracle.com
Thu Feb 15 20:30:33 EET 2024
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 <paul at nohats.ca>
Date: Wednesday, February 14, 2024 at 2:13 PM
To: Mamta Gambhir <mamta.gambhir at oracle.com>
Cc: swan at lists.libreswan.org <swan at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20240215/fc915605/attachment-0001.htm>
More information about the Swan
mailing list