Authentication and Connection Options

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.

Unit Authentication

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):

• Automatically A user behind the 3002 sends traffic destined beyond the 3002. Even if the traffic is not meant for the corporate site, the 3002 still will bring up the tunnel to determine what the split tunneling policy is.
• Manually With this approach there are two options:

  - 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:

• Interactive Unit Authentication (Interactive UA)
• Individual User Authentication (Individual UA)

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:

• If you use a single username and password, all users behind the 3002 will need this, since there is no guarantee which user will need to bring up the tunnel; you could create separate usernames and passwords for each person to solve this problem, but this might create an administrative burden.
• When a tunnel isn't up, it will take a few seconds for a user to figure this out and perform the authentication to bring it up.
• Once the tunnel is up, any user can use the tunnel; this can present problems in SOHO networks that use wireless LANs that might have rogue devices connected to them; this is also true of Unit Authentication.

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.

Note

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).

Note

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).

Caution

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:

• You enable the monitor account on the 3002 and have the users log in to this account via a web browser and the private interface of the 3002, go to the Monitoring > System Status screen, and click the Connect Now button. The top of the screen shows that Interactive UA is being used. Enter the correct username and password (see Figure 14-18) and click the Continue button. If successful, you should see a screen like that shown previously in Figure 14-16.

  Figure 14-18. 3002 Monitoring > System Status Interactive UA

  
• A user opens a web browser connection to the private interface of the 3002, and clicks the Connection/Login Status hyperlink. If a tunnel is not yet up, then the Connect Now button will be visible; click it and enter the correct username and password that represents the 3002 for XAUTH. If a tunnel is up, you'll see something like that in Figure 14-19 when Interactive UA is enabled.

  Figure 14-19. Connection/Login Status with a Tunnel Up

  
• A user opens a web browser connection and points it to any web server beyond the 3002. This will cause the 3002 to intercept the web connection request and display a web page indicating that a tunnel is not up (possibly) and that the user must authenticate. If you look at the web browser URL in the address text box, it will look something like this: http://192.168.10.1/connstatus.html?url=http://192.168.101.99/. The 192.168.10.1 address is the 3002's private interface. The "http://192.168.101.99" is the URL the user originally tried to access before it was intercepted by the 3002. Click the Connect Now button and supply the correct username and password to be used for XAUTH. Click the Continue button and if XAUTH authentication is successful, you'll see a screen like that shown previously in Figure 14-19. In a few seconds, the web browser will be redirected back to the URL the user originally was trying to access at the corporate site.

Tip

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.