Once you have used Quick Configuration to set up the 3002 or have modified its configuration, you'll want to verify that an IPsec tunnel can be brought up to the configured VPN gateway. The following sections will discuss three possible options you can use to perform authentication: Unit Authentication, Interactive Unit Authentication, and Individual User Authentication. If the 3002 will be connecting to a VPN 3000 concentrator, you also must enable the correct policy on the concentrator. Under the "Building the IPsec Tunnel" subheading, I also will discuss three possible options of performing authentication for use of the IPsec tunnel when Interactive Unit or Individual User Authentication is enabled.
The default authentication method on the 3002 is called Unit Authentication, sometimes referred to as the default method. With the default method, the XAUTH remote access username and password are configured on the 3002 itself; therefore, no users behind the 3002 have to perform any type of authentication to either bring up the IPsec tunnel or to use an existing tunnel.
With the default method, there are three ways of bringing up the IPsec tunnel to the VPN gateway: one brings up the tunnel automatically and two require user intervention to bring up the tunnel. Here are the three connection options (these only apply to client mode connections, because network extension mode automatically brings up the tunnel):
- A user behind the 3002 opens up a web browser connection to the private interface of the 3002, and in the web browser window clicks the Connection/Login Status hyperlink and then clicks the Connect Now button.
- A user behind the 3002 opens up a web browser connection to the private interface of the 3002 and logs in to one of the three accounts: admin, config, or monitor. Only the first one is enabled, by default. To enable the other two, go to Administration > Access Rights > Administrators after logging in to the admin account. For user access, I would enable only the monitor account, because it has read-only privileges on the 3002; mostly, it's restricted to the Monitoring menu structure. Once logged in, the user goes to the Monitoring > System Status screen and clicks the Connect Now button to bring up the tunnel. Of the two manual options, this is the least preferred because you are letting SOHO users log in to the 3002, which might present a security risk.
For testing purposes, as an administrator, you'll probably go to the Monitoring > System Status screen to bring up the tunnel. When no tunnel is up, you'll see the screen shown in Figure 14-15.
Figure 14-15. System Status Screen: No Tunnel
Click the Connect Now button to bring up the IPsec tunnel to the configured Easy VPN Server; this will take a few seconds. Once the tunnel is up, an updated System Status screen will appear, shown in Figure 14-16. The internal address assigned to the 3002 by the Easy VPN Server is 192.168.101.130 and below this is statistical information for the IKE and IPsec SAs. There are two IPsec SAs; however, the second one won't show up here until traffic traverses the connection from the Easy VPN Server to the 3002.
Figure 14-16. System Status Screen: IPsec Tunnel
Additional Authentication Options
The main problem with Unit Authentication is that if the 3002 is ever compromised or stolen (it's fairly small), the remote access username and password are stored in Flash memorythe hacker or thief can then use this to establish an encrypted connection into your network. Cisco has two other solutions with the hardware clients to deal with this problem:
The following two sections discuss these methods.
Interactive Unit Authentication
With Interactive UA, the remote access username and password is not stored on the 3002's Flash memory; instead, one user behind the 3002 must supply this information to bring up the tunnel. This information is used by the 3002 to perform XAUTH during ISAKMP/IKE Phase 1. Once the tunnel is up, every user behind the 3002 can use the tunnel without any further authentication.
There are a few limitations of Interactive UA:
Individual User Authentication
Individual UA solves the issues in the previous bulleted list. With Individual UA, once the tunnel is up, every user that wants to use the tunnel also must authenticate. This authentication is not part of XAUTH but is an additional authentication function. The hardware client passes this information over the ISAKMP/IKE Phase 1 connection and the Easy VPN Server performs the authentication and passes back the results to the hardware client.
Individual UA can be combined with either Unit Authentication or Interactive UA.
The hardware client keeps track of authenticated users based on both their IP and MAC addresses; if these change, the user is forced to re-authenticate. An idle timer is associated with the user: if the user doesn't send traffic across the tunnel during this idle period, at the end of the idle period, the user is cleared from the hardware client's authentication cache and is forced to re-authenticate the next time the user needs access to the IPsec tunnel. This process provides better control over who uses the tunnel.
The next section will discuss how to configure Interactive UA and Individual UA. Following this, I will discuss how users can authenticate to bring up and use the IPsec tunnel. Last, I'll discuss how you can monitor the Interactive UA and Individual UA processes.
Configuring the VPN 3000 Concentrator
One of the interesting things about Interactive and Individual UA is that they are not configured on the 3002 client; instead, this policy is configured on the Easy VPN Server device, such as a concentrator. This policy is then pushed down to the hardware client during IKE Mode Config. Even if the hardware client has the remote access username and password stored in Flash memory, if the policy pushed down to the hardware client is not Unit Authentication, the hardware client erases the XAUTH username and password in its configuration automatically.
If you're configuring Interactive or Individual UA for a hardware client on a VPN 3000 concentrator, this is performed from the HW Client tab under the group configuration (Configuration > User Management > Groups). Figure 14-17 shows an example of this screen.
Figure 14-17. 3000 Concentrator: HW Client Group Tab
At the top of the screen are two check boxesRequire Interactive Hardware Authentication and Require Individual User Authenticationwhich enable Interactive and Individual UA, respectively. If both are checked, then both are used, where one user must authenticate to bring up the tunnel and then every user must authenticate to use the tunnel.
Below this you can change the idle timer for authenticated hardware clients (UA and Interactive UA) and users (Individual UA)it defaults to 30 minutes. Changing the timer to 0 disables the idle timeout, which is not recommended.
Two other optional parameters are Cisco IP Phone Bypass and Leap Bypass. These are necessary when you have Cisco IP Phones or wireless devices using LEAP (Lightweight Extension Authentication Protocol) behind the hardware client, because the IP Phones and LEAP don't understand the authentication process that needs to take place (LEAP is used by wireless devices for authentication).
If you have Cisco IP Phones or wireless clients using LEAP, then you must use either UA or Individual UAInteractive UA is not supported. Plus, you'll need to use network extension mode, which causes the 3002 to automatically bring an IPsec tunnel up once the 3002 boots up.
If you have Cisco IP Phones behind the 3002 that might need to contact the corporate office via the IPsec tunnel before a user can perform the authentication, click the check box labeled Cisco IP Phone Bypass. Likewise, if you have wireless clients that will be using LEAP for authentication, you need to check the Leap Bypass check box: this allows LEAP packets to traverse the IPsec tunnel without being authenticated. However, once LEAP authentication is performed, the user still must authenticate to send normal packets across the tunnel. LEAP bypass will work only if the wireless access point (AP) is a Cisco Aironet AP running the Cisco Discovery Protocol (CDP).
Using either bypass method presents a security risk because unauthenticated packets are allowed to traverse the tunnel.
Building the IPsec Tunnel
Once you have defined your Interactive or Individual UA policy for the group containing the hardware clients, there are three ways authentication can take place:
Figure 14-18. 3002 Monitoring > System Status Interactive UA
Figure 14-19. Connection/Login Status with a Tunnel Up
Because the web browser redirection method works only for web browser connections, if a user attempts to make a connection to the corporate office using another application, this will fail. Therefore, I recommend that you do two things on the user's desktop. First, set the user's web browser default home page to an IP address of a web server at the corporate site; second, put the web browser in the user's startup menus, which will cause the web browser to begin when the desktop boots up, causing the web browser's redirection process and any necessary authentication that needs to be performed.
In the previous bulleted list, I assumed that you were using Interactive UA. The process is very similar if you are using Individual UA. I'll use an example where a user clicks the Connection/Login Status hyperlink on the 3002's login screen. If no tunnel is up (assuming you're using an Interactive UA), one user must provide the XAUTH credentials to bring up the tunnel. From the Connection/Login Status screen, click the Connect Now button and provide the username and password given to you that's associated with the group the 3002 belongs to. If successful, you'll see the screen shown in Figure 14-20. On this screen, the tunnel is up, but you must perform Individual UA to use it.
Figure 14-20. Connection/Login Status with Individual UA Before Logging In
Next, click the Login Now button, reenter your user name and password, and click the Continue button. Once authenticated, you should see a screen like that shown in Figure 14-21, with the message of "You are logged in" followed by your username, IP address, and MAC address, when you logged in, and for how long you were logged in.
Figure 14-21. Connection/Login Status with Individual UA After Logging In
If the tunnel is already up, when you click the Connection/Login Status hyperlink on the main 3002 login screen, you're taken immediately to the screen in Figure 14-20, where you must perform Individual UA. Please note that the process for performing this from the Monitoring > System Status screen and using the web browser redirection method are basically the same.
Verifying the Connection
On the 3002 and VPN 3000 concentrator, there is no difference, from a monitoring perspective, if you are using UA or Interactive UA. The devices treat them as a normal IPsec remote access session using XAUTH for user authentication. However, this is not true of Individual UA. On a 3002, you can see the list of authenticated users by going to Monitoring > User Status, shown in Figure 14-22.
Figure 14-22. Viewing Authenticated Individual UA Users on the 3002
On a VPN 3000 concentrator, go to Monitoring > Sessions and scroll down to the Remote Access Sessions section. Click the name of the user that was used for XAUTH to bring up the tunnel from the 3002. After seeing the session summary and the IKE and IPsec connection details, you will see a section entitled Authenticated Users, listing the users who currently are authenticated via Individual UA who can use the existing tunnel.
Part I: VPNs
Overview of VPNs
PPTP and L2TP
Part II: Concentrators
Concentrator Product Information
Concentrator Remote Access Connections with IPsec
Concentrator Remote Access Connections with PPTP, L2TP, and WebVPN
Concentrator Site-to-Site Connections
Verifying and Troubleshooting Concentrator Connections
Part III: Clients
Cisco VPN Software Client
Windows Software Client
3002 Hardware Client
Part IV: IOS Routers
Router Product Information
Router ISAKMP/IKE Phase 1 Connectivity
Router Site-to-Site Connections
Router Remote Access Connections
Troubleshooting Router Connections
Part V: PIX Firewalls
PIX and ASA Product Information
PIX and ASA Site-to-Site Connections
PIX and ASA Remote Access Connections
Troubleshooting PIX and ASA Connections
Part VI: Case Study