Tested version

Version:          VyOS 1.5.0
Release train:    circinus
Built on:         Mon 30 Mar 2026 18:57 UTC
Build commit ID:  cb47cdb72c6d08
Architecture:     x86_64
System type:      bare metal
VPP version:      v25.10.0-48~vyos20260206142847.f850754fc

Hardware: Intel X540 dual-port NIC; both ports are managed by VPP.

Problem

eth2 is both the VPP NAT44 outside interface and the local endpoint of a route-mode IPsec/VTI tunnel.

With dynamic NAT44 enabled, inbound IKE/ESP is sent to nat44-out2in and dropped with no translation. If I temporarily run sudo vppctl nat44 forwarding enable, the tunnel can establish, but traffic is punted to Linux instead of using VPP IPsec. show ipsec sa is empty and the expected ipsec<reqid> interface is missing.

Current rolling check

The latest nightly available when this was filed is 2026.08.14-0025-rolling.

The NAT part is still present in current rolling source. In src/conf_mode/vpp_nat_nat44.py, dynamic address translation explicitly disables NAT44 forwarding:

# Forwarding must be disabled when dynamic rules are present
enable_forwarding = not bool(config.get('address_pool', {}).get('translation'))
n.enable_disable_nat44_forwarding(enable_forwarding)

Source: https://github.com/vyos/vyos-1x/blob/32f3ce2d951e30335dc6216e3759d7c1fcef4832/src/conf_mode/vpp_nat_nat44.py#L459-L462

I also checked vyos-vpp-patches from the tested VPP package date (2026-03-16) through commit 15f9906b7169e767a1992d3b647ab32f95aab7d8. There are no later IPsec/XFRM changes; the only later VPP patch commit concerns DET44 tests. The route-mode code still creates ipsec%d from the XFRM instance and calls ipsec_itf_create():

https://github.com/vyos/vyos-vpp-patches/blob/15f9906b7169e767a1992d3b647ab32f95aab7d8/patches/vpp/0003-linux-cp-add-ipsec-interface-support-for-xfrm.patch#L91-L140

This confirms that the NAT44/local-IPsec conflict remains in rolling source. The missing VPP SA/interface after the forwarding override was reproduced on the version above; I have not booted the August nightly to repeat that second stage at runtime.

Topology

LAN A 198.51.100.0/24
        |
      eth1 (NAT44 inside)
        |
     VyOS A
      eth2 192.0.2.1/24 (NAT44 outside + IPsec endpoint)
        |
      eth2 192.0.2.2/24
     VyOS B
        |
LAN B 203.0.113.0/24

VTI: 169.254.100.1/30 <-> 169.254.100.2/30

These are documentation addresses, not the addresses used in the test.

Configuration on VyOS A

set interfaces ethernet eth1 address '198.51.100.1/24'
set interfaces ethernet eth2 address '192.0.2.1/24'
set interfaces vti vti0 address '169.254.100.1/30'
set protocols static route 203.0.113.0/24 interface 'vti0'

set vpp settings allow-unsupported-nics
set vpp settings interface eth1 num-rx-queues '1'
set vpp settings interface eth1 num-tx-queues '1'
set vpp settings interface eth2 num-rx-queues '1'
set vpp settings interface eth2 num-tx-queues '1'
set vpp settings ipsec-acceleration
set vpp nat nat44 address-pool translation interface 'eth2'
set vpp nat nat44 interface inside 'eth1'
set vpp nat nat44 interface outside 'eth2'

set vpn ipsec authentication psk LAB id 'left'
set vpn ipsec authentication psk LAB id 'right'
set vpn ipsec authentication psk LAB secret 'replace-me'
set vpn ipsec esp-group LAB-ESP mode 'tunnel'
set vpn ipsec esp-group LAB-ESP pfs 'disable'
set vpn ipsec esp-group LAB-ESP proposal 1 encryption 'aes256'
set vpn ipsec esp-group LAB-ESP proposal 1 hash 'sha256'
set vpn ipsec ike-group LAB-IKE key-exchange 'ikev2'
set vpn ipsec ike-group LAB-IKE proposal 1 dh-group '14'
set vpn ipsec ike-group LAB-IKE proposal 1 encryption 'aes256'
set vpn ipsec ike-group LAB-IKE proposal 1 hash 'sha256'
set vpn ipsec interface 'eth2'
set vpn ipsec site-to-site peer right authentication local-id 'left'
set vpn ipsec site-to-site peer right authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer right authentication remote-id 'right'
set vpn ipsec site-to-site peer right connection-type 'initiate'
set vpn ipsec site-to-site peer right default-esp-group 'LAB-ESP'
set vpn ipsec site-to-site peer right ike-group 'LAB-IKE'
set vpn ipsec site-to-site peer right local-address '192.0.2.1'
set vpn ipsec site-to-site peer right remote-address '192.0.2.2'
set vpn ipsec site-to-site peer right vti bind 'vti0'

VyOS B uses the mirrored VTI/IPsec configuration and does not need VPP NAT44.

Reproduction

1. Commit the configuration and reboot VyOS A.
2. Establish the CHILD_SA from VyOS B and send traffic over the VTI.
3. Trace inbound packets and check:

sudo vppctl show nat44 interfaces
sudo vppctl show ipsec all
sudo vppctl show interface

4. Run sudo vppctl nat44 forwarding enable, re-establish the CHILD_SA, and repeat the checks.

Result

With the configured NAT44 state:

$ sudo vppctl show nat44 interfaces
NAT44 interfaces:
 eth1 in
 eth2 out

... -> nat44-out2in -> error-drop
NAT44 out2in: no translation

After sudo vppctl nat44 forwarding enable:

... -> ipsec4-no-such-tunnel -> linux-cp-punt

The XFRM listener logs success:

ipsec sa add ... success
Tunnel protect update success for index : 7

but VPP has no SA:

$ sudo vppctl show ipsec all
SPD Bindings:
IPSec async mode: off

There is no ipsec1 interface for XFRM reqid 1. Creating it manually with sudo vppctl ipsec itf create instance 1 does not restore the SA import. Forcing NAT-T can make the VTI ping work, but the trace still shows linux-cp-punt, so that is kernel IPsec rather than VPP acceleration.

Expected result

• IKE and ESP addressed to the router's WAN address should reach local/IPsec processing instead of being dropped by NAT44.
• With ipsec-acceleration enabled, XFRM route mode should create ipsec<reqid>, install the SAs, and bind tunnel protection.
• Traffic should use VPP IPsec encrypt/decrypt nodes and increment VPP SA counters without linux-cp-punt.

Notes

• AES-CBC-256 + HMAC-SHA2-256-128 works in an isolated VPP IPsec test and decrypts packets without crypto errors. This is not an algorithm negotiation problem.
• Linux IPsec works with the same tunnel and NAT/PBR path.
• Using separate interfaces for NAT44 and IPsec avoids the first failure.
• nat44 forwarding enable only bypasses the NAT drop; it does not fix the missing VPP SA.

Related tasks:

• T8201 has a valid VPP SA and reaches esp4-decrypt-tun before dropping local traffic. This report fails earlier and has no VPP SA.
• T7930 covers NAT44 forwarding state being reset during configuration.
• T8116 covers a resolved VPP/XFRM crash.