Hello Paul,
In opportunistic IPsec .conf file(See below), I’m exploring options to enforce
different policies based on protocol and port — particularly for RoCEv2 and
general TCP/UDP traffic.
Current Goal:
* Offload UDP port 4791 (RoCEv2) traffic via NIC (nic-offload=packet)
* Offload all TCP traffic
* Handle other UDP traffic via software IPsec
My current config uses an opportunistic connection like:
conn private-or-clear
type=transport
auto=route
ikev2=insist
nic-offload=packet
negotiationshunt=passthrough
failureshunt=passthrough
authby=null
rightid=%null
leftid=%null
right=%opportunisticgroup
left=192.201.82.7
To achieve more granular control, I’ve considered adding manual xfrm policies
(example below), but this doesn't scale well when multiple peer IPs are
involved in opportunistic mode:
sudo ip xfrm policy add src ... proto tcp offload ...
Alternatively, I’m exploring whether multiple conn entries using leftprotoport
and rightprotoport can help apply per-protocol/port offload logic — even within
opportunistic or hybrid setups.Just wanted to check if libreswan supports such
selective handling (e.g. RoCEv2 offloaded, other UDP not) using connection
blocks for opportunistic peers? Or is there a better strategy to manage this
with minimal manual xfrm state?
Thanks in advance for your input.
From: Mamta Gambhir <[email protected]>
Date: Saturday, March 8, 2025 at 3:31 PM
To: Paul Wouters <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: [External] : Re: [Swan] Ipsec config with two sections one in
clear and one private-or-clear
From: Paul Wouters <[email protected]>
Date: Saturday, March 8, 2025 at 8:34 AM
To: Mamta Gambhir <[email protected]>
Cc: [email protected] <[email protected]>
Subject: [External] : Re: [Swan] Ipsec config with two sections one in clear
and one private-or-clear
On Fri, 7 Mar 2025, Mamta Gambhir via Swan wrote:
> I want to check if my ipsec config is appropriate I have two sections for two
> interfaces with same subnet.I would think the peer which has clear
> section in the same subnet in the opportunistic mode will communicate in
> clear. But Isee both interfaces successfully negotiate.
> See below
Similar to having two private-or-clear style connections, you should
have two clear style connections too?
<MG>So here is the thing I am having issues with two
private-or-clear/private-or-clear-2 in same subnet as I mentioned in
https://github.com/libreswan/libreswan/issues/2029 and still not getting much
success once.I had no issues with this in a 2-node setup but in a setup with
multiple nodes. I run into issues as I mentioned in that bug.
Now getting back to this config I am trying as an alternate to mitigate above
issues if I can have one interface doing everything in clear.
That means though my policy files list all nodes in that subnet but those peers
that want to do clear should be in clear (like node B with second interface in
clear).
> Node 1
>
> conn private-or-clear
> right=%opportunisticgroup
> left=10.106.2.33
>
> conn clear
> left=10.106.2.34
> right=%group
So what is in /etc/ipsec.d/policies/clear and
/etc/ipsec.d/policies/private-or-clear ?
Both nodes have this
# cat /etc/ipsec.d/policies/clear
10.106.2.0/24
# cat /etc/ipsec.d/policies/private-or-clear
10.106.2.0/24
> Node 2
>
> conn private-or-clear
> right=%opportunisticgroup
> left=10.106.2.35
> conn clear
> left=10.106.2.36
> right=%group
>
So what is in /etc/ipsec.d/policies/clear and
/etc/ipsec.d/policies/private-or-clear ?
# cat /etc/ipsec.d/policies/private-or-clear
10.106.2.0/24
# cat /etc/ipsec.d/policies/clear
10.106.2.0/24
> One would expect 33->35 successful and
It all depends on the entries in the policies files. If these have no
entries, then the conns are basically "empty" and never matching
anything.
If you have "clear" entries, when you start pluto, you can see the clear
entries using "ip xfrm policy".
And again, you will have to do all this twice if you have two IPs
covered in diffrent conns for clear, private-or-clear, etc.
<MG> The output confuses me, I wasn’t hoping to see any encrypted packets on
interface clre1 with say local ip 10.16.2.34 on Node A(similar on node B) .
# ethtool -S clre1 | grep ipsec
ipsec_rx_pkts: 2
ipsec_rx_bytes: 196
ipsec_rx_drop_pkts: 0
ipsec_rx_drop_bytes: 0
ipsec_tx_pkts: 2
ipsec_tx_bytes: 268
ipsec_tx_drop_pkts: 0
ipsec_tx_drop_bytes: 0
ipsec_rx_drop_sp_alloc: 0
ipsec_rx_drop_sadb_miss: 0
ipsec_rx_drop_syndrome: 0
ipsec_tx_drop_bundle: 0
ipsec_tx_drop_no_state: 0
ipsec_tx_drop_not_ip: 0
ipsec_tx_drop_trailer: 0
[root@scaqat26adm05vm01 ~]# ethtool -S clre0 | grep ipsec
ipsec_rx_pkts: 2
ipsec_rx_bytes: 196
ipsec_rx_drop_pkts: 0
ipsec_rx_drop_bytes: 0
ipsec_tx_pkts: 2
ipsec_tx_bytes: 268
ipsec_tx_drop_pkts: 0
ipsec_tx_drop_bytes: 0
ipsec_rx_drop_sp_alloc: 0
ipsec_rx_drop_sadb_miss: 0
ipsec_rx_drop_syndrome: 0
ipsec_tx_drop_bundle: 0
ipsec_tx_drop_no_state: 0
ipsec_tx_drop_not_ip: 0
ipsec_tx_drop_trailer: 0
[root@scaqat26adm05vm01 ~]# ip x p
src 10.106.2.33/32 dst 10.106.2.35/32
dir out priority 3850432 ptype main
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 16417 mode transport
crypto offload parameters: dev clre0 mode packet
src 10.106.2.35/32 dst 10.106.2.33/32
dir in priority 3850432 ptype main
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 16417 mode transport
crypto offload parameters: dev clre0 mode packet
src 10.106.2.34/32 dst 10.106.2.35/32
dir out priority 3850432 ptype main
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 16413 mode transport
crypto offload parameters: dev clre1 mode packet
src 10.106.2.35/32 dst 10.106.2.34/32
dir in priority 3850432 ptype main
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 16413 mode transport
crypto offload parameters: dev clre1 mode packet
src 10.106.2.34/32 dst 10.106.2.0/24
dir out priority 3850449 ptype main
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 0 mode transport
crypto offload parameters: dev clre1 mode packet
src 10.106.2.33/32 dst 10.106.2.0/24
dir out priority 3850449 ptype main
tmpl src 0.0.0.0 dst 0.0.0.0
proto esp reqid 0 mode transport
crypto offload parameters: dev clre0 mode packet
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src ::/0 dst ::/0 proto udp sport 500 dport 500
dir out priority 1 ptype main
crypto offload parameters: dev clre0 mode packet
if_id 0x3
src 0.0.0.0/0 dst 0.0.0.0/0 proto udp sport 500 dport 500
dir out priority 1 ptype main
crypto offload parameters: dev clre0 mode packet
if_id 0x3
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src ::/0 dst ::/0 proto udp sport 500 dport 500
dir out priority 1 ptype main
crypto offload parameters: dev clre1 mode packet
if_id 0x4
src 0.0.0.0/0 dst 0.0.0.0/0 proto udp sport 500 dport 500
dir out priority 1 ptype main
crypto offload parameters: dev clre1 mode packet
if_id 0x4
Appreciate the clarification , if my interpretation of clear isn’t correct.
Thanks
Mamta
Paul
_______________________________________________
Swan mailing list -- [email protected]
To unsubscribe send an email to [email protected]
