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 <[email protected]>
Date: Tuesday, December 19, 2023 at 1:08 PM
To: Mamta Gambhir <[email protected]>
Cc: [email protected] <[email protected]>
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 <[email protected]> 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 [email protected]: 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 <[email protected]>
Date: Thursday, August 31, 2023 at 10:05 AM
To: Paul Wouters <[email protected]>
Cc: [email protected] <[email protected]>
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
[email protected] [email protected] 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
[email protected] [email protected] 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
[email protected] [email protected] 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
[email protected] [email protected] Traffic: ESPin=128B
ESPout=128B ESPmax=2^63B
From: Paul Wouters <[email protected]>
Date: Tuesday, August 29, 2023 at 4:17 PM
To: Mamta Gambhir <[email protected]>
Cc: [email protected] <[email protected]>
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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
