Sunday, June 7, 2015

Quick overview of IPSEC and SSL VPN technologies


Quick overview of IPSEC and SSL VPN technologies
Introduction
This document is regarding the quick look out of two VPN technologies. It covers the difference and strengths of both technologies.
IPSEC:
-      It works on Layer 3 (Network Layer) of OSI Model.
-      Since, it works on Network Layer; it secures all data that travels between two end points without an association to any specific application.
-      Once, it gets connected then the person will be virtually connected to the respective entire network and able to access the entire network
-      It defines how to provide data integrity, authenticity and confidentiality over insecure network
like Internet.
-      It completes its goal through tunneling, Encryption and Authentication.
-      It is complex because the two entities which will communicate via IPSEC have to agree on same security policies which must be  configured on the both end of the devices.
-      A Single IPsec tunnel secures all the communication between the devices regardless of traffic type. It can be TCP, UDP, ICMP etc. or any application like e-mail, client-server, and database.
-      Special purpose software is available for IPsec connections. This can be for PCs, Mobiles, and
PDAs as well as for edge devices like Routers and Firewall.
SSL VPN:
-      It works on Layer 7 (Application Layer) of OSI Model.
-      It is a protocol used for secure web-based communication over the Internet.
-      It uses encryption and authentication to keep communications privatebetween two devices, typically, web server and user machine.
-      Like IPsec, SSL also provides flexibility by providing level of security.
-      Unlike IPSec, SSL helps tosecure one application at a time and eachapplication is supported via web browser.
-      All basic web browser application such as IE or Mozilla supports SSL, by default. But, not all the application supports same so it requires upgrading which is very cost consuming.
-      Above problem can be resolved by purchasing SSL VPN gateway which is deployed at the edge
of the corporate network and serve as a proxy to LAN application such as e-mail, file servers and the other resources.
-      The browser thinks it is directlycommunicating with the application and applicationthinks it is directly communicating with browser.SSL VPN makes it transparent to the either side of the network.


SSL VPN delivers the following three modes of SSL VPNaccess:
•      Clientless—Clientless mode provides secure access to private webresources and will provide accessto web content.This mode is useful for accessing most content that you would expect to access in a web browser, such as Internet access, databases, and online tools that employ a web interface.
•      Thin Client (port-forwarding Java applet)—Thin client mode extends the capability of the cryptographic functions of the webbrowser to enable remote access to TCP-basedapplications such as Post Office Protocol version 3 (POP3), Simple Mail Transfer Protocol (SMTP), Internet Message Accessprotocol (IMAP), Telnet, and Secure Shell (SSH).


