There are two options for configuring a standard IPsec (site-to-site) VPN tunnel: route-based VPN and policy-based VPN. This article provides an overview of the differences between a route-based VPN and policy-based VPN and the criteria for determining which you should implement, as well as links to application notes that address configuration and troubleshooting.
With policy-based VPN tunnels, a tunnel is treated as an object that together with source, destination, application, and action, comprises 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 (ST) 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 following are reasons why you implement route-based VPN:
Source or destination NAT (NAT-src or NAT-dst) needs to occur as traffic travels through the VPN.
There are overlapping subnets or IP addresses between the two LANs.
Hub-and-spoke VPN topology is used in the network.
Primary and backup VPN are required.
A dynamic routing protocol (for example, OSPF, RIP, or BGP) is running across the VPN.
Multiple subnets or networks at the remote site across the VPN need to be accessed.
The following are reasons why you implement policy-based VPN:
The remote VPN device is a non-Juniper device.
Only one subnet or one network at the remote site across the VPN needs to be accessed.