[Swan] nic-offload, was Re: [External] : Re: Question on opportunistic ipsec for multiple interfaces on same subnet
Mamta Gambhir
mamta.gambhir at oracle.com
Wed Feb 14 09:58:57 EET 2024
Hi Paul,
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.
This works when I have different subnets
conn private-or-clear
authby=null
leftid=%null
rightid=%null
left=192.167.0.1
right=%opportunisticgroup
negotiationshunt=passthrough
failureshunt=passthrough
ikev2=insist
auto=route
type=transport
nic-offload=packet
conn private-or-clear-2
authby=null
leftid=%null
rightid=%null
left=192.166.0.2
right=%opportunisticgroup
negotiationshunt=passthrough
failureshunt=passthrough
ikev2=insist
auto=route
type=transport
nic-offload=packet
This below only works for only one interface say 192.166.0.1
conn private-or-clear
authby=null
leftid=%null
rightid=%null
left=192.166.0.1
right=%opportunisticgroup
negotiationshunt=passthrough
failureshunt=passthrough
ikev2=insist
auto=route
type=transport
nic-offload=packet
conn private-or-clear-2
authby=null
leftid=%null
rightid=%null
left=192.166.0.2
right=%opportunisticgroup
negotiationshunt=passthrough
failureshunt=passthrough
ikev2=insist
auto=route
type=transport
nic-offload=packet
Above had worked for me in the past on both interfaces.
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
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
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
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
Is there any known issue?
Thanks
Mamta
From: Paul Wouters <paul at nohats.ca>
Date: Tuesday, December 19, 2023 at 1:08 PM
To: Mamta Gambhir <mamta.gambhir at oracle.com>
Cc: swan at lists.libreswan.org <swan at lists.libreswan.org>
Subject: nic-offload, was Re: [External] : Re: [Swan] Question on opportunistic ipsec for multiple interfaces on same subnet
I am investigating the same problem. It seems that crypto offloading is working but packet offloading is not.
I’m not sure if the Linux api changed since the libreswan code was merged in a year ago. But it could also just be a bug in our end.
Paul
Sent using a virtual keyboard on a phone
On Dec 19, 2023, at 15:46, Mamta Gambhir <mamta.gambhir at oracle.com> wrote:
Hi Paul,
I had a question, I recently introduced nic-offload in my .conf files and have been seeing problems with IPSec connections in this config for one of the interfaces. My .conf file looks like –
conn private-or-clear
authby=null
leftid=%null
rightid=%null
left=192.168.6.127
right=%opportunisticgroup
negotiationshunt=passthrough
failureshunt=passthrough
ikev2=insist
auto=route
type=transport
nic-offload=packet
conn private-or-clear-2
authby=null
leftid=%null
rightid=%null
left=192.168.6.128
right=%opportunisticgroup
negotiationshunt=passthrough
failureshunt=passthrough
ikev2=insist
auto=route
type=transport
nic-offload=packet
I am using Nvidia Cx7 NIC which supports packet offloads, but if I use nic-offload I see following error.
Dec 19 11:30:34 scaqat03adm07.us.oracle.com pluto[20740]: "private-or-clear#192.168.0.0/20"[1] ...192.168.6.131 #1: STATE_V2_PARENT_I2: 60 second timeout exceeded after 7 retransmits. Possible authentication failure: no a>
Dec 19 11:30:34 scaqat03adm07.us.oracle.com pluto[20740]: ERROR: "private-or-clear#192.168.0.0/20"[1] ...192.168.6.131 #4: netlink response for Del SA esp.9104cd14 at 192.168.6.127: No such process (errno 3)
Dec 19 11:30:34 scaqat03adm07.us.oracle.com pluto[20740]: "private-or-clear#192.168.0.0/20"[1] ...192.168.6.131 #1: kernel_xfrm_policy_add() adding offload via interface re0 for IPsec policy, type: Packet
Without nic-offload , all seems good on both interfaces. Any thoughts on this will be highly appreciated.
Thanks
Mamta
From: Mamta Gambhir <mamta.gambhir at oracle.com>
Date: Thursday, August 31, 2023 at 10:05 AM
To: Paul Wouters <paul at nohats.ca>
Cc: swan at lists.libreswan.org <swan at lists.libreswan.org>
Subject: Re: [External] : Re: [Swan] Question on opportunistic ipsec for multiple interfaces on same subnet
Thanks Paul. The config for 2 private-or-clear sections seem to work as desired. I haven’t run any traffic but wanted to provide update as iCMP traffic works.
000 #21: "private-or-clear#192.168.0.0/20"[7] ...192.168.0.1:500 STATE_V2_ESTABLISHED_IKE_SA (established IKE SA); REKEY in 28490s; REPLACE in 28760s; newest; idle;
000 #23: "private-or-clear#192.168.0.0/20"[7] ...192.168.0.1:500 STATE_V2_ESTABLISHED_CHILD_SA (established Child SA); REKEY in 28490s; REPLACE in 28760s; newest; eroute owner; IKE SA #21; idle;
000 #23: "private-or-clear#192.168.0.0/20"[7] ...192.168.0.1 esp.2ce74258 at 192.168.0.1 esp.5ec5bed9 at 192.168.0.3 Traffic: ESPin=0B ESPout=256B ESPmax=2^63B
000 #24: "private-or-clear#192.168.0.0/20"[8] ...192.168.0.2:500 STATE_V2_ESTABLISHED_IKE_SA (established IKE SA); REKEY in 27823s; REPLACE in 28773s; newest; idle;
000 #26: "private-or-clear#192.168.0.0/20"[8] ...192.168.0.2:500 STATE_V2_ESTABLISHED_CHILD_SA (established Child SA); REKEY in 27899s; REPLACE in 28773s; newest; eroute owner; IKE SA #24; idle;
000 #26: "private-or-clear#192.168.0.0/20"[8] ...192.168.0.2 esp.48581d25 at 192.168.0.2 esp.f756432e at 192.168.0.3 Traffic: ESPin=256B ESPout=256B ESPmax=2^63B
000 #25: "private-or-clear#192.168.0.0/20"[9] ...192.168.0.2:500 STATE_V2_PARENT_R1 (sent IKE_SA_INIT (or IKE_INTERMEDIATE) response); DISCARD in 172s; idle;
000 #27: "private-or-clear-2#192.168.0.0/20"[6] ...192.168.0.2:500 STATE_V2_ESTABLISHED_IKE_SA (established IKE SA); REKEY in 28148s; REPLACE in 28790s; newest; idle;
000 #28: "private-or-clear-2#192.168.0.0/20"[6] ...192.168.0.2:500 STATE_V2_ESTABLISHED_CHILD_SA (established Child SA); REKEY in 27943s; REPLACE in 28790s; newest; eroute owner; IKE SA #27; idle;
000 #28: "private-or-clear-2#192.168.0.0/20"[6] ...192.168.0.2 esp.b13040cf at 192.168.0.2 esp.774c0700 at 192.168.0.4 Traffic: ESPin=128B ESPout=128B ESPmax=2^63B
000 #29: "private-or-clear-2#192.168.0.0/20"[7] ...192.168.0.1:500 STATE_V2_ESTABLISHED_IKE_SA (established IKE SA); REKEY in 28254s; REPLACE in 28794s; newest; idle;
000 #30: "private-or-clear-2#192.168.0.0/20"[7] ...192.168.0.1:500 STATE_V2_ESTABLISHED_CHILD_SA (established Child SA); REKEY in 28200s; REPLACE in 28794s; newest; eroute owner; IKE SA #29; idle;
000 #30: "private-or-clear-2#192.168.0.0/20"[7] ...192.168.0.1 esp.c103f6fd at 192.168.0.1 esp.9a1be691 at 192.168.0.4 Traffic: ESPin=128B ESPout=128B ESPmax=2^63B
From: Paul Wouters <paul at nohats.ca>
Date: Tuesday, August 29, 2023 at 4:17 PM
To: Mamta Gambhir <mamta.gambhir at oracle.com>
Cc: swan at lists.libreswan.org <swan at lists.libreswan.org>
Subject: Re: [External] : Re: [Swan] Question on opportunistic ipsec for multiple interfaces on same subnet
On Tue, 29 Aug 2023, Mamta Gambhir wrote:
>
>
>
>
>
> I was hoping above should be working or will need changes too. I am using equivalent of libreswan 5.0.
>
> Though your suggestion of having multiple private (private/private2)sections will be most appropriate I wasn’t aware of that. Thank
> you.I am assuming I will need private2 policies file too.
>
> I am open to try and test the changes as needed in programs/pluto/foodgroups.c to make this work as our goal is to get above going.
Actually, looking at the code it seems the hardcoded names for
foodgroups has completely vanished.
So I think you can do this:
conn private-or-clear
authby=null
leftid=%null
rightid=%null
left=192.168.0.1
right=%opportunisticgroup
negotiationshunt=passthrough
failureshunt=passthrough
ikev2=insist
auto=route
type=transport
conn private-or-clear-2
authby=null
leftid=%null
rightid=%null
left=192.168.0.2
right=%opportunisticgroup
negotiationshunt=passthrough
failureshunt=passthrough
ikev2=insist
auto=route
type=transport
# /etc/ipsec.d/policies/private-or-clear
192.168.0.0/24
# /etc/ipsec.d/policies/private-or-clear-2
192.168.0.0/24
Let me know if that works?
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20240214/f289b44b/attachment-0001.htm>
More information about the Swan
mailing list