Routed IPsec (VTI)¶

Route-based IPsec is an alternative method of managing IPsec traffic. It uses if_ipsec(4) from FreeBSD for Virtual Tunnel Interfaces (VTI) and traffic is directed using the operating system routing table. It does not rely on strict kernel security association matching like policy-based (tunnel mode) IPsec.

A routed IPsec tunnel creates an ipsecX interface at the operating system level and this interface has its own IP address. The ipsecX interface must be assigned so it can be used for purposes such as static or dynamic routing, daemon binding, traffic monitoring, and so on.

Once assigned, the IPsec interface also gains an automatic gateway which provides policy routing and gateway group capabilities.

Note

Routed IPsec is not replacing traditional tunnel mode IPsec or transport mode. The mode choice is up to the user when creating an IPsec phase 2 entry. Any mode may be used at the same time, subject to the caveats listed later in this document.

Prerequisites¶

First pick a transit network. This is similar to choosing a tunnel network for a WireGuard, GRE, or OpenVPN instance. Typically this is a /30 network in an unused subnet. This example uses 10.6.106.0/30.

IPsec Configuration¶

Create an IPsec Phase 1 entry as usual
Create a Phase 2 entry under this Phase 1 with the following settings:

Description:

Some useful relevant text (e.g. HQ VTI Tunnel)

Mode:

Routed (VTI)

Local Network Address:

10.6.106.1

Remote Network Address:

10.6.106.2

Proposal:

Set as needed to match the other end.
Click Save
Click Apply Changes

In most cases only a single phase 2 entry is necessary as all traffic for a specific address family can be carried over a single interface. A common use case for a second phase 2 is to setup an IPv6 address if the first is setup for IPv4 (or vice versa).

When using IKEv2 without split connections these addresses will all use the same underlying ipsecX interface. With IKEv1 or with IKEv2 and split connections active then each phase 2 will be a separate ipsecX interface which must be assigned and used independently.

Tip

The default case of IKEv2 without split connections is the best practice. Avoid using the other cases unless required by a third party.

IPsec Interface Assignment¶

Navigate to System > Routing
Set the Default gateway options to a specific gateway or group, as long as they are not left at Automatic (Managing the Default Gateway)

Warning

If the default gateway remains set to Automatic the firewall may end up using the IPsec VTI interface as the default gateway, which is unlikely to be the desired outcome.
Navigate to Interfaces > Assignments
Pick the new ipsecX interface from the Available Network Ports list
Click + Add
Note the new interface name, e.g. OPT1
Navigate to Interfaces > [New Interface Name]
Check Enable
Give the interface a more suitable name using the Description field (e.g. VTI_HQ)
Click Save
Click Apply Changes

The firewall creates a gateway automatically which can be used for static routing, policy routing, and so on.

At this point the interface is available for use like any other interface. It can be used for packet captures, traffic graphs, binding daemons, routing protocols, and so on.

Routing¶

No traffic will attempt to cross the IPsec tunnel until routing is configured except for gateway monitoring probes (if enabled).

Static Routes¶

To setup static routes navigate to System > Routing, Static Routes tab. Add new routes there using the assigned IPsec interface gateway.

Typically there will be one static route per remote destination network, similar to how there would be one phase 2 entry per remote destination network with tunnel mode IPsec.

Dynamic Routes¶

As an alternative to manually managing static routes, assigned IPsec VTI interfaces can be used with the FRR Package for dynamic routing such as BGP and OSPF.

Policy Routes¶

To policy route traffic across a routed IPsec tunnel, use the assigned IPsec interface gateway in firewall rules as usual for policy routing.

Note

This may not work as expected without NAT and/or reply-to, which require special settings. See Routed IPsec Firewall Rules for details.

Routed IPsec Firewall Rules¶

By default routed IPsec traffic appears to the OS on both the per-tunnel ipsecX interface and the enc0 interface. When set this way traffic must be passed on the IPsec tab.

This can be changed, however. The behavior of firewall rules for traffic inside an IPsec tunnel depends on the IPsec Filter Mode option in the Advanced IPsec Settings.

To utilize features such as per-interface rules, NAT, and reply-to with routed IPsec the IPsec Filter Mode option must be set to filter on assigned interfaces. This option is not compatible with tunnel mode so it is only feasible if all tunnels on the firewall are using VTI or transport mode.

Warning

Staying on the default filter mode requires special changes to the rules to work around incompatibilities between the default firewall state policy and the way VTI traffic is handled by the OS. See IPsec VTI Filtering for details.

Caveats¶

Routed IPsec works best when both sides support routed IPsec. It can still work when only one side supports routed IPsec, but most of its benefits are lost.

Rather than managing IPsec Phase 2 entries, routes must be managed instead. Since this can be automated with dynamic routing protocols this is not a large concern.

Firewall rule processing can be confusing as mentioned in Routed IPsec Firewall Rules. Some features such as NAT require special settings to function.