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))
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
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
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
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
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
>
