Call for Contributions
This section needs improvements, examples and explanations.
Please take a look at the Contributing Guide for our Write Documentation.
VPP IPsec Configuration
VPP Dataplane in VyOS can offload IPSec processing from kernel. This allows to speed-up IPSec traffic handling significantly, when necessary conditions are met.
Note
VPP IPsec implementation is not as feature rich as Linux kernel IPsec. It supports only a subset of algorithms and modes.
Requirements
To make IPSec offloading work, following requirements must be met:
VPP dataplane must be configured.
VPP IPsec settings should be configured as needed.
IPSec should be configured in the VPN configuration section, see IPsec.
Both source and destination of the IPSec traffic must be reachable via VPP interfaces, so it can perform both encryption and decryption of the traffic.
Integration Details
VPP Dataplane offloads IPSec processing from kernel, but does not handle IPSec configuration itself. IPSec configuration management and control-plane operation, like IKE negotiation, is still done by the kernel and other daemons.
After an IPSec tunnel is configured in the kernel, VPP receives the necessary information via netlink messages and creates a corresponding SAs and policies to be able to offload the traffic.
When VPP is used for offloading IPsec, it creates a virtual interface of a specific type to connect to a peer. The type of the interface can be configured using the interface-type
parameter in the dataplane settings.
Supported IPsec Modes
VPP supports offloading IPsec connections in the following IPsec modes:
Tunnel mode
Transport mode
Supported Encryption and Integrity Algorithms
Warning
Since VPP dataplane is used only to offload IPsec traffic processing, algorithms mentioned below are applicable to ESP profiles in the IPsec configuration. IKE profiles are not affected by these limitations and can use any algorithms supported by the kernel.
VPP supports only the following encryption algorithms:
AES-CBC
VPP does not support the following encryption algorithms:
Null encryption
AES-CTR
AES-CCM with ICV
AES-GCM with ICV
Null encryption with AES-GMAC
3DES-EDE-CBC
Blowfish-CBC
Camellia-CBC
Camellia-COUNTER
Camellia-CCM with ICV
Serpent-CBC
Twofish-CBC
CAST-CBC
ChaCha20/Poly1305 with ICV
VPP supports the following integrity algorithms:
MD5 HMAC
SHA1 HMAC
SHA2_256_128 HMAC
SHA2_384_192 HMAC
SHA2_512_256 HMAC
VPP does not support the following integrity algorithms:
MD5_128 HMAC
SHA1_160 HMAC
SHA2_256_96 HMAC
AES XCBC
AES CMAC
AES-GMAC
If you have configured ESP profiles with algorithms not supported by VPP and the traffic for such peers flows trough VPP interfaces, such traffic will be dropped.
Configuration Examples
ACL for VPP IPsec Traffic
When using VPP for offloading IPsec traffic, you may need to adjust your firewall rules to allow the necessary protocols and ports. Below is an example of how to configure ACLs for VPP IPsec traffic:
set vpp acl ip interface <interface-name> input acl-tag 10 tag-name 'IPSEC'
set vpp acl ip tag-name IPSEC description 'Allow IPsec traffic'
set vpp acl ip tag-name IPSEC rule 10 action 'permit'
set vpp acl ip tag-name IPSEC rule 10 destination port '500'
set vpp acl ip tag-name IPSEC rule 10 protocol 'tcp'
set vpp acl ip tag-name IPSEC rule 20 action 'permit'
set vpp acl ip tag-name IPSEC rule 20 destination port '500'
set vpp acl ip tag-name IPSEC rule 20 protocol 'udp'
set vpp acl ip tag-name IPSEC rule 30 action 'permit'
set vpp acl ip tag-name IPSEC rule 30 destination port '4500'
set vpp acl ip tag-name IPSEC rule 30 protocol 'tcp'
set vpp acl ip tag-name IPSEC rule 40 action 'permit'
set vpp acl ip tag-name IPSEC rule 40 destination port '4500'
set vpp acl ip tag-name IPSEC rule 40 protocol 'udp'
set vpp acl ip tag-name IPSEC rule 50 action 'permit'
set vpp acl ip tag-name IPSEC rule 50 protocol 'esp'
Pay attention to the order of the rules, as they are processed sequentially. Make sure to place IPsec-related rules before any other rules that might deny traffic to ensure that IPsec traffic is allowed.
Simple VTI-based IPsec Tunnel
On the VPP host:
set interfaces ethernet eth1 address '192.168.1.1/24'
set interfaces ethernet eth2 address '192.168.100.1/24'
set interfaces vti vti1
set protocols static route 192.168.200.0/24 interface vti1
set vpn ipsec authentication psk psk1 id 'peerA'
set vpn ipsec authentication psk psk1 id 'peerB'
set vpn ipsec authentication psk psk1 secret 'AB'
set vpn ipsec esp-group esp1 mode 'tunnel'
set vpn ipsec esp-group esp1 pfs 'disable'
set vpn ipsec esp-group esp1 proposal 10 encryption 'aes256'
set vpn ipsec esp-group esp1 proposal 10 hash 'sha256'
set vpn ipsec ike-group ike1 close-action 'none'
set vpn ipsec ike-group ike1 dead-peer-detection action 'clear'
set vpn ipsec ike-group ike1 proposal 10 encryption 'aes256'
set vpn ipsec ike-group ike1 proposal 10 hash 'sha256'
set vpn ipsec interface 'eth1'
set vpn ipsec site-to-site peer peerB authentication local-id 'peerA'
set vpn ipsec site-to-site peer peerB authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer peerB authentication remote-id 'peerB'
set vpn ipsec site-to-site peer peerB connection-type 'none'
set vpn ipsec site-to-site peer peerB default-esp-group 'esp1'
set vpn ipsec site-to-site peer peerB ike-group 'ike1'
set vpn ipsec site-to-site peer peerB local-address '192.168.1.1'
set vpn ipsec site-to-site peer peerB remote-address '192.168.1.3'
set vpn ipsec site-to-site peer peerB vti bind 'vti1'
set vpn ipsec site-to-site peer peerB vti traffic-selector remote prefix '192.168.200.0/24'
set vpp settings interface eth1 driver 'dpdk'
set vpp settings interface eth2 driver 'dpdk'
set vpp settings ipsec netlink rx-buffer-size '32000'
set vpp settings lcp ignore-kernel-routes
Where:
eth1
is the interface connected to the IPsec peer.eth2
is the interface connected to the local subnet, where unencrypted traffic is expected.192.168.100.0/24
is the local subnet that will be accessible through the IPsec tunnel.192.168.200.0/24
is the remote subnet that will be accessible through the IPsec tunnel.vti1
is the VTI interface created by VPP for the IPsec tunnel.peerA
andpeerB
are the identifiers for the local side and remote peer, respectively.
Note
What is important in this configuration
VPP uses only remote traffic-selector to determine what traffic should be offloaded to the IPsec tunnel.
Adding additional routes via VTI interface does not affect actual VPP IPsec operation.
Potential Issues and Troubleshooting
Improper IPsec configuration can lead to various issues, including:
Unidirectional traffic flow or acceleration
If kernel has a conflicting route for the remote subnet, such route may take precedence over the policy route created for the IPsec tunnel in VPP. This may lead to unidirectional traffic flow or acceleration only in one direction. This has no security impact because traffic will still be encrypted by the kernel, but it may lead to performance degradation. To avoid this, ensure that no conflicting routes exist in the kernel routing table.
Conflicting with kernel routes
If the kernel routes synchronization option is enabled, VPP will install all the routes from kernel. If you have there routes configured via VTI interfaces to the IPsec peer, they will conflict with the policy routes created for the IPsec tunnel in VPP. Consider using policy-based IPSec configuration to avoid this or disable the kernel routes synchronization.
Unsupported algorithms
If you have configured ESP profiles with algorithms not supported by VPP and the traffic for such peers flows through VPP interfaces, such traffic will be dropped. You can check system logs for messages from VPP with
linux-cp/ipsec: Invalid/Unsupported crypto algo
orlinux-cp/ipsec: Invalid/Unsupported integ algo
line to identify such cases.Connection is established but no traffic flows
Even if you use compatible algorithms, there can be other reasons why traffic is not flowing. One of most frequent is blocking traffic between peers - that is especially common in public clouds. Make sure that TCP/UDP ports 500 and 4500 and ESP protocol are allowed between the peers. Alternatively, consider enforcing UDP encapsulation on both sides of the tunnel: