EzVPN II: Electric Boogaloo

On February 17, 2011, in CCIE, Networking, by Steve

The previous post talked about setting up an EzVPN server and an EzVPN client on a router.  Not the easiest task on hand as the name would suggest.  But the reason for setting up an EzVPN server isn’t so much for other routers; the main reason is for an IPSec Client at a remote location to easily connect to the main network.  In order to do that with certificates, as was demonstrated in the last post, the IPSec Client must be installed and then manually enroll with the CA server.  In production, this would be done while the user is in the office, as the PKI server shouldn’t be exposed to the outside world.

The steps for this are the easiest to do:

  1. Install the Cisco IPSec Client on the laptop.
  2. Enroll with the CA  to download the certificates.
  3. Configure the client to connect to the remote server with the certificate.

This is the “Ez” part of EzVPN.  But if grasshopper isn’t careful about the configuration, all unhappiness will befall upon the network engineer.  First, download the client from Cisco’s website and install it.  This is a simple program to install, so I am not going to go through the grizzly details.  But a word of caution.  If you are doing testing in a lab, use a 32 bit version of XP.  There is a version of the client that will work on 64 bit Vista and Windows 7, but it is not worth trying to troubleshoot any issues with that particular client when doing a lab.  Just use XP and call it good.  64 bit XP will not work at all.

After the client is installed, fire it up.  You will need to get the certificates.  Go to Certificates and choose Enroll

Now enter the fields as shown.  Note the /cgi-bin/pkiclient.exe at the end of the enroll url.  This was not needed on the router, but it is needed on the VPN client.

The next bit is crucial.  The OU MUST have the name of the VPN group that is defined on the router.  Without it, the VPN connection will fail.

Click enroll!

Yay!  Now configure the client to connect to the EzVPN server:

Note that we use the certificate that we just downloaded.  Click on save, and the connection should now be in the main window of the VPN client.

Double click on the connection entry.  You will be prompted for the username and password.  We have a local username and password on the EzVPN server of ccie/ccie.

Note that we have the save password checkbox available.  In the EzVPN server configuration, we used the save-password option in the EzVPN client profile.  Enter the password of ccie, and we get authenticated.  After being authenticated, the little status bar in the lower left will change to “Securing Channel…”, and then the VPN will disappear into the taskbar.  There will be a little icon of a lock next to the clock in XP.  If it is closed, you are authenticated!

Time to verify.  Double click on the lock icon, and that will bring back the main window.  Click on Status, then click on Statistics.

Now we run a ping from a command window in XP to 192.168.1.1.  The results:

Note that we did four pings, and the result was four encrypted and decrypted packets.  The ping went through the tunnel!  But what if we ping the 10.10.30.3 interface on R3?

No increase in the encrypted and decrypted packets.  This is because the split tunnel was defined on the EzVPN router as going to the 192.168 networks.  10.10.30.3 was not defined as interesting, so that traffic goes out the interface unencrypted.  In the real world, this would be used to allow a remote user to use the Internet at home and only sending traffic that needs to go to the corporate network over the tunnel.  This split tunnel can be verified in the route details tab.

Note the routes to the 192.168 networks, but none listed for the 10 network.  If no split tunnel is defined, then the route details would come up as all zeros (0.0.0.0).

Verification is complete, as well as the full EzVPN lab.  Yay!

Good luck!

 

Comments are closed.