Hi Dinesh, Thank you for the detailed write-up. The short answer is NO, the full Ipv6 support in Strongswan plugin is missing and never validated
1. IPv6 SPD Policies Installed as IPv4 (htonl(ADDRESS_IP6) bug) The root cause is that vl_api_address_family_t` is a u8 field in the VPP API. Wrapping its assignment with htonl() silently truncates on little-endian (x86) systems: htonl(ADDRESS_IP6) = htonl(1) = 0x01000000, which when stored as u8 becomes 0 = ADDRESS_IP4. I think bypass_all and bypass_port have no IPv6 awareness at all. the is_ipv6 flag was never propagated into those functions, meaning IKEv2 (UDP 500) and NAT-T (UDP 4500) bypass SPD entries are always installed as IPv4 regardless of the SA address family. This breaks IPv6 IKE negotiation even after fixing the protect entry. 1. IPv6 Tunnel SAs Not Resolving Endpoints Have you tried set both IS_TUNNEL | IS_TUNNEL_V6 for an IPv6 tunnel SA ? The vl_api_ipsec_sad_entry_t v1 in ipsec_sad_entry_add_del () has flat tunnel_src` /tunnel_dst address fields and relies on IS_TUNNEL_V6 for IPv6 derivation. I think vl_api_ipsec_sad_entry_v4_t should be used here which carries a full vl_api_tunnel_t struct 1. Remaining VPP Ipv6 support in strongswan plugin Route-based mode is missing completely in strongswan plugin Best regards Kai ________________________________ From: [email protected] <[email protected]> on behalf of Dinesh via lists.fd.io <[email protected]> Sent: 06 July 2026 14:47 To: [email protected] <[email protected]> Subject: [vpp-dev] IPSec IPv6 - Multiple Issues with IPv6 Tunnel SA and SPD policies via API Hi all, VPP version: 25.02 I am using strongSwan (v5.9.13) with the kernel-vpp plugin to establish IPv6 IPSec tunnels. I have encountered multiple issues with IPv6 IPSec when SAs and SPD policies are created via the VPP API. IPv4 IPSec works correctly with the same code path. Ipsec Configuration: conn temp_ipv6 keyexchange=ike left=2001:db8:100::1 leftsubnet=2001:cb9:1::/48 right=2001:db8:200::1 rightsubnet=2001:cb9:2::/48 ike=aes-sha1-modp1024 esp=aes-sha1 auto=start authby=secret Issue 1: IPv6 SPD Policies Inserted as IPv4 Type When the strongSwan kernel-vpp plugin creates SPD policies for IPv6 traffic selectors via the ipsec_spd_entry_add_del API, the policies are being inserted into the ip4-outbound and ip4-inbound-protect categories instead of ip6-outbound and ip6-inbound-protect. The IPv6 subnet addresses are being truncated and misinterpreted as IPv4 addresses. For example, the IPv6 subnet 2001:cb9:1::/48 appears as 32.1.12.185 (where 0x2001 = 32.1 and 0x0CB9 = 12.185 — the first 4 bytes of the IPv6 address treated as IPv4). vpp# sh ipsec all ip4-outbound: [9] priority 2690 action protect type ip4-outbound protocol any sa 8 local addr range 32.1.12.185 - 32.1.12.185 port range 0 - 65535 remote addr range 32.1.12.185 - 32.1.12.185 port range 0 - 65535 packets 0 bytes 0 ip6-outbound: (empty) ip4-inbound-protect: [8] priority 2690 action protect type ip4-inbound-protect protocol any sa 7 local addr range 32.1.12.185 - 32.1.12.185 port range 0 - 65535 remote addr range 32.1.12.185 - 32.1.12.185 port range 0 - 65535 packets 0 bytes 0 ip6-inbound-protect: (empty) Root Cause found: The issue was in the kernel_vpp_ipsec.c plugin code where the address_family (af) field in the vl_api_address_t structure was being set using htonl() // Broken code: mp->entry.local_address_start.af = htonl(ADDRESS_IP6); mp->entry.local_address_stop.af = htonl(ADDRESS_IP6); mp->entry.remote_address_start.af = htonl(ADDRESS_IP6); mp->entry.remote_address_stop.af = htonl(ADDRESS_IP6); Fix Applied: mp->entry.local_address_start.af = ADDRESS_IP6; mp->entry.local_address_stop.af = ADDRESS_IP6; mp->entry.remote_address_start.af = ADDRESS_IP6; mp->entry.remote_address_stop.af = ADDRESS_IP6; API trace after Fix: vl_api_ipsec_spd_entry_add_del_t: is_add: 1 entry: spd_id: 1 priority: 2690 is_outbound: 0 sa_id: 1 policy: IPSEC_API_SPD_ACTION_PROTECT protocol: 0 remote_address_start: 2001:cb9:2:: remote_address_stop: 2001:cb9:2:ffff:ffff:ffff:ffff:ffff local_address_start: 2001:cb9:1:: local_address_stop: 2001:cb9:1:ffff:ffff:ffff:ffff:ffff Issue 2: IPv6 Tunnel SA - Tunnel Endpoints Not Resolved Even after fixing the SPD policy issue, the IPv6 tunnel SA does not show resolved tunnel endpoints. The SA is created with the correct IPSEC_API_SAD_FLAG_IS_TUNNEL_V6 flag and correct IPv6 tunnel addresses, but VPP does not resolve them. API trace - IPv6 SA Creation vl_api_ipsec_sad_entry_add_del_t: is_add: 1 entry: sad_id: 2 spi: 3246572560 protocol: IPSEC_API_PROTO_ESP crypto_algorithm: IPSEC_API_CRYPTO_ALG_AES_CBC_128 crypto_key: length: 16 integrity_algorithm: IPSEC_API_INTEG_ALG_SHA1_96 integrity_key: length: 20 flags: IPSEC_API_SAD_FLAG_IS_TUNNEL_V6 tunnel_src: 2001:db8:100::1 tunnel_dst: 2001:db8:200::1 tx_table_id: 0 VPP SA Output - IPv6 (Broken) vpp# sh ipsec sa 0 [0] sa 571 (0x23b) spi 3394444776 (0xca531de8) protocol:esp flags:[tunnel-v6 inbound ] locks 2 salt 0x0 thread-index:65535 seq 0 seq-hi 0 window-size: 64 window: Bl <- 1111111111111111111111111111111111111111111111111111111111111111 Tl crypto alg aes-cbc-128 key 0ac690e497b9f452df78ee5e1c372256 integrity alg sha1-96 key 6f9c144c0b0f1d93728124fe7141ba1679c528b0 UDP:[src:0 dst:0] tx/rx:[packets:0 bytes:0] SA errors: "packets lost":[packets:0] "hand-off":[packets:0] "Integrity check failed":[packets:0] "Decryption failed":[packets:0] "crypto engine error (dropped)":[packets:0] "SA replayed packet":[packets:0] "undersized packet":[packets:0] "no buffers (dropped)":[packets:0] "buffer with oversized header (dropped)":[packets:0] "no enough buffer tail space (dropped)":[packets:0] "no tunnel protocol":[packets:0] "unsupported payload":[packets:0] "sequence number cycled (dropped)":[packets:0] "crypto queue full (dropped)":[packets:0] "no Encrypting SA (dropped)":[packets:0] "IP fragments drop":[packets:0] VPP SA output - IPv4 (Working for comparison) vpp# sh ipsec sa 1 [1] sa 2 (0x2) spi 3355970896 protocol:esp flags:[tunnel] crypto alg aes-cbc-128 key ece4e008557be611e97c6a34201f4372 integrity alg sha1-96 key 2c1f0ace8af1d7385eabebbcafa3ea9128037a6c table-ID:0 [50.50.50.2->50.50.50.3] hop-limit:255 point-to-point CS0 [resolved] [none] [resolved via fib-entry: 50] Issue 3: Packet Drop After ESP6 Encryption Due to the unresolved tunnel endpoints, encrypted IPv6 packets are dropped after encryption. Packet trace - IPv6 (Broken) ip6-lookup fib 5 dpo-idx 25 ICMP6: 2001:cb9:1::2 -> 2001:cb9:2::2 ip6-rewrite tx_sw_if_index 7 : ipv6 via 2001:db8:200::1 ipsec_loop ipsec6-output-feature spd 1 policy 9 esp6-encrypt esp: sa-index 1 spi 3351494297 seq 2 crypto aes-cbc-128 integrity sha1-96 ipsec_loop-output ← Goes directly to interface output IP6: de:ad:00:00:00:01 -> de:ad:00:00:00:02 IPSEC_ESP: 2001:cb9:1::2 -> 2001:cb9:2::2 ← Inner IPs, no outer tunnel header ethernet-input error-drop ethernet-input: l3 mac mismatch ← Dropped Packet Trace - IPv4 (Working for comparison) ip4-rewrite tx_sw_if_index 7 : ipv4 via 50.50.50.3 ipsec_loop ipsec4-output-feature spd 1 policy 11 esp4-encrypt esp: sa-index 3 spi 3450312993 seq 22 crypto aes-cbc-128 integrity sha1-96 ip4-load-balance ← Re-enters IP lookup with OUTER header fib 7 dpo-idx 15 IPSEC_ESP: 50.50.50.2 -> 50.50.50.3 ← Outer tunnel IPs correctly applied ip4-rewrite tx_sw_if_index 3 via 40.40.40.1 eth2 ← Routes via physical interface Is there a known issue with the v1 API handler not correctly processing IPv6 tunnel endpoints? Or this is an existing bug that needs to resolved for IPv6 ? Can someone confirm whether adding an ipv6 tunnel SA has an issue ? Any guidance on resolving these issues would be greatly appreciated. Thanks, Dinesh
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#27109): https://lists.fd.io/g/vpp-dev/message/27109 Mute This Topic: https://lists.fd.io/mt/120135925/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
