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.gamb...@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@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.gamb...@oracle.com> > Date: Thursday, August 31, 2023 at 10:05 AM > To: Paul Wouters <p...@nohats.ca> > Cc: swan@lists.libreswan.org <swan@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@192.168.0.1 esp.5ec5bed9@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@192.168.0.2 esp.f756432e@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@192.168.0.2 esp.774c0700@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@192.168.0.1 esp.9a1be691@192.168.0.4 Traffic: ESPin=128B > ESPout=128B ESPmax=2^63B > > > From: Paul Wouters <p...@nohats.ca> > Date: Tuesday, August 29, 2023 at 4:17 PM > To: Mamta Gambhir <mamta.gamb...@oracle.com> > Cc: swan@lists.libreswan.org <swan@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
_______________________________________________ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
