Introduction

Last month's article looked at "clever" addressing schemes. I do hope it was an interesting excursion into wildcard masks and planning ahead with address assignments. The article can be found at  http://www.netcraftsmen.net/welcher/papers/addressing.html.

What Does a VPN Concentrator Do?

The VPN Concentrator is used for Remote Access VPN's. In typical use, a Remote Access VPN allows users to use an encrypted tunnel to securely access a corporate or other network via the Internet.

Different VPN Concentrator (VPNC) models are used for different numbers of users and amounts of throughput. While the VPNC can be used for limited site-to-site VPN's (interconnecting LAN's rather than connecting a single remote computer), a PIX or router may be better suited for that form of connectivity.

Another current use of the VPNC is to encrypt WLAN or wired traffic, especially for certain users (e.g. faculty or administrators on a college campus), where there is concern about the consequences should login/password be captured. Remote Access VPN with WLAN usage is popular in the short term where administrators don't want to have to deal with driver installs and OS support issues, WPA, 802.11i, etc. Note that IPSec also buys robust confidential user / PC authentication, the other area where WLAN WEP is somewhat lacking (see my previous WLAN articles).

The Cisco VPN Concentrator 3000 series provides Remote Access VPN connectivity using either IPSec or SSL for the VPN.  User authentication can be via RADIUS, Kerberos or MS Active Directory, RSA SDI, digital certificates, or the built-in authentication server. It also allows access lists (ACL's) to be applied to remote user sessions.

The VPN Concentrator (VPNC) can be configured and administered via command line interface (CLI) or web interface. It provides useful web pages showing active user sessions and statistics.

The following URL's will get you to the relevant documentation on Cisco's pages.

IPSec Versus SSL

SSL (WebVPN) has become a popular alternative. It provides encrypted web access to web-enabled corporate applications. It has become popular because it can be clientless, with much simpler setup and use and lower administration cost. The drawback is that it only enables use of a more limited set of applications, which may not fit all environments. One security concern with WebVPN is web caching and private information left on a computer used for web access to corporate resources. The Cisco client goes to some lengths to prevent compromise of user information, even on a public shared computer used for WebVPN access.

Designing for the VPN Concentrator

The case for putting the VPNC in parallel with the PIX is that this offloads work from the PIX, if you trust the VPN and your remote users. If you connect the VPNC to a Remote Access DMZ interface on the PIX, you're putting more work on the PIX, but also possibly obtaining benefits from ACL's, NAT, etc.

Yet another approach is to just put the VPNC totally inside the network. Have the PIX allow IKE and IPSec to the VPNC, also doing NAT from the internal VPNC public address to an address out of the Internet public address block for the site. Of course, doing NAT like this imposes more work on the PIX.
Yet another alternative: if  the VPNC is just being used for robust WLAN authentication and encryption, put the VPNC on the internal network and don't expose it to the Internet at all.

One of the designs I've been developing recently has a requirement for VPNC for WLAN use. The natural question was, is there any directionality to the processing flow in the VPNC, similar to some firewalls or other appliances. Do you need to use both the public and private interfaces in the VPNC?

I've got the VPNC set up and working in my lab using only the private (internal) interface. There seems to be little or no packet flow directionality into how the VPNC works. The default filters (ACL's) on the public and private interfaces do differ -- but they're rather lax anyway, so you'll probably want to adjust them in any real VPNC deployment.

