Policy-Based VPN vs Route Based VPN

When we are planning for VPN solutions, we should have an understanding of 2 VPN solutions (Policy Based and Route Based). 

Policy-based VPNs encrypt a subsection of traffic flowing through an interface as per configured policy in the access list. The policy dictates either some or all of the interesting traffic should traverse via VPN.

A Route-based VPN works on routed tunnel interfaces as the endpoints of the virtual network. All traffic passing through a tunnel interface is placed into the VPN. Rather than relying on an explicit policy to dictate which traffic enters the VPN, static and/or dynamic IP routes are formed to direct the desired traffic through the VPN tunnel interface.

To summarize, let’s see a comparison table with the main differences between Policy-Based and Route-Based VPN solutions.

Policy-based VPN Route-based VPN

Supported on most network devices (Cisco Routers, Cisco ASA, other vendors, etc)

Supported only on Cisco IOS Routers. Very limited interoperability with other vendors

Routing Protocols cannot pass through the VPN tunnel

Routing Protocols can pass through the VPN tunnel

Strong Security natively

Need additional configuration

Complex Configuration

Simplified Configuration

Supports P2P network topology while Hub and Spoke topology is not supported Supports Hub-spoke , P2P and P2MP network topologies
Traffic flowing through the VPN tunnel can’t be NATTed Traffic flowing through the VPN tunnel can be NATTed since it passes through either the tunnel interface or gateway IP address specified as next-hop in routing.
VPN failover group provides redundant VPN tunnels. SD-WAN policy routing with backup gateway configuration provides redundant routes.
Small networks with limited network expansion. Large networks experiencing rapid growth.

Outside to DMZ Cisco FTD RPF Check Drop

As Network Engineers, we use packet tracer on both ASA/FTD systems. There are times where we need to run packet tracer to verify the NAT configuration. If you see errors related to RPF (Reverse Path Forwarding), you can simply try using the public IPs instead of private IP addresses. In the below example, the destination IP has been the NAT assigned public IP.

packet-tracer input outside tcp source_public_ip ssh nat_public_ip ssh

If you are not comfortable with the packet tracer, you can refer the guide