Официален блог на WebEKM EKM очаквайте сайта онлайн скоро.

Download Free Templates http://bigtheme.net/ free full Wordpress, Joomla, Mgento - premium themes.

Policy Based and Route Based- IPSEC VPN variations (LAB)

ipsecpolicyThere 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

 

 

 

 

policy basedVPN

 

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. 

, , , , , ,

Onlain bookmaker bet365.com - the best bokie

Menu