From: Paul Wouters <p...@nohats.ca> Date: Saturday, March 8, 2025 at 8:34 AM To: Mamta Gambhir <mamta.gamb...@oracle.com> Cc: swan@lists.libreswan.org <swan@lists.libreswan.org> 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 -- swan@lists.libreswan.org To unsubscribe send an email to swan-le...@lists.libreswan.org
