Easy VPN

You are currently browsing articles tagged Easy VPN.

Cisco EasyVPN is a solution that I, for the most part, have totally overlooked when designing VPN solutions.  The overlooking part most likely came from my lack of understanding.  Until recently I hadn’t fully understood what its uses were.  A couple of months ago when I was studying for my ISCW exam I came across a chapter for EasyVPN.  Here are the main points that I came out with.

-EasyVPN can be used to create IPSec VPN tunnels between a ‘headend’ and ‘remote’ location
-The remote site does NOT need to have a statically assigned IP address on its external interface
-The configuration can act in Network extension or Client mode.  Network extension mode presents a full routable network to the tunnel for connectivity back to the headend.  In Client mode (also called NAT mode) all traffic is hidden behind a NAT. 
-Remote node configuration is for the most part handled through a mode configuration type policy push from the headend

In other words, EasyVPN certainly has its place in today’s networks.  Let’s look at a ‘real-world’ example to solidify the point.  Let’s say that you have a client who has remote users spread across the US.  The client has a Cisco VOIP solution in house at their corporate office and they’d like to have all of their remote users have a desk phone and LAN access at their respective locations.  In most scenarios like this I’d recommend Cisco phone-proxy and some sort of software client VPN solution.  However, let’s say in this instance they happen to have a pile of older Cisco 800 series router sitting around and don’t feel like upgrading their ASA license for phone proxy.  Enter EasyVPN.

I like to think of EasyVPN as simply a hardware client VPN solution.  Rather than terminating the VPN locally on a users laptop, why not terminate it on a piece of hardware that can support multiple devices?  EasyVPN also supports split tunneling, which should be a consideration in any VPN solution.  All you have to do is configure a router and send it home with the user and their desk phone.  You’ll need to ensure, of course, that the DHCP scope on the router has the 150 option set so that the phone can find the TFTP server but other than that, it should be very transparent to the user.

Configuration
So let’s talk configuration.  Configuring the headend is almost identical to configuring a standard IPSec client VPN solution.  There are a few differences and we’ll point those out as we move through the configuration.  In this scenario we are using a ASA5500 series firewall for the headend, and a 800 series router as the remote device.  I’m assuming that you have a working production device in operation at both the client and the headend location prior to beginning configuration.

Notes
-Insert your relevant information between <>
-Console prompts are show in green
-Text in blue are variable names I made up, feel free to change them

Headend
Notes: Define the ACLs’ for no nat and for the crypto map.  Assuming we have two networks we want access to, a phone and data network  Nothing new here.
ASA# config t
ASA(config)#
access-list EasyVPN extended permit ip <Phone Network> <Phone Subnet Mask> <EasyVPN Client network> <EasyVPN Client Mask> 
ASA(config)# access-list EasyVPN extended permit ip <Data Network> <Data Subnet Mask> <EasyVPN Client network> <EasyVPN Client Mask>
ASA(config)# access-list nonat extended permit ip <Phone Network> <Phone Subnet Mask> <EasyVPN Client network> <EasyVPN Client Mask>
ASA(config)# access-list nonat extended permit ip <Data Network> <Data Subnet Mask> <EasyVPN Client network> <EasyVPN Client Mask>
Notes: Apply the no nat ACL to nat if you havent done so already
ASA(config)#
nat (inside) 0 access-list nonat
Notes: Create the group policy for the connection.  The group policy is where we define the mode.  Here we specify network extension mode with the ‘nem’ enable command
ASA(config)#
group-policy GP_EasyVPN internal
ASA(config)# group-policy GP_EasyVPN attributes
ASA(config-group-policy)# password-storage enable
ASA(config-group-policy)# split-tunnel-policy tunnelspecified
ASA(config-group-policy)# split-tunnel-network-list value EasyVPN
ASA(config-group-policy)# nem enable
ASA(config-group-policy)# exit
Notes: Create a username to use during authentication
ASA(config)# username ezvpn password ezvpn
Notes: Create the transform set to use during phase 2
ASA(config)#
crypto ipsec transform-set TS_EasyVPN esp-3des esp-sha-hmac
Notes: Create the crypto map and dynamic map then apply it to the outside interface
ASA(config)#
crypto dynamic-map DM_EasyVPN 5 set transform-set TS_EasyVPN
ASA(config)# crypto map CM_EasyVPN 60 ipsec-isakmp dynamic DM_EasyVPN
ASA(config)# crypto map OutsideMap 60 ipsec-isakmp dynamic DM_EasyVPN
ASA(config)# crypto map OutsideMap interface outside
ASA(config)# crypto isakmp enable outside
Notes: Create the iskamp policy to be used during phase 1
ASA(config)# crypto isakmp policy 1
ASA(config-isakmp-policy)# authentication pre-share
ASA(config-isakmp-policy)# encryption 3des
ASA(config-isakmp-policy)# hash md5
ASA(config-isakmp-policy)# group 2
ASA(config-isakmp-policy)# lifetime 86400
ASA(config-isakmp-policy)# exit
Notes: Create the tunnel group and assign its attributes
ASA(config)# tunnel-group TG_EasyVPN type remote-access
ASA(config)# tunnel-group TG_EasyVPN general-attributes
ASA(config-tunnel-general)# default-group-policy GP_EasyVPN
ASA(config-tunnel-general)# tunnel-group TG_EasyVPN ipsec-attributes
ASA(config-tunnel-ipsec)# pre-shared-key <pre-shared key>