•      Tunnel Mode—full tunnel client mode offers extensive application support through its dynamically downloaded Cisco Any Connect VPN Client (next-generation SSL VPN Client) for SSL VPN.Full tunnel client mode delivers a lightweight, centrally configured and easy-to-support SSL VPNtunneling client that provides network layer access to virtually any application.
Strength and Weaknesses:
IPsec‘s key strength lies in its ability to provide a permanent connectionbetween locations. Working at the network layer (layer 3 of the network stack) also makes it application agnostic: Any IP-basedprotocol could be tunneled through it. This makes IPsec an attractive alternative to an expensive leased line or a dedicatedcircuit. It could also serve as a backup link in the event that the primary leased line or dedicated circuitconnectingthe remote site to the central office goes down.
IPsec's application-agnostic designis also its weakness, however.Thoughit provides authentication, authorization and encryption, while basically extending the corporate network to any remote user, it does not have the ability to restrict access to resources at a granular level. Once a tunnel is set up, remote users can typically access any corporate resource as if they were pluggeddirectly into the corporate network. These VPN security concern are exacerbated because having a mobile workforce requires allowing non-managed IT assets like smartphones and home PCs to access corporate resources.These are assets that IT has novisibility into or control over, andthere is no guarantee that these
Devices comply with the level of security that is typically enforced on managed assets.
IPsec is also more involved to maintain. In addition to setting up the appliance to terminate the tunnels, additional configurationand maintenance are requiredto support the remote user population. In situations where corporations use Network Address Translation (NAT), special configuration is required to ensure IPsec plays nicely with the NAT setup.
SSL VPNs, on the other hand, have been designed from the ground up to support remote access. They do not require any special software to be installed. Remote access is provided through a browser-based session using SSL.SSL VPNs also provide an enterprise with the ability to control access at a granular level. Specific authentication and authorization schemes for access to an application can be limited to as particular user population. Built-in logging and auditing capabilities address various compliance requirements. SSL VPNs also have the ability to run host compliance checks on the remote assetsconnecting to the enterprise to validate they are configured withthe appropriate security software and have the latest patches installed.
This does not meanSSL VPNs are the panacea to all of IPsec’s weaknesses. If a remote site requires analways-onlink to the main office, SSL VPN would not be the solution. IPsec, being application agnostic, can support a number of legacy protocols andtraditional client/server applications with minimal effort.This is not the case withSSL VPNs, which have been built aroundWeb-basedapplications. Many SSLVPNs getaround this weakness by installing a Java or ActiveX-based agent on the remote asset. This installation is typically achieved seamlessly after the remote asset has successfully authenticated tothe SSL VPN appliance, though it should be noted that both ActiveX and Java come withtheir own security weaknesses that attackers commonly seek to exploit.
IPSEC or SSL VPN:
Each VPN method has its place in an enterprise. Ideally, as SSL and IPsec VPNs serve different purposes and complement each other, they should both be implemented. IPsec should be leveragedin situations where an always-on connection toremote office locations or partners/vendors is required. In these instances, granular access control limitations and missing host-check capabilities should be augmented with aNetwork Access Control (NAC) system, whichcan ensure only approved remote hosts are allowed to connect to the enterprise. Enterprises shouldleverage SSL VPNs primarily as a remote access method for the mobile workforce where granular access control capabilities, auditing and logging, and security policy enforcement are crucial. But, regardless of your VPNchoice or specific needs, remember that a VPN must notonly be updated, tested and monitored for performance, but also employedas part of a defense-in-depthstrategy that utilizes comprehensive policies and a variety of network security technologies.
Related Information

Tuesday, June 2, 2015

Logging options on the Cisco ASA

Logging options on the Cisco ASA

Introduction
Logging is a critical function of any device in your network, but perhaps even more so on a firewall. Whether you are troubleshooting an issue, following an audit trail or just wanting to know what is going on at any time, being able to view generated logs is highly valuable. This post looks at logging options on the Cisco ASA and discusses some of the things you need to consider.
Tick clock
It’s all very well looking through your logs as individual events but if you want to tie them together, particularly across multiple devices, then you need to ensure that all of your devices have the correct time configured. Nothing says ‘I love you’ more than a time stamp that you can trust. If you use a centralized logging solution, you can filter logs across multiple devices to help determine root cause of issues. You can configure time on the ASA manually by using the following commands:
1
2
3
ASA#clock set 12:23:00 JUN 02 2015
ASA#clock timezone GMT 0 3
ASA#clock summer-time BST recurring last Mon jun 2:00 last Sun Oct 2:00
The above lines configure the time, the time zone relative to UTC and the daylight savings time settings respectively. There is a battery on the motherboard of the ASA that will keep the time should the device lose power or be rebooted. However, locally configured time can drift over…time, so what we really want is to use a trusted external time source that all devices synchronize against and this is where NTP comes in.

1
2
3
4
ASA(config)#ntp authenticate
ASA(config)#ntp authentication-key 1 md5 fred
ASA(config)#ntp trusted-key 1
ASA(config)#ntp server 192.168.1.11 key 1 source inside prefer
Lines 1-2 above dictate that we should be using authentication with NTP for added security and gives a key to use. Line 3 is required to advise the ASA that this key is trusted. Line 4 tells us which server to use, which interface it can be found on and which authentication key to use. It also tells the ASA to prefer this time source over other NTP servers of the same judged accuracy based on what stratum they are in. You should configure at least two NTP servers for redundancy. In the event that all servers are unavailable for an extended period, the ASA can fall back to using the local clock. NTP is a Jekyll and Hyde protocol. It can be as simple to understand as the last section or you can dive deep in to its bowels and be lost forever.
Log destination
Logs can be sent to several destinations but before I list them, it should be noted that logs come from two key sources, system events and network events. System events include things like CPU errors, network events include packets being denied on a certain interface. Both types of messages are dealt with by the logging subsystem and are then potentially filtered prior to being sent to one of the following destinations:
§  Console – logs sent here can be viewed in real time when you are connected to the serial port. As this causes CPU interrupts for each message, you need to be careful when enabling this
§  ASDM – logs can be viewed in the ASDM GUI. From here, you can quickly build filters, colour code the logs by severity and save the log as a local text file to be dealt with later or simply archived
§  Monitor – logs to a Telnet or SSH session. But you don’t still use Telnet for management do you?!?
§  Buffered – this is the internal memory buffer
§  Host – a remote syslog server
§  SNMP – rather than sending logs remotely using the syslog syntax, you can use SNMP to send a trap
§  Mail – send generated logs via SMTP
§  Flow-export-syslog’s – send event messages via Net Flow v9
Log severity levels
Before I show some examples of how to configure different logging, it’s worth looking at the different severity levels available to us. There are eight in total as per Cisco’s definitions below:
Numeric level
Name
Definition
0
Emergencies
 Extremely critical “system unusable” messages