The other issue I ran into was routing. I ended up using an address pool to assign the IPSec tunnel endpoint an address from a pool. You can take advantage of the "tunnel default gateway" to specify default gateway for traffic exiting a VPN tunnel, usually to the next hop internal router. But you also have to route traffic back to the addresses assigned to the tunnel endpoints (the PC's). I did this with a static route pointing at the private VPNC interface.

Routing also affects one other aspect. In my lab, I had the VPNC connected to two VLAN's on a switch, trunked to a "router on a stick". (Frugal lab). You set up the VPN Client to talk to one address on the VPNC. If routing causes replies to come out the other VPNC interface, the PC Client doesn't like that. You need the PC IPSec traffic to go in and out one and the same interface of the VPNC or a Security Association won't be formed.

Configuring the VPN Concentrator

I thought about posting screen captures of the VPNC User Interface, as I've done for other Cisco software products. However, the online documentation has a very thorough set of screen captures, so I don't feel the need to do this. (Yeah, I guess I just said "RTFM").

So for space and time reasons, at least for now, we're not going to get into the UI for VPNC in any depth. Let's take the high-level tour. Here's the one screen capture I'm going to allow myself...

The reason I included this is so you can see that the User Interface (UI) is pretty natural. The hierarchy shows to the left, and it matches the CLI menu hierarchy. So if you can navigate one, you can deal with the other. Although I find the CLI a bit clunky, and wish ESC was the exit to the next menu level up. As it is, you have to read what number got assigned to Exit, which slows me down.

The main areas of the UI are Configuration, Administration, and Monitoring, as you can see to the left of the previous figure. The first area is where you set up the box, the second is for upgrades, reboots, polite shutdowns, saving the currently active configuration, PING, etc. And Monitoring is essentially show commands: check out the routing table, look at active sessions, drill down for session details, and look at all sorts of counters.

TIP: your current configuration in ASCII form is the file CONFIG, and under Administration you'll find an option to view a file. This gives you a way to save the configuration offline. You can also export and import an XML version. So if you lose your configuration, that gives you a way to put it back without walking the GUI.

If you click on the plus sign in a box, it expands the header. You can then click on the entries in the left frame to navigate.

Setting up the box can be loosely described as using the Console port to give the box an address and basic information. You can then web in and use the abov e set of screens for more detailed configuration. Overall, configuration consists of walking the tree of forms, filling out things that need to be specified. Note: the special cable is required, the standard IOS router type of cable. does NOT work.

The screen capture is from Configuration --> User Management --> Base Group. You fill in the form to set up how you want the base group to behave. Click on Apply and the settings take effect. Users inherit from groups they're assigned to. Groups inherit from the base group. So you start with specifying the policy for the base group, and then in the other forms for the groups and users you create, you only have to change the things the deviate from the base group settings. That can go pretty quickly!

I'm going to stop describing at this point, and refer you to the manual. Really, I found the UI to be fairly straightforward. That's not to say the box worked instantly the first time I tried it, since I had to get the routing and some of the rest of my plan (design) straight in my mind, not having thought it through up front. (I.e. a very accurate real-world simulation?) But there were relatively few surprises or hard-to-find items. The Live Event Log screen under Monitoring was very useful in seeing why the Client was not connecting. Between that and the log screen on the client side, troubleshooting went fairly simply. Most of the troubleshooting was of the "reply from unexpected source address" or "we're at IKE Phase 1, why no reply" sort of thing. See the IPSec Simplified articles, URL's above. I did use Ethereal to make sure I was getting encrypted traffic when the connection came up (ping to a specific target), but the client counter display also showed packet counts that incremented in tandem with the pings. So the VPNC and Client products get an A if not A+ for giving good info for troubleshooting. After all, being able to get it working is what matters!

Configuring the Cisco VPN Client

That is, you tell it where to go, umm, where to connect to. You give it a user GROUP name and GROUP password, which must match that in VPNC, if you're using groups and passwords. As the connection is set up, you'll be prompted for username and password. These can be authenticated against the VPNC built-in database, or against the plethora of external databases that the product supports.

The other tabs in the above window configure options. When done, click "Save". Then click on Connect to connect. After a connection is set up, click on Disconnect to ... I think you get the idea.

Summary

Lab tip: something I just noticed in trying to shut down my lab VPNC politely. The private interface didn't have link when the device booted. The routing table shows 0.0.0.0 as next hop, but forwarding through that interface doesn't seem to be working. Plugging the Ethernet cable in tightly and rebooting leaves the routing table looking the same, but routing to remote networks working. Tentative conclusion: make sure your VPNC is well-connected at boot time? (I don't have time or inclination to experiment further with this right now.)

I do hope this article was interesting and useful. Ideas, comments, questions are always welcome. Send to the email address below.

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014, CCIP) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, IPSec VPN, wireless LAN and bridging,  network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw <at> netcraftsmen <dot> net.