Remote
Notes: Change your DHCP scope on the router to include both the 150 option for the phones to boot and a LAN DNS server.  I always list a second external DNS as well. 
Cisco831(config)# ip dhcp pool DHCP
Cisco831(dhcp-config)#
dns-server <LAN DNS Server> <External DNS Server>
Cisco831(dhcp-config)#
domain-name <LAN domain name>
Cisco831(dhcp-config)# option 150 ip <IP of TFTP Server for phones> <Second IP if applicable>
Cisco831(dhcp-config)#
exit
Notes: Configure the EasyVPN Client
Cisco831(config)# crypto ipsec client ezvpn EZVPN_CLIENT
Cisco831(config-crypto-easy VPN)# group TG_EasyVPN key <pre-shared-key>
Cisco831(config-crypto-easy VPN)# mode network-extension
Cisco831(config-crypto-easy VPN)# peer <External Peer Address of ASA>
Cisco831(config-crypto-easy VPN)# username ezvpn password ezvpn
Cisco831(config-crypto-easy VPN)#  xauth userid mode local
Cisco831(config-crypto-easy VPN)# exit
Notes: Add the EasyVPN info to the inside and outside interfaces
Cisco831(config)#
int ethernet0
Cisco831(config-if)# crypto ipsec client ezvpn EZVPN_CLIENT inside
Cisco831(config)# int ethernet1
Cisco831(config-if)# crypto ipsec client ezvpn EZVPN_CLIENT

Summary and hints
That’s all there is to the configuration.  After you have the configuration done it should initiate a connection.   It should be noted that this is technically a double NAT scenario.  Most users already have some type of low end device at their home currently.  We typically configure the routers to obtain a external IP via DHCP so there is a possibility of overlapping subnets if you are using the same RFC1918 addressing as the user already has in their home.   The down side to double NAT is that since the outside interface is hidden behind their router, remote administration is impossible until the tunnel comes up.  I ran into a couple of hang ups the first time I deployed EasyVPN that I’ll leave you with.

-As mentioned, there can be overlapping private subnets.  Try to pick ones that you usually wouldn’t defined on home grade routers for your inside interface on the remote side.

-I haven’t 100% figured this out yet, but for some reason the first time the client connects to the headend the console on the client prompts for a login.  The headend will report a phase 1 status of ‘AM_TM_INIT_XAUTH_V6H’ when its waiting for you to enter authentication on the client.  TAC tells me that this only happens the first time it connects.

-For some reason the default routes gave me some grief.  I tested the device at my house behind my ASA and the default route of ‘0.0.0.0 0.0.0.0 ethernet1’ worked great.  At other locations traffic wouldn’t pass at all when I specified the interface name.  Once I changed the route to point to DHCP ‘0.0.0.0 0.0.0.0 dhcp’ the router could pass traffic.  I’ve run into the interface name problem before, but since I don’t deal with many routers that have DHCP external addresses this is the first time I had to set a default route to ‘dhcp’.

– Since multiple tunnels are terminating on the ASA that need to talk to each other I used the ‘same-security-traffic permit intra-interface’ to ensure traffic could pass between tunnels.  Additionally, make sure that your ACL’s allow the traffic to get from one remote EasyVPN client to the other.  AKA ensure that the split tunnel ACL’s specify your remote networks as well.

Tags: ,

Update plus EzVPN tip

Well, I have to apologize.  I’m certainly not posting as frequently as I used to.  Unfortunately between work and studying for the BSCI things have been a little crazy.  I’m hoping to get some good posts out of my studies, but I don’t want to bore anyone with hello and dead times for OSPF just yet.

At any rate, I had an interesting issue come up when doing a Cisco easy VPN deployment the other day that I thought I’d share.  The headend device was a ASA5510 and the remote was an 831 ISR.  During testing the phase 1 SA was getting stuck in a ‘AM_TM_INIT_XAUTH_V6H’ state which I had never seen before.  A quick google came back empty so I went to check out what the easy VPN client was doing.  The console on the client router was spitting out

‘Pending XAuth Request, Please enter the following command: crypto ipsec client ezvpn xauth’.

So I obliged and entered in the command it suggested which then prompted me for the XAUTH username and password.  After I entered in the credentials the tunnel came up just fine. 

After doing some research it appeared to me that the client was coming up in what Cisco calls ‘interactive mode’ which requires you to enter the credentials each time the router loads.  After verifying that the client was configured for ‘auto mode’ we opened a TAC case.  The TAC engineer came back and told us that the client config looked good, and that it was a issue on the ASA.  He had me add modify my group policy as follows.

group-policy <Easy VPN Group Policy Name> attributes
        password-storage enable

After I added the password storage command we connected once more.  On the first connect it again prompted for the username and password.  Then on every subsequent reboot the tunnel came up automagically. 

Tags: