Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Migrate to Route-Based IPsec VPNs

Read this topic when migrating from policy-based VPNs to route-based VPNs using a shared st0 interface.

This topic describes how to migrate existing policy‑based IPsec VPNs to route‑based VPNs using a shared point‑to‑point st0 interface. It compares policy‑based and route‑based VPNs, explains the role of the shared st0 interface in the migration, and provides essential configuration guidance to support the transition.

Comparison of Policy-Based VPNs and Route-Based VPNs

This table compares policy‑based and route‑based VPNs to help you understand why you should migrate to route‑based VPNs.

Table 1 summarizes the differences between policy-based VPNs and route-based VPNs.

Table 1: Comparison Between Policy-Based VPNs and Route-Based VPNs

Policy-Based VPNs

Route-Based VPNs

In policy-based VPNs, a tunnel is treated as an object that, together with source, destination, application, and action, constitutes a tunnel policy that permits VPN traffic.

In route-based VPNs, a policy does not specifically reference a VPN tunnel.

A tunnel policy specifically references a VPN tunnel by name.

A route determines which traffic is sent through the tunnel based on a destination IP address.

The number of policy-based VPN tunnels that you can create is limited by the number of tunnels that the device supports.

The number of route-based VPN tunnels that you create is limited by the number of st0 interfaces (for point-to-point VPNs) or the number of tunnels that the device supports, whichever is lower.

With a policy-based VPN, although you can create numerous tunnel policies referencing the same VPN tunnel, each tunnel policy pair creates an individual IPsec SA with the remote peer. Each SA counts as an individual VPN tunnel.

Because the route, not the policy, determines which traffic goes through the tunnel, multiple policies can be supported with a single SA or VPN.

In a policy-based VPN, the action must be permit and must include a tunnel.

In a route-based VPN, the regulation of traffic is not coupled to the means of its delivery.

The exchange of dynamic routing information is not supported in policy-based VPNs.

Route-based VPNs support the exchange of dynamic routing information through VPN tunnels. You can enable an instance of a dynamic routing protocol, such as OSPF, on an st0 interface that is bound to a VPN tunnel.

Use a policy‑based VPN when traffic‑selection requirements cannot be defined using routes.

Route-based VPNs uses routes to specify the traffic sent to a tunnel; a policy does not specifically reference a VPN tunnel.

Policy-based VPNs cannot be used for hub-and-spoke topologies.

Route-based configurations are used for hub-and-spoke topologies.

When a tunnel does not connect large networks running dynamic routing protocols and you do not need to conserve tunnels or define various policies to filter traffic through the tunnel, use policy-based VPN tunnel.

With route-based VPNs, a policy does not specifically reference a VPN tunnel.

Policy-based VPN tunnels are required for remote-access (dial-up) VPN configurations.

Route-based VPNs do not support remote-access (dial-up) VPN configurations.

Policy-based VPNs might be required if the third party requires separate SAs for each remote subnet.

Route-based VPNs might not work correctly with some third-party vendors.

Policy-based VPNs cannot be used if NAT is required for tunneled traffic.

Route-based VPNs support NAT for st0 interfaces.

With a policy-based VPN tunnel, you can consider a tunnel as an element in the construction of a policy.

When the security device does a route lookup to find the interface through which it must send traffic to reach an address, it finds a route through a secure tunnel (st0) interface.

With a route-based VPN tunnel, you can consider a tunnel as a means for delivering traffic, and can consider the policy as a method for either permitting or denying the delivery of that traffic.

Proxy ID is supported for both route-based and policy-based VPNs. Route-based tunnels also offer the usage of multiple traffic selectors also known as multi-proxy ID. A traffic selector is an agreement between IKE peers to permit traffic through a tunnel, if the traffic matches a specified pair of local and remote IP address prefix, source port range, destination port range, and protocol. You define a traffic selector within a specific route-based VPN, which can result in multiple Phase 2 IPsec SAs. Only traffic that conforms to a traffic selector is permitted through an SA. The traffic selector is commonly required when remote gateway devices are non-Juniper Networks devices.