1
Alerts
Messages that require immediate administrator action
2
Critical
A critical condition
3
Errors
An error message (also the level of many access list deny messages)
4
Warnings
A warning message (also the level of many other access list deny messages)
5
Notifications
A normal but significant condition (such as an interface coming online)
6
Informational
An informational message (such as a session being created or torn down)
7
Debugging
A debug message or detailed accounting message
By selecting a lower severity (with a higher number), you are also opting in to everything with a higher severity e.g. level 4 will not only log all warnings but all errors, critical, alert and emergency logs. Be wary of selecting too low a severity level, particularly on the console. You can quickly bring a device to its knees if it’s getting hammered.
Examples
Here are some examples to show how to get things up and running.
1
2
3
4
5
6
7
8
ASA(config)#logging enable
ASA(config)#logging timestamp
ASA(config)#logging buffer-size 128000
ASA(config)#logging buffered warnings
ASA(config)#logging monitor 4
ASA(config)#logging trap informational
ASA(config)#logging host inside 192.168.1.55
ASA(config)#logging device-id hostname
Line 1 enables logging globally. We then enable timestamps on the log messages, without which it’s difficult to tell when an event occurred. Line 3 configures the size of the local buffer memory. Once this fills up, it is overwritten in a circular fashion. Lines 4 and 5 configure the buffered and monitor destinations previously discussed for the same level, the first using the keyword ‘warnings’ and the second using the equivalent numerical value. Both are interchangeable but will show in various command outputs using the keyword regardless (expect in the logs themselves, where the numerical form will display). Lines 6 and 7 are configured together for remote syslog logging. Line 6 enables the logging at the specified level (in this case informational) and line 7 configures the syslog server IP address and the interface it can be found on.
Line 8 allows various other attributes to be included in each log message. In this case, it will include the hostname but can also include the firewall IP address of a particular interface, the context name (where used) or a specific string. The latter could be useful for using regular expressions for refining logs at a more granular level.
Finally, the show logging command will firstly show the different settings for each logging destination and then the current contents of the local log buffer. Below is an example of its output with just the first log entry for brevity (please note the enabled settings below are not by any means ideal for a production environment, you need to consider what is best for yours):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
ASA#show logging
Syslog logging: enabled
 Facility: 20
 Timestamp logging: enabled
 Standby logging: disabled
 Debug-trace logging: disabled
 Console logging: level debugging, 204220845 messages logged
 Monitor logging: level debugging, 204220844 messages logged
 Buffer logging: level debugging, 204220845 messages logged
 Trap logging: level debugging, facility 20, 204220844 messages logged
  Logging to management 172.16.221.101 errors: 27 dropped: 450
  Logging to management 172.16.221.204
 History logging: level debugging, 204220844 messages logged
 Device ID: disabled
 Mail logging: disabled
 ASDM logging: level informational, 161093061 messages logged
Feb 19 2013 21:41:18: %ASA-4-106023: Deny icmp src outside:10.0.0.1 dst inside:172.16.46.252 (type 3, code 1) by access-group "OUT_IN" [0x0, 0x0]
One thing to note about logging to Telnet\SSH sessions using the monitor destination. Whilst you may have this enabled and will be able to see the messages logged count in the above output rising each time, you may find yourself confused as to why, whilst SSH’d on to your ASA, you aren’t seeing the logs on your screen. To view logs for the current session, assuming they are enabled, you need to type this command in whilst connected:

1
ASA#terminal monitor
and the logs will start appearing according to the severity level you have set. In a move that I can only attribute to Cisco allowing a drunken intern to come up with the command to negate the above one, somebody settled on:
1
ASA#terminal no monitor
Thanks drunken intern guy. To finish off this post, I’ll bundle some other commands together with a brief description:

