Hide Navigation Pane
Show Navigation Pane
Feedback
Download
SHA1
Comparing Policy-Based and Route-Based VPNs
It is important to understand the differences between policy-based and route-based VPNs and why one may be preferable to the other. 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. In a policy-based VPN configuration, a tunnel policy specifically references a VPN tunnel by name. With route-based VPNs, a policy does not specifically reference a VPN tunnel. Instead, the policy references a destination address. When the security device does a route lookup to find the interface through which it must send traffic to reach that address, it finds a route via a secure tunnel (st0) interface, which is bound to a specific VPN tunnel. Thus, with a policy-based VPN tunnel, you can consider a tunnel as an element in the construction of a policy. With a route-based VPN tunnel, you can consider a tunnel as a means for delivering traffic, and the policy as a method for either permitting or denying the delivery of that traffic.
The number of policy-based VPN tunnels that you can create is limited by the number of policies that the device supports. 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. A route-based VPN tunnel configuration is the preferred 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 there is just one IPsec SA 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. This is unlike a policy-based VPN configuration, in which the action must be permit and must include tunnel.
Another advantage that route-based VPNs offer is the exchange of dynamic routing information through VPN tunnels. This is not supported with policy-based VPNs. Also for hub-and-spoke topologies, you must use route-based configuration. In addition, you can define static Network Address Translation (NAT) addresses specifically for st0 interfaces. OSPF, hub-and-spoke, and static NAT configurations are beyond the scope of this document.
When a tunnel does not connect large networks running dynamic routing protocols and when you do not need to conserve tunnels or define various policies to filter traffic through the tunnel, a policy-based tunnel is ideal. Also, because there is no network beyond a dial-up VPN client, policy-based VPN tunnels can be a preferred choice for dial-up VPN configurations. Finally, for interoperability with third-party vendors which do not support the concept of route-based VPNs, policy-based VPNs may be absolutely required especially if the third party requires separate SAs for each remote subnet.
For the purposes of this network configuration example, the focus is on policy-based VPN configuration and troubleshooting. Additional Junos OS specific application notes can be found on Juniper Networks’ Knowledge Base at http://kb.juniper.net. In particular, article KB10182 lists several application notes related to VPN configuration and troubleshooting.
