Comparison of Policy-Based VPNs and Route-Based VPNs
Security Director supports configuring two types of VPNs for SRX Series devices – policy-based and route-based VPNs. The underlying IPsec functionality is essentially the same in terms of traffic being encrypted.
Table 1 summarizes the differences between policy-based VPNs and route-based VPNs.
Table 1: Differences between Policy-Based and Route-Based VPNs
A tunnel is treated as an object that, together with source, destination, application, and action, constitutes a tunnel policy permitting VPN traffic.
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 can 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.
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.
Because the route, not the policy, determines which traffic goes through the tunnel, multiple policies can be supported with a single SA or VPN.
The action must be permit and must include a tunnel.
The regulation of traffic is not coupled to the means of its delivery.
The exchange of dynamic routing information is not supported.
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 a st0 interface that is bound to a VPN tunnel.
If you need more granularity than a route can provide to specify the traffic sent to a tunnel, using a policy-based VPN with security policies is the best choice.
Route-based VPNs use routes to specify the traffic sent to a tunnel; a policy does not specifically reference a 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 you 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. However, the multi-proxy ID is supported for only route-based VPNs. The multi-proxy ID is also known as traffic selector. 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 addresses. 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.