1
2
3
ASA(config)#logging standby
ASA(config)#logging debug-trace
ASA(config)#logging emblem
If you have a pair of firewalls configured in a failover configuration, you can enter the first command to enable logging on the standby unit also. Just be aware of the increase in traffic if logging externally to the ASA. The second line will additionally send debug messages to any configured syslog servers, which is disabled by default. Again, this can cause a severe increase in traffic, especially if you enable lots of debugs. The last command changes messages to a proprietary Cisco format and to be honest, I don’t think its used much at all.
Summary
Hopefully you will have learnt a couple of extra things you can do with logging from this post but you can dive even deeper and I suggest you do to get the most out of this critical function. For example, you can archive buffered logs to the local flash or to a remote FTP server, you can disable certain messages completely or just filter them from certain destinations. You can also change the default severity of individual messages to better suit your environment. It would require a certain amount of initial work but would be easily repeatable across your estate.
A great place to learn more is to use the ASDM console which, despite me being a CLI fiend on the ASA, comes in to its own when configuring and reviewing logs. Also pay special attention to what level of logging you have for each destination. I’ve only covered a couple of key points on how best to do this (e.g. disable console logging) as what works best depends on your environment. If possible though, try to use a centralised Syslog server and use the ASDM logging due to it’s immediate nature and filtering capabilities.
Thanks

Mirza Mukaram Baig

Sunday, December 28, 2014

Policy-Based vs Route-Based VPN


Policy-Based vs Route-Based VPNs: Part 1

By Zeeshan | Sunday, December 28, 2014 at 11:05 p.m. 
This is the first part of a two-part post that will compare and contrast policy-based VPNs and route-based VPNs. Policy-based VPNs encrypt and encapsulate a subset of traffic flowing through an interface according to a defined policy (an access list). The policy may dictate that only some or all of the traffic being evaluated is placed into the VPN. This type of VPN is often referred to as LAN-to-LAN when implemented on Cisco ASAs, and I have covered the ASA implementation before. This article examines the configuration of a policy-based VPN on Cisco IOS.
In contrast to a policy-based VPN, a route-based VPN employs 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. IPsec quick and dirty provides a decent primer if you're not familiar with route-based VPNs on IOS.
The lab topology employed in this article is easily replicated using Dynamips or the community lab, and I encourage readers to play along in a lab of their own while reading. If you do, be sure to bookmark this VPN troubleshooting guide from Cisco before you begin. It can be a real time-saver should you run into a wall.

Topology

topology.png
Our goal is to form two VPNs across the "public" network represented by the 172.16.0.0/15 space. (And before anyone brings up my New Year's pledge, I am planning to replicate both VPNs configurations using IPv6 in the future. I just wanted to keep the IP architecture as simple as possible for now since we're already dealing with two fairly complex topics.)
The first part of this article covers setting up a policy-based VPN between R1 and R3. The second part will cover the configuration of a route-based VPN tunnel between R1 and R5, and discuss some pros and cons to both approaches.

Step 1: Define an access list to match interesting traffic

This is the policy part of policy-based VPNs. We need to define an access list to match all the traffic we want to send through the VPN between the two routers. Every line in the access list will result in a bidirectional pair of IPsec security associations (SAs) between the VPN endpoints, so it's beneficial to be as succinct as possible when creating a policy.
For our purposes, we only need to match traffic between the two LANs attached to R1 and R3. Specifically, we need to match traffic from 10.0.1.0/24 to 10.0.3.0/24 on R1, and from 10.0.3.0/24 to 10.0.1.0/24 on R3. This results in two ACLs which mirror each other, one on either router.

R1

ip access-list extended R1_to_R3
 permit ip 10.0.1.0 0.0.0.255 10.0.3.0 0.0.0.255

R3

ip access-list extended R3_to_R1
 permit ip 10.0.3.0 0.0.0.255 10.0.1.0 0.0.0.255
Note that these ACLs must mirror each other exactly in order for the IPsec SAs to form correctly. This is easy when we only have one permit statement, but can become burdensome when dealing with numerous policy entries.

Step 2: Create a pre-shared key

