How to Create and Configure IPsec XFRM Interfaces in Linux Using ip link

Traditional IPsec implementations on Linux historically operated in policy-based mode, where the kernel’s XFRM (transform) framework intercepted and encapsulated packets matching specific Security Policies (SPs) and Security Associations (SAs). While functional, policy-based IPsec lacks routable interface endpoints, making it difficult to use standard routing protocols (such as BGP or OSPF), dynamic routing tables, network namespaces, and firewall packet filtering tools.

To provide modern, route-based VPN capabilities, Linux kernel 4.19 introduced native XFRM virtual interfaces (type xfrm) into the iproute2 suite. XFRM interfaces bind directly to unique interface identifiers (if_id) configured inside IPsec SAs and SPs. This approach replaces older VTI (Virtual Tunnel Interface) constructs, eliminating MTU-clamping bugs, supporting both IPv4 and IPv6 over identical hardware, and providing first-class virtual network devices that integrate seamlessly with Linux routing. If you build enterprise tunnels on Linux, you may also find our guides on configuring network hardware devices with devlink and managing multipath routing objects with ip nexthop helpful.

Verifying Kernel Support for XFRM Interfaces

Before creating an XFRM interface, confirm that your Linux kernel has the XFRM interface driver module compiled and available:

# Check for the xfrm_interface kernel module
modinfo xfrm_interface

# Load the module into the active kernel
sudo modprobe xfrm_interface

If the module loads without error, your system is fully prepared to instantiate XFRM devices.

Creating an XFRM Virtual Interface Device

Creating an XFRM interface requires binding it to an underlying physical or overlay interface (via the dev parameter) and designating an integer if_id (interface ID):

# Create xfrm0 bound to physical device eth0 with interface ID 42
sudo ip link add name xfrm0 type xfrm dev eth0 if_id 42

# Verify the interface creation
ip link show xfrm0

The resulting output confirms the device parameters: xfrm0@eth0: ... if_id 42. The if_id acts as the cryptographic handshake key linking this network adapter to matching IPsec security rules.

Configuring IP Addresses and Bringing the Interface Online

Once created, treat the XFRM device as a regular point-to-point or routed network interface:

# Assign an internal tunnel IP address to xfrm0
sudo ip address add 10.100.0.1/30 dev xfrm0

# Bring the interface link state up
sudo ip link set dev xfrm0 up

Binding IPsec Security Associations and Policies with if_id

For network traffic routed through xfrm0 to be encapsulated and encrypted, matching IPsec states and policies must reference the identical if_id. Using the low-level ip xfrm tool (or configuring your IKE daemon such as strongSwan or Libreswan):

# Add an outbound IPsec state with if_id 42
sudo ip xfrm state add src 198.51.100.1 dst 203.0.113.1 proto esp spi 0x1000 \
    reqid 1 mode tunnel if_id 42 \
    aead "rfc4106(gcm(aes))" 0x0123456789abcdef0123456789abcdef01234567 128

# Add an inbound IPsec state with if_id 42
sudo ip xfrm state add src 203.0.113.1 dst 198.51.100.1 proto esp spi 0x2000 \
    reqid 1 mode tunnel if_id 42 \
    aead "rfc4106(gcm(aes))" 0x0123456789abcdef0123456789abcdef01234567 128

# Add the corresponding IPsec security policies with if_id 42
sudo ip xfrm policy add dir out if_id 42 tmpl src 198.51.100.1 dst 203.0.113.1 proto esp reqid 1 mode tunnel
sudo ip xfrm policy add dir in if_id 42 tmpl src 203.0.113.1 dst 198.51.100.1 proto esp reqid 1 mode tunnel

Because the policy specifies if_id 42, the kernel only enforces encryption on packets entering or exiting the xfrm0 virtual device.

Routing Traffic Through the Route-Based IPsec Tunnel

With the cryptographic layer bound to the interface, routing entire remote subnets across the secure tunnel simply requires standard ip route statements:

# Route remote office subnet 10.200.0.0/16 through the XFRM interface
sudo ip route add 10.200.0.0/16 dev xfrm0

# Verify the routing path
ip route get 10.200.5.25

The kernel cleanly routes packets destined for the remote subnet into xfrm0, where they are encrypted via hardware offload or kernel AES-GCM and transmitted over eth0 without complex iptables marks.

Removing Obsolete XFRM Interfaces

When decommissioning a VPN link, removing the virtual interface is instantaneous:

# Bring the interface down
sudo ip link set dev xfrm0 down

# Delete the XFRM device
sudo ip link del xfrm0

This route-based architecture provides unmatched simplicity, deterministic routing, and high throughput for modern cloud infrastructure.