There are 2 kinds of VPN IPSEC tunnels : Policy Based which is based on “crypto maps” and implementation them on the physical interfaces and Route Based which is based on virtual interfaces (tunnel interfaces). In this article I will talk them over, show how to implement them, when we may to pick up particular ones, and when we are doomed to one of them.
One of the biggest downsides of Cisco ASA is lack of route based VPNs. Of course we may put a router in front ASA or behind the ASA (then ASA may work as layer 2 device and only filter the traffic), but would be nice to have site to site VPN , SSL Remote Access and fully work OSPF on both sites without deployment another devices like ISR branch office router. Anyway, if we have routers already on the edge we are able to use Policy Based VPN and Route Based VPN as well and this is the relevant advantage of routers over ASA.
Policy Based VPN
Firstly let’s have a look at Policy Based VPN. We operate within physical interfaces only! As usual we have to deploy ISAKMP policies and IKE IPSec policies. In a few steps what we have to do is :
1. Mark interesting traffic with access-list
2. Create ISAKMP policy
3. Create preshared key
4. Create ISAKMP profile ( not necessary if we don’t use keyring like me in this case)
5. Define transform set
6. Create and attach crypto map to the outside interface
If we have static routing (which is the only one acceptable in case of Policy Based VPN) we may use Reverse Route Injection (RRI) mechanism which literally takes remote, protected networks from our access-list (interesting traffic) and put them into routing table of our router with next hop of outside interface (protected by ipsec). Why is this useful? If we run OSPF protocol on both sides and redistribute static routes into OSPF then we obtain routing table with all networks of the second site, even if we don’t have OSPF Area0 between crypto map interfaces (of course we CAN’T have because VPN site to site with crypto maps doesn’t allow multicasts and routing protocols). Don’t confuse RRI rules, we don’t get updates from the second side via OSPF because we don’t have Area0 between interfaces! We get update which based on access-list with “interested traffic” only!
Route Based VPN
Route Based VPN is very similar, the difference is that we don’t have to mark interesting traffic because we have 2 outside interfaces : Tunnel interface (virtual) and physical interface. Tunnel interfaces on both sites are considered for being connected directly (in spite of they are physically not). All routes which we get via OSPF will have “Tunnel0” interface as an outside interface. The remain traffic will be going through the physical interface. Another distinguishing feature is that we have to create ipsec profile and attach its to the tunnel interface. Besides we have to define that our tunnel will be protected by ipsec. To summarize in a few steps it looks like this:
1. Create ISAKMP policy
2. Create preshared key
3. Create ISAKMP profile ( not necessary if we don’t use keyring)
4. Define transform set
5. Create ipsec profile (with isakmp profile included)
6 Create tunnel interface and attach ipsec profile to
In this particular case I used VTI VPN , cause I choose tunnel mode ipsec ipv4, originally is GRE. Difference ? 4 bytes additional overhead with GRE. Key difference regards Policy based is the VPN IPSec tunnel is up all the time and doesn’t have to be triggered by one of the site through the ICMP ping for example.
Each of above solutions is scalable. Route based VPN is scalable better because we don’t have to establish site to site tunnel for each pair of routers, for example if we have 5 sites we need to create 25 tunnels in order to achieve full connectivity. In the case of Routed base VPN like DMVPN we have to create only 5 tunnels in Hub & Spoke topology with using of Next Hop Resolution Protocol. If we want to add another site in the first case we have to create another 5 tunnels and make changes in configuration on each site, in DMVPN we don’t even have to “touch” the Hub (or make slight changes, depends on configuration of ISAKMP key), so we make configuration changes only on added router.