## Summary
When a VPP-managed WAN interface is configured both as the NAT44 outside interface and as the endpoint for route-mode IPsec/VTI, inbound IKE/ESP does not reach the VPP IPsec dataplane correctly.
There are two observable failure stages:
1. With the default NAT44 behavior, inbound UDP/500, UDP/4500, and native ESP reach `nat44-out2in` before local/IPsec processing and are dropped with `no translation`.
2. After temporarily enabling endpoint-independent NAT forwarding with `sudo vppctl nat44 forwarding enable`, IKE can establish and traffic can work only through the Linux fallback. VPP traces show `ipsec4-no-such-tunnel -> linux-cp-punt`; `show ipsec sa` remains empty and the expected route-mode `ipsec<reqid>` interface is not present.
This makes VPP NAT44 and VPP route-mode IPsec acceleration unusable together on the same WAN interface. Kernel IPsec continues to work, so tunnel establishment alone can misleadingly look successful.
## Version and hardwareTested 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:
```
VPP version: v25.10.0-48~vyos20260206142847.f850754fc# 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)
```
NIC: Intel X540 dual-port,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; both ports managed by VPPI have not booted the August nightly to repeat that second stage at runtime.
## Minimal t## 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
```
The addresses abovThese are documentation prefixes replacingaddresses, not the addresses used in the test.
## Relevant c## Configuration on VyOS A
VPP and NAT44: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'
```
Route-mode IPsec/VTI (PSK and IDs replaced):
```
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 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/VTI configuration and does not need VPP NAT44 for the failure to reproduce.
## Steps to r## Reproducetion
1. Commit the configuration and reboot VyOS A so VPP starts with IPsec acceleration enabled.
2. Establish the IKEv2 CHILD_SA from VyOS B.
32. Send traffic acrossEstablish the VTI and trace the inbound WAN packets in VPPCHILD_SA from VyOS B and send traffic over the VTI.
43. Check the NAT44 and IPsec runtime state:Trace inbound packets and check:
```
sudo vppctl show nat44 interfaces
sudo vppctl show ipsec all
sudo vppctl show interface
```
54. Temporarily runRun `sudo vppctl nat44 forwarding enable`, re-establish the CHILD_SA, and repeat the trace/state checks.
## Actual behavior## Result
Before enablingWith the configured NAT44 forwarding:state:
```
... -> nat44-out2in -> error-drop
NAT44 out2in: no translation
```
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`, the tunnel may pass traffic, but it is not accelerated:
```
... -> ipsec4-no-such-tunnel -> linux-cp-punt
```
The Linux XFRM listener reportlogs successful proccessing::
```
ipsec sa add ... success
Tunnel protect update success for index : 7
```
However,but VPP still has no SA or route-mode IPsec interface::
```
$ sudo vppctl show ipsec all
SPD Bindings:
IPSec async mode: off
```
No `ipsec1` (for XFRM reqid 1) appears in `show interface`.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, Manually creating it with `sudo vppctl ipsec itf create instance 1` does not fix the import;but the trace still shows `linux-cp-punt`, later XFRM event processing removes/recreates state and theso that is kernel IPsec rather than VPP SA remains absentacceleration.
Forcing NAT-T changes ESP into UDP/4500 and can make the VTI ping succeed, but the trace still shows the packet being punted to Linux. Therefore this is a kernel fallback, not VPP IPsec acceleration.## Expected result
## Expected behavior
- IKE and ESP addressed to the router's own WAN address should bypass NAT44 translation lookup and continue to local/IPsec processing without requiring the runtime-only `nat44 forwarding enable` workaroundWAN address should reach local/IPsec processing instead of being dropped by NAT44.
- With `set vpp settings ipsec-acceleration` enabled, XFRM route-mode XFRM events mode should create the expectedte `ipsec<reqid>` interface, install the inbound/outbound SAs, and bind tunnel protection.
- Traffic should traverse thuse VPP IPsec deencrypt/endecrypt nodes, with and increment VPP SA counters increasing andrs without `linux-cp-punt`.
## Control tests and workarounds## Notes
- AES-CBC-256 + HMAC-SHA2-256-128 was verifiedworks in an isolated VPP IPsec test: VPP imported the algorithm correctly and decrypteds packets with zeroout crypto errors. This is not an algorithm negotiation failureproblem.
- Removing VPP- Linux IPsec acceleration and using Linux IPsec allows the complete IPsec +works with the same tunnel and NAT/PBR path to work.
- Separat- Using IPsec and VPP NAT44 onto different physical/VLANseparate interfaces is expected tofor NAT44 and IPsec avoids the NAT44 feature-order collisionfirst failure.
- `nat44 forwarding enable` is only a partial/runtime workaround: it allows unmatched packets to continue bubypasses the NAT drop; it does not makefix the route-mode SA import workmissing VPP SA.
## Related tasks/code:
- T8201: VPP drops packets destined to its local interfaces when using VTI based IPsec. That task is different: its trace shows a valid VPP SA and successful `esp4-decrypt-tun`, while this report has no VPP SA and hits `ipsec4-no-such-tunnel`.
- T7930: NAT44 `forwarding_enabled` handling. That task concerns the flag being reset by NAT configuration; has a valid VPP SA and reaches `esp4-decrypt-tun` before dropping local traffic. here the default feature order drops locally addressed IKE/ESP and enabling the flag still leaves route-mode SA import brokenThis report fails earlier and has no VPP SA.
- T8116: VPP IPsec faulting. The fixed crash path is different from the miss- T7930 covers NAT44 forwarding state being reset during SA/interface state hereconfiguration.
- Route-mode implementation constructs `ipsec%d` from XFRM reqid and calls `ipsec_itf_create`; the observed runtime state does not match that intended behavior.
No matching open or closed task was found for the combined same-interface NAT44 + route-mode IPsec failureT8116 covers a resolved VPP/XFRM crash.