Misc 20

One of the emerging trends in the industry is the rise of mobile workers. Mobile workers, otherwise known as teleworkers are employees who work away from the office. A typical teleworker would require resources in the office, but that would mean that he would have to traverse the internet. Due to this, a form of VPN known as a Remote Access VPN has to be implemented.
Today we'll look at a topology similar to this:


In this scenario, the home user wants to access the subnet containing the RADIUS server from home (imagine there's some other servers there as well). To do this, he would have to establish a VPN Remote Access connection with the VPN Concentrator. This can be done with Cisco's VPN Client.

This article assumes that connectivity between your client and the VPN Concentrator is set up. Now the first thing we want to do is to set up AAA on the VPN Concentrator. The concept is extremely similar to previous articles. In this case, we'll be using the local database:
aaa new-model
aaa authentication login VPNAUTHEN local
aaa authorization network VPNAUTHOR local
user cisco pass 0 cisco

That's really all for AAA. Now we'll begin setting up the cryptographic services. If you recall from the VPN Introduction article, we have to first set up Phase 1 of the connection which is ISAKMP. To do this, enter the following:
crypto isa pol 1
hash sha
auth pre
group 2
life 1800
encr 3des

Recall the HAGLE ("Haggle") sequence (Hash, Authentication, Group, Life, Encryption). This is the part that deters from the Site-to-Site design. In a normal Site-to-Site design, the peers are hardcoded in. However, in a Remote Access design, we do not know who our peers are. We have to go through an extra step in Phase 1. First we designate the traffic that are interesting:
ip access-l ext VPNINTERESTING
permit ip 20.20.20.0 0.0.0.255 40.40.40.0 0.0.0.255
permit ip 30.30.30.0 0.0.0.255 40.40.40.0 0.0.0.255

We create a pool of addresses to assign:
ip local pool VPNPOOL 40.40.40.10 40.40.40.150

And finally we create a client group to consolidate the settings:
crypto isakmp client config group VPNCLIENTGROUP
key cisco
dns 30.30.30.2
domain kelvin.com
pool VPNPOOL
acl VPNINTERESTING

That's it for Phase 1. Now we move on to Phase 2. Recall that I said that we can't hardcode peers here. To get around this, we'll need to use something known as a dynamic map. A dynamic map is a map that is similar to a normal crypto map, except that it does not have a peer-matching statement. We'll first create the transform set we need to use:
crypto ipsec transform TRANSFORM esp-3des esp-md5-hmac

Then we apply it in the dynamic map like this:
crypto dynamic VPNDYNAMIC 10
set transform TRANSFORM
reverse-route

Note that there is a command known "reverse-route". Reverse-route adds a routing entry for each connected Remote Access client. This is required for two way communication. Finally we create the crypto map:
crypto map MAP client authentication list VPNAUTHEN
crypto map MAP isakmp authorization list VPNAUTHOR
crypto map MAP client configuration address respond
crypto map MAP 10 ipsec-isakmp dynamic VPNDYNAMIC

Over here, the AAA lists are specified for authentication and authorization, and the VPNDYNAMIC map is used in the crypto map. This is all the setting we need. We'll now have to apply the map onto the interface. We'll also need to use virtual-reassembly to reassemble fragmented segments:
in s0/0
ip virtual-reassembly
crypto map MAP
in f0/0
ip virtual-reassembly

In most implementations, the packets would be routed through a NAT. IPSec VPN traffic is particularly sensitive to NAT. To go past the NAT, we'll have to have an access-list that looks like this:
ip access-l ext NAT
deny ip 20.20.20.0 0.0.0.255 40.40.40.0 0.0.0.255
deny ip 30.30.30.0 0.0.0.255 40.40.40.0 0.0.0.255
permit ip any any

This prevents any traffic destined for the 40.40.40.0 network (VPN clients) to be NATted. Now we implement NAT:
in s0/0
ip nat inside
in f0/0
ip nat outside
ip nat source list NAT interface s0/0 overload