To keep things simple, we'll configure the routers to authenticate one another (via ISAKMP) using a pre-shared key. In the real world, public key authentication provides much better security.
We'll create a keyring to hold our pre-shared keys, which are mapped by peer (public) IP address. R1 maps the key string MySecretKey to R3, and vice versa.

R1

crypto keyring VPN 
  pre-shared-key address 172.16.0.3 key MySecretKey

R3

crypto keyring VPN 
  pre-shared-key address 172.16.0.1 key MySecretKey

Step 3: Create an ISAKMP policy

Next we'll create an ISAKMP policy. This sets the parameters which will be used by the routers during IKE phase one, when the initial asymmetrically-encrypted ISAKMP SA is negotiated. The policy below employs 256-bit AES using pre-shared key authentication (from step two) and Diffie-Hellman group five.
This policy is applied identically to both routers.

R1 and R3:

crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 5

Step 4: Create an ISAKMP profile

An ISAKMP profile is used to establish parameters for a particular ISAKMP peer by matching its outside IP address. We specify the keyring to be used for this peer so that the router knows how to locate the correct pre-shared key.

R1

crypto isakmp profile R1_to_R3
   keyring VPN
   match identity address 172.16.0.3 255.255.255.255

R3

crypto isakmp profile R3_to_R1
   keyring VPN
   match identity address 172.16.0.1 255.255.255.255

Step 5: Define an IPsec transform-set

Now that ISAKMP is out of the way, we move on to IPsec configuration, which is much less involved: We simply need to define an IPsec transform-set. A transform-set tells the router what protocol, encryption, and hashing algorithms to use when forming the IPsec SAs, as well as in which mode to operate (tunnel or transport) and a few other details. The line below defines a transform-set employing ESP with 256-bit AES and SHA-1 hashing (similar to our ISAKMP policy) in tunnel mode. Create the same transform-set on both routers.

R1 and R3

crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac

Step 6: Create and apply the crypto map

Finally, we tie together all of these pieces by creating a crypto map, which does a few things. In order of the config snippets presented below, these are:
  • Matches "interesting" traffic based on the access list we created in step one
  • Sets the remote peer to the outside IP address of the remote router
  • Sets the transform-set we defined in step five
  • Sets the ISAKMP profile we defined in step four
  • Enables static reverse-route injection, which creates static routes for the remote networks specified by the matched access list
  • Sets the administrative distance of the injected static routes to ten (optional)
After creating the crypto map, apply it to the appropriate interface on each router.

R1

crypto map Policy_VPN 10 ipsec-isakmp
 match address R1_to_R3
 set peer 172.16.0.3
 set transform-set ESP-AES256-SHA1
 set isakmp-profile R1_to_R3
 reverse-route static
 set reverse-route distance 10
!
interface FastEthernet0/0
 crypto map Policy_VPN

R3

crypto map Policy_VPN 10 ipsec-isakmp
 match address R3_to_R1
 set peer 172.16.0.1
 set transform-set ESP-AES256-SHA1
 set isakmp-profile R3_to_R1
 reverse-route static
 set reverse-route distance 10
!
interface FastEthernet0/0
 crypto map Policy_VPN
Our policy VPN configuration is complete! We can verify that the crypto map has injected a static route on R1 for the 10.0.3.0/24 network on R3. (Note that the static parameter of the reverse-route command causes the route to be injected even when the VPN tunnel is not established.)
R1# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.17.0.0/24 is subnetted, 1 subnets
C       172.17.0.0 is directly connected, FastEthernet0/1
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.0.0 is directly connected, FastEthernet0/0
     10.0.0.0/24 is subnetted, 2 subnets
S       10.0.3.0 [10/0] via 172.16.0.3
C       10.0.1.0 is directly connected, Loopback1

Testing

Policy VPNs by nature are created on-demand when traffic which matches the associated policy (access list) is detected egressing an interface to which the crypto map is applied. Currently, there are no existing ISAKMP SAs:
R1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status

IPv6 Crypto ISAKMP SA
We can generate some traffic to trigger the creation of the VPN by performing a simple ping whose source anddestination addresses are matched by the VPN policy:
R1# ping 10.0.3.1 source 10.0.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.3.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/3/4 ms
Notice that the first packet was dropped while the VPN was established. The next four pings succeeded, and we can verify that an ISAKMP SA was established. We can also verify the creation of IPsec SAs with the commandshow crypto ipsec sa.
R1# show crypto isakmp sa        
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
172.16.0.3      172.16.0.1      QM_IDLE           4003 ACTIVE

