Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Comparing Policy-Based and Route-Based VPNs

It is important to understand the differences between policy-based and route-based VPNs and why one might be preferable to the other.

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

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

Route-Based VPNs

Policy-Based VPNs

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

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

The policy references a destination address.

In a policy-based VPN configuration, a tunnel policy specifically references a VPN tunnel by name.

The number of route-based VPN tunnels that you create is limited by the number of route entries or the number of st0 interfaces that the device supports, whichever number is lower.

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

Route-based VPN tunnel configuration is a good choice when you want to conserve tunnel resources while setting granular restrictions on VPN traffic.

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 security association (SA) with the remote peer. Each SA counts as an individual VPN tunnel.

With a route-based approach to VPNs, the regulation of traffic is not coupled to the means of its delivery. You can configure dozens of policies to regulate traffic flowing through a single VPN tunnel between two sites, and only one IPsec SA is at work. Also, a route-based VPN configuration allows you to create policies referencing a destination reached through a VPN tunnel in which the action is deny.

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

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.

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

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

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

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

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, a policy-based tunnel is the best choice.

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

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

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

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

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 via a secure tunnel interface (st0) , which is bound to a specific VPN tunnel.

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.

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

Route-based VPNs support NAT for st0 interfaces.

Policy-based VPNs cannot be used if NAT is required for tunneled 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.

Policy-based VPNs are only supported on SRX5400, SRX5600, and SRX5800 line. Platform support depends on the Junos OS release in your installation.