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 (#27096): https://lists.fd.io/g/vpp-dev/message/27096
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]]
-=-=-=-=-=-=-=-=-=-=-=-