IPv6 Crypto ISAKMP SA
Successive pings will all succeed so long as the VPN tunnel doesn't time-out.
R1# ping 10.0.3.1 source 10.0.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.3.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
That about wraps it up for simple policy-based VPNs. In part two, we'll look at the configuration of a comparable route-based VPN and examine the pros and cons of each approach.

Policy-Based vs Route-Based VPNs: Part 2

By Zeeshan | Sunday, December 28, 2014 at 11:05 p.m. 
This article is a continuation of our discussion regarding policy-based versus route-based VPNs. Make sure to read through part one before continuing if you haven't already. In this second part, we'll look at configuring a route-based VPN on IOS and then examine some important differences between the two approaches.

Step 1: Create a pre-shared key

Route-based VPNs don't rely on an explicit policy (access list) to match traffic, so we can skip that step and start by creating a pre-shared key. On R1, we can re-use the keyring we defined in part one and simply add a new key for R5. On R5, create a new keyring and key for R1. (Use the same key on both routers.)

R1

crypto keyring VPN 
  pre-shared-key address 172.16.0.3 key MySecretKey
  pre-shared-key address 172.17.0.5 key AnotherSecretKey

R5

crypto keyring VPN
  pre-shared-key address 172.17.0.1 key AnotherSecretKey

Step 2: Create an ISAKMP policy

We can also re-use the ISAKMP policy we created on R1 in part one; just remember to apply it to R5.

R1 and R5

crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 5

Step 3: Create an ISAKMP profile

This step should also look familiar. Create a new ISAKMP profile on both R1 and R5 to match the peer IP address to the pre-shared key keyring. (R1 will now have two ISAKMP profiles, R1_to_R3 and R1_to_R5.)

R1

crypto isakmp profile R1_to_R5
   keyring VPN
   match identity address 172.17.0.5 255.255.255.255 

R5

crypto isakmp profile R5_to_R1
   keyring VPN
   match identity address 172.17.0.1 255.255.255.255 

Step 4: Define an IPsec transform-set

We can also re-use the IPsec transform-set defined on R1. Be sure to define it on R5 as well.

R1 and R5

crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac

Step 5: Create an IPsec profile

At this point we start doing things a bit differently. We need to create an IPsec profile, which serves as a wrapper around one or more transform-sets and other parameters to be used in the construction of IPsec SAs. (For our purposes, we only need to reference a single transform-set, so it probably appears redundant.) Create the IPsec profile on both R1 and R5.

R1 and R5

crypto ipsec profile Routed_VPN
 set transform-set ESP-AES256-SHA1 

Step 6: Create a VPN tunnel interface

Now we get into the meat of the VPN configuration. We need to create a routed tunnel interface on both routers to act as the logical VPN edge. Tunnel interfaces serve to encapsulate/encrypt egressing traffic and decapsulate/decrypt ingressing traffic. (Here's a way to visualize this concept if it's a bit fuzzy.)
We'll use the 192.168.0.0/30 network for our VPN tunnel. The tunnel source and destination addresses are defined as the local and remote outside router IP addresses, respectively. The last two lines of the configs below apply IPsec to the tunnel interface using the IPsec profile we defined in the previous step.

R1

interface Tunnel0
 ip address 192.168.0.1 255.255.255.252
 tunnel source 172.17.0.1
 tunnel destination 172.17.0.5
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile Routed_VPN

R5

interface Tunnel0
 ip address 192.168.0.2 255.255.255.252
 tunnel source 172.17.0.5
 tunnel destination 172.17.0.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile Routed_VPN
Notice that, unlike our policy VPN configuration, the peer LAN (10.0.5.0/24) is not automatically injected by the VPN because there is no policy to tell the router what exists on the other side of the tunnel:
R1# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.17.0.0/24 is subnetted, 1 subnets
C       172.17.0.0 is directly connected, FastEthernet0/1
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.0.0 is directly connected, FastEthernet0/0
     10.0.0.0/24 is subnetted, 2 subnets
S       10.0.3.0 [10/0] via 172.16.0.3
C       10.0.1.0 is directly connected, Loopback1
     192.168.0.0/30 is subnetted, 1 subnets
C       192.168.0.0 is directly connected, Tunnel0
Also unlike policy-based VPNs, the SAs for a route-based VPN are constructed automatically and maintained indefinitely whether or not traffic is passing across the VPN.
R1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
172.17.0.5      172.17.0.1      QM_IDLE           4004 ACTIVE
172.16.0.3      172.16.0.1      QM_IDLE           4003 ACTIVE

Step 7: Enable dynamic routing

As just mentioned, route-based VPNs have no mechanism to automatically discover the remote networks which are reachable over the VPN. So how do we communicate this information among peers? With a routing protocol, of course! Just about any routing protocol will do; we'll use single-area OSPF for this lab.
OSPF must be enabled for both the internal LAN interface (which in this case is actually just a loopback pretending to be a /24 network) and the tunnel interface. An OSPF adjacency should form between R1 and R5 over the 192.168.0.0/30 network, inside the VPN. There is no need to enable OSPF on the outside network (172.17.0.0/16), which we're pretending is publicly routed space outside of the VPN (e.g. the Internet).

R1 and R5

router ospf 1
!
interface Loopback1
 ip ospf 1 area 0
!
interface Tunnel0
 ip ospf 1 area 0

Testing

R1 and R5 should learn of each other's LAN prefixes via OSPF, and both networks should be immediately reachable via through the VPN tunnel:
R1# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.17.0.0/24 is subnetted, 1 subnets
C       172.17.0.0 is directly connected, FastEthernet0/1
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.0.0 is directly connected, FastEthernet0/0
     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
S       10.0.3.0/24 [10/0] via 172.16.0.3
C       10.0.1.0/24 is directly connected, Loopback1
O       10.0.5.1/32 [110/1001] via 192.168.0.2, 00:01:29, Tunnel0
     192.168.0.0/30 is subnetted, 1 subnets
C       192.168.0.0 is directly connected, Tunnel0
R1# ping 10.0.5.1 source 10.0.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.5.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

Pros and Cons

If you've been paying close attention throughout these last two articles, you'll have noticed a number of subtle but important differences between policy-based and route-based VPNs.

Policy-based VPNs require administrative policy maintenance

This is probably the biggest drawback of using policy-based VPNs as configured in part one. If we wanted to add a second internal network to R3, for example, we would have to manually update the policy ACL on both R1 and R3 to match traffic for the new network. This isn't a big deal if you're only ever going to manage a handful of networks, but the burden can quickly grow tiring when managing several dozen VPN sites.

Policy-based VPNs result in excessive IPsec SA creation

On the heels of the first observation, we realize that every ACL entry in a VPN policy results in a distinct pair of IPsec SAs (which we can examine in detail with the command show crypto ipsec sa). This isn't a problem if you can efficiently summarize routes, but results in substantial overhead if you have to define a number of distinct routes at either end of the VPN.

Some devices only support policy-based VPNs

I'm looking at you, ASAs. Some devices simply don't support tunnel interfaces or route-based VPNs, making the choice to adopt policy-based VPNs rather easy.

Route-based VPNs require a routed subnet

While route-based VPNs require only a single pair of IPsec SAs, they accomplish this because the VPN tunnel is constructed as an independently routed link (192.168.0.0/30 in our example). Rather than having to match all possible source and destination addresses in the private networks, a pair of IPSec SAs is built only to match traffic between the tunnel source and destination outside IPs. The trade-off, of course, is that we need to assign additional IP address space to the tunnel links.

Route-based VPNs are always on

The SAs for a route-based VPN are always maintained, so long as the corresponding tunnel interface is up. This is in contrast to a policy-based VPN, which forms SAs in response to detecting traffic which matches the policy (and will eventually tear down the SAs in the absence of such traffic). This can be seen as a benefit of policy-based VPNs if your VPN experiences infrequent traffic load, but personally I prefer to have my crypto tunnels up all the time to avoid IKE negotiation delay.

Route-based VPNs require a routing protocol

We saw in part one that reverse route injection can be used in a policy-based VPN to automatically inject static routes for destinations reachable via the VPN tunnel. Route-based VPNs require the introduction of a separate dynamic routing protocol (or static routes) to distribute VPN routing information among peers.
Overall, I think it's fair to say that route-based VPNs offer a much more robust and versatile VPN solution than the policy-based VPN configuration we examined in part one. (And that's not even taking into consideration more scalable route-based VPN solutions like DMVPN.) But I'm curious to hear what readers prefer: policy-based or route-based? Leave a comment and let everyone know!