Shared Point-to-Point st0 Interface

In this topic, you’ll learn about sharing the point-to-point st0 logical interface between multiple VPN objects.

Junos OS supports sharing of point-to-point st0 logical interface when you run IPsec VPN service using the iked process to provide a migration path from the kmd process. You can configure multiple VPNs objects to share a point-to-point st0 interface if you meet the following prerequisites:

  • You've configured explicit traffic selectors.

  • You've not used wildcard network mask in your configuration.

Read further to understand the benefits and limitations of shared point-to-point st0 interface.

Benefits

  • Eliminates the logical interface (IFL) limit on st0 interface.

  • Negotiates multiple security associations (SAs) for a single IKE gateway when you have multiple subnets.

  • Helps migrating policy-based VPNs to route-based VPNs.

  • Eliminates the manual management of static routes to the tunnel using auto route insertion (ARI) with traffic selectors.

  • Eliminates the need for next hop tunnel binding (NHTB) as shared st0 interface is not just limited to point-to-multipoint mode.

Limitations

IPsec VPNs cannot share point-to-point st0 interface if:

  • Proxy ID is configured.

  • Explicit traffic selectors are not configured.

  • One VPN object has proxy ID configured and the other VPN object has default traffic selector configured.

  • One VPN object has explicit traffic selector configured and the other VPN object has default traffic selector configured.

  • One VPN object has proxy ID configured and the other VPN object has explicit traffic selector configured.

Sample Configuration

You can bind the same st0 interface in multiple IPsec VPN objects. You can configure two different IKE gateways with two different IPsec VPN objects binding to the same st0 interface.

Migrate Policy-Based VPNs to Route-Based VPNs

Read this topic if you plan to migrate your configuration from policy-based VPNs to route-based VPNs using the shared point-to-point st0 interface.

Although the SRX Series Firewalls support policy-based VPNs on firewalls that run the IPsec VPN using the kmd process, there are associated limitations. While the policy can control the traffic entering the VPN tunnel in terms of the protocol and the port number of an application, IKEv1 doesn't support protocol or port negotiation in security association (SA) negotiation. So the firewall cannot perform granular control of traffic with policy-based VPNs. We recommend that you migrate your policy-based VPNs to route-based VPNs.

To migrate from policy-based VPNs to route-based VPNs, perform the following steps:

  • Deactivate the IPsec VPN objects that are running in your Junos OS device using the kmd process.

  • Install the junos-ike package to run IPsec VPN service using the iked process. See install junos-ike package.

  • Configure the prerequisites related to the shared point-to-point st0 interface.

  • Activate the previously deactivated IPsec VPN objects with the shared point-to-point st0 interface.

We recommend that you carry out migration using your migration best practices to minimise the downtime.

Limitations

  • You cannot switch back to the kmd-based IPsec VPN service once you migrate to the iked process with shared point-to-point st0 interface.

  • The policy-based VPNs implicitly enforce the sequence order in which the policies are configured when a policy lookup if performed on the data traffic. But the route-based VPNs do not enforce the sequence order in which VPNs are configured, even with traffic selectors, because the sequence is governed by the metric per traffic selector per VPN configuration.

Sample Configuration

Before the migration, let's consider you've the following configuration for the policy-based IPsec VPN that uses the kmd process. Note that the support for policy-based VPNs is available with IKEv1 only. In this configuration, if the security policy matches the criteria, the device directs the traffic to the VPN tunnel.

After the migration, you'll notice the following configuration. Note that the support for multiple traffic selectors, port, and protocol is not available with IKEv1. You must bind the VPN objects to the same st0 interface for the IPsec VPN service that uses the iked process. You can configure two different IKE gateways with two different IPsec VPN objects binding to the same st0 interface with explicit traffic selectors configuration.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
24.4R1
Support for the shared point-to-point st0 interface with the iked process added in Junos OS Release 24.4R1.
24.4R1
We've introduced support for migrating policy-based VPNs to route-based VPNs using the shared point-to-point st0 interface with the iked process in Junos OS Release 24.4R1.