Information Technology

VPN 3000 FAQ and Troubleshooting

General

Troubleshooting

General

Will the VPN interface work with my normal network connection?

The VPN client is active only when you choose to start it. If the program is not running, then it will not affect your connection.

Do I have to use the Cisco or Netlock client software?

For most operating systems (Windows, Macintosh OS X, or Unix), the Cisco client is the only client supported by Rice.

Netlock is responsible for Netlock client support. Rice does not directly provide customer support for these third-party clients, although we do make all reasonable efforts to ensure that our VPN systems are accessible by these clients.

Is there a charge for the Cisco or Netlock client software?

For Windows, Macintosh OS X, and Unix operating systems, the Cisco client is freely available to end users. See Downloading and installing Cisco VPN client software for more details.

Is there Windows CE or Palm OS support?

No. There is no current expectation to support VPN for Windows CE, Palm OS, or other handheld devices.

Is there Windows 95 or Macintosh 7.5-9.x support?

Windows 95 is not supported at all, and Macintosh operating systems prior to OS X are not supported by Cisco.

A client called Netlock allows Macintosh OS 8 and 9 users to connect to the VPN server. (More information about the Netlock client for Macintosh systems.) Although Rice does not directly provide support for Netlock clients, Rice-specific documentation for how to connect a Netlock client to the Rice VPN system is available. (For more detailed support, Netlock users should contact Netlock directly.)

Is there Windows 2003 Server support?

Cisco does not currently support use of the VPN client on the Windows 2003 Server operating system; therefore, Rice cannot support users who wish to use the VPN client on Windows 2003.

It has been reported that the InstallShield version of the VPN client for Windows platforms will install and run correctly on Windows 2003 Server systems. However, Rice cannot provide assistance for users choosing to run this way. If you encounter problems running the VPN client on Windows 2003 Server systems, you will need to troubleshoot it by yourself.

How long can I stay connected to the VPN server?

The total maximum connection time is 12 hours, but the idle timeout (when the connection is not being used) is 30 minutes.

Note: Many laptops' power saving features will put network cards to sleep sooner than our idle timeouts will. If you want to stay connected even when you aren't actively using your laptop/mobile device, you will probably need to disable the power saving features of the laptop or mobile device. You may also need to disable power-saving features on the network card itself.

Windows-specific:

Using both Network Neighborhood (Windows networking protocol) and your regular Internet connection (TCP/IP networking protocol) with the VPN server

The instructions given in Downloading and installing Cisco VPN client software concentrate on using the VPN server with Internet networking protocols (TCP/IP).

If you never access networked resources through the Windows Network Neighborhood, you do not need to modify the configuration described for you in the installation instructions. (Common resources you might access through the Network Neighborhood would be files stored on Windows servers or printers attached to Windows servers.)

If you do access networked resources through the Windows Network Neighborhood:

  1. First, make sure that your VPN client is already correctly handling the TCP/IP-based communications. If you cannot connect to the VPN server or cannot connect to any off-campus Web pages while it is running, you should resolve those issues before configuring the VPN client for the Network Neighborhood.

  2. After the VPN client is working for that function, reconfigure it to start by default before you log in to your desktop. (This means that you will identify yourself to the world with a Rice-based IP address as soon as you log in.)

    To do this:
    1. If there is more than one profile available, choose the one you use the most. Under the Connection Entries menu (in Advanced Mode), select the "Set as default" option. (If only one profile is available, it will automatically be used.)
    2. Under the Options menu, select Windows Logon Properties.
    3. Place a check mark in the box that says "Enable start before logon".
      • If your default connection type is a dialup connection, you should make sure that your default profile expects to make a dialup connection before attempting either to connect to the VPN server or to log on. Follow the instructions below to make sure you have defined a wired connection profile as a dialup connection profile.
  3. On some Windows operating systems, logging out and attempting to log back in will produce the VPN prompt before the login is made. Other Windows operating systems will need to be rebooted before the change will take effect.

  4. The next time you log in, you should wait for a prompt from the VPN server before continuing with the regular Windows login.

    The Cisco VPN Client splash screen will display, and the Simple Mode form of the interface will appear in the lower left corner of the screen with your default profile selected. If this is the correct profile for your current connection type, click the Connect button; otherwise, select another profile from the drop menu before selecting Connect.

    At this point, dialup users will be prompted for the name and password they use to log in to their ISP. (Ethernet and cable modem users will not receive this prompt.)

    Next, all users should receive a VPN dialogue box prompting for your user name and "Radius" password. It expects your Network ID and Network ID password.

    After providing your Network ID and password to the VPN server, watch the lower left corner of the VPN Simple Mode interface for confirmation that you have successfully connected to the VPN server. At this point, you can proceed with the standard Windows login for the machine.

  5. For wired users only: Depending on your ISP and your configuration, you may or may not correctly receive the WINS IP addresses needed to connect to the Windows Network Neighborhood area of the Rice network. If you have difficulty logging in to the Windows domain after the reconfiguration, you need to tell your machine how to find the campus WINS servers, located at 128.174.5.30 (winsa) and 128.174.36.251 (winsb).

    In older versions of Windows (95, 98, NT, etc.), the networking tabs (including DNS and WINS) are usually found by going to Start -> Programs -> Accessories -> Communications -> Dialup Networking (or Network and Dialup Connections), then selecting the connection you want to examine. Right-click on the connection you use and choose Properties. In the Properties dialogue box, click TCP/IP settings. Both DNS and WINS settings should be visible here.

    In newer versions of Windows (2000, XP, etc.), go to Start -> Programs -> Accessories -> Communications -> Dialup Networking (or Network and Dialup Connections), then select the connection you want to examine. Right-click on the connection you use and choose Properties. In the Properties dialogue box, click the General tab. On the General tab, click TCP/IP, then the Properties button. The TCP/IP Properties dialogue box's Advanced button takes you to the IP settings, DNS, WINS, and other tabs. Click on the WINS server tab.

    In either case, once you've located the WINS server settings, enter 128.174.5.30 and 128.174.36.251 and click OK until you've returned to the Desktop. Then reboot if you are prompted to do so.

    When you log in again, you should be able to correctly connect to the VPN server before logging in to the Windows desktop. If you continue to receive error messages, such as "No domain server is available to validate your login," contact the Help Desk in the Mudd building, room 103, or at helpdesk@rice.edu, or at extension 4357.

Note: If you choose not to use the Network Neighborhood during a session, you can hit Cancel at the Radius password prompt; in that instance, you will not connect to the VPN server before logging into your Windows desktop.

Creating a dialup profile from a standard ethernet profile

The default wired profile assumes that your network connection has been established before the VPN software is launched, and that it is an Ethernet-type (or cable modem-type) network connection. If you frequently dial in to a third-party ISP and need to use the VPN with a third-party dialup connection:

  1. Go to the Advanced Mode view of the VPN client. (The choice is listed under the Options menu. If you only see a choice for Simple Mode, then you're already in Advanced Mode.)
  2. In the Connection Entries tab, right-click on the default wired profile and select Duplicate.
  3. Select this duplicate entry and click the Modify button.
  4. In the window which appears, rename the connection entry to indicate that it's your dialup networking entry. (If you dial in to more than one location, you will need more than one of these profiles.)
  5. Click on the Dialup tab. Place a check mark next to "Connect to Internet via dialup" and select the ISP you wish to use from the drop menu on the right. (In this picture, the user has a choice between Rice Dialup and third-party ISPs.)
  6. Click Save.

Afterward, whenever you use this profile to connect to the VPN server, it will dial your ISP before making the VPN authentication attempt. (This is essential for users who need to use Windows / Network Neighborhood networking via a dialup connection, and who must dial in to their ISP before logging in to the system.)

Using software-based firewalls with the VPN server

In order for the VPN server to work through any software-based firewalls you may have installed on your Windows computer, you will need to tell your firewall that information from the VPN server can be allowed to come in.

Each software firewall system has different controls; to provide an example, we've documented how to configure the free edition of ZoneAlarm, version 3.7. (This is not a product endorsement, just an example.)

To configure the free edition of ZoneAlarm to work with the Rice VPN server:

  1. Open ZoneAlarm.
  2. Select the Firewall option.
  3. On the Main tab, verify that the "Trusted Zone" security setting is set to medium.
  4. On the Zones tab, click Add, then IP Address. Select "IP address" from the list of options.
  5. To add the VPN server to your Trusted zone, enter the IP address which applies to the service you use (128.42.247.200 for users of all other ISPs).
  6. Add a description of this entry. "Rice VPN server" is recommended.
  7. Click OK.

    • Note: If you sometimes use a third-party ISP, repeat steps 4-7 to add the second VPN IP address to your trusted zone as well.

Some firewalls will have a more complex configuration procedure than this. For more information on configuring firewalls to pass data on specific ports, see "Firewall Ports" later on this page.

Problems after installing service packs

Installing some service packs (notably Windows 2000 Service Pack 3 or the Internet Explorer 6 service packs) can overwrite some libraries which the VPN client needs to operate correctly.

If you are having problems after installing a service pack, uninstall the VPN client (under Add/Remove Programs) and then reinstall it. The VPN client should work correctly after reinstallation.

Note: If you have customized your profiles (for example, to use a dialup networking connection or to use the alternative port of 10000 due to NAT or firewall issues), you should back up your profiles before uninstalling. Then, after reinstalling, use the Import button to import your customized profiles again.

On Windows machines, the profiles are stored in the Program Files/Cisco Systems/VPN Client/Profiles folder.

I launch the VPN client, get prompted for a password, and it says I am connected, but my traffic doesn't appear to be going through the VPN software. What is the matter?

Your VPN connection may be confused by the simultaneous existence of several enabled network connections, and disabling the inactive ones may help.

Some machines with multiple Ethernet adapters have difficulty with connecting to the VPN server.

If you have a built-in Ethernet card and insert a wireless card, you may need to temporarily disable the built-in Ethernet adapter for the VPN to work properly with the wireless card. (You can temporarily disable an Ethernet interface in the Networking area of the Control Panel.)

If both network adapters are PCMCIA-based (i.e., located on PC cards you insert into slots on the side of your laptop computer), you may wish to stop the wired Ethernet adapter and then remove it from the system when you want to connect to the wireless network.

In either case, you will need to remove or disable the Ethernet interface before launching the VPN software.

Macintosh-specific:

Upgrading to Panther (Mac OS 10.3) with the VPN 3000 client

Some users have experienced problems running the VPN 3000 client after upgrading a machine from an earlier version of Mac OS X to version 10.3 (also known as Panther). In order to repair your VPN 3000 installation, you should:

  1. Uninstall your VPN 3000 client, saving your profiles to a memorable location on your hard drive.
  2. Reinstall your VPN 3000 client and profiles.
  3. Reboot your system.

After the reinstallation and reboot, your VPN client will work correctly again.

Can I use the native Mac OS X VPN client with the Cisco VPN 3000 server?

Effectively, no. While it's possible to use the native Mac client to make a connection to the VPN 3000 server, the Mac OS X VPN client doesn't currently support extended authentication. This means that you won't be able to use your Net ID and password to authenticate yourself to the VPN 3000 system through the campus Radius servers, which means that you won't be authorized to use the Rice VPN network.

The Cisco client for Macintosh OS X is available for free download for Rice students, staff and faculty, and installation instructions are also provided.

Unix-specific:

Error messages (tainted kernel, unresolved symbols) on Red Hat Linux

Red Hat Linux 9 users have reported certain error messages when using the VPN 3000 client, including the following:

Unresolved symbols:

On boot, when the system runs the depmod command, the system gives error messages about unresolved symbols in the cisco_ipsec kernel module. However, the kernel module does load correctly. We believe this error can be ignored safely.

Tainted kernel:

Because the Cisco software is proprietary, when vpnclient_init is run and the cisco_ipsec kernel module is loaded, there is a warning about how it will taint the kernel. This warning is expected and can be ignored safely.

Example from a user's boot logs:

Sep 12 08:08:42 sycorax vpnclient_init: Warning: loading
/lib/modules/2.4.20-8acpi/CiscoVPN/cisco_ipsec will taint the kernel: 
non-GPL license - Proprietary
Sep 12 08:08:42 sycorax vpnclient_init: See 
http://www.tux.org/lkml/#export-tainted for information about tainted modules
Sep 12 08:08:42 sycorax vpnclient_init: Module cisco_ipsec loaded, with warnings

How can I get more debugging information from the process?

See the Cisco Linux and Solaris client documentation for information on more options available to users of Unix-variety VPN clients.

I made a typo when entering the profile name in the command line, and now I have a duplicate profile that doesn't work.

If Unix system users type an incorrect profile name while trying to make a VPN connection, the VPN software assumes that you're trying to create a new profile with that name. It creates a new profile based on Cisco's defaults, and then tries to use that profile to connect.

Since that newly created Cisco-default profile doesn't contain the Rice VPN server's IP address and connection information, the process will never successfully connect to the Rice VPN server. Remove the incorrectly created profile and try again.

To minimize the chances of this happening, and to simplify launching your VPN connection, you may wish to create an alias that will run the command and its arguments (i.e., the correct name of the profile).

Troubleshooting

"Required VPN subsystem not available" error message

This error message has been reported by both Windows and Macintosh OS X users. It can be caused by several different conditions, including the following:

  • The VPN service's process, running on your computer, has quit unexpectedly.
  • The machine's network connection has been interrupted.
  • Newly installed patches or software have interfered with a file needed by the VPN client software.

Try the following remedies, in the following order:

  • Make sure your network connection is securely attached and active.
    • For wired users, make sure that the cable is securely connected at both ends.
    • For wireless users, make sure that your wireless software reports an active connection with a signal strong enough to maintain connectivity. (Many wireless card providers place status icons in tool-type areas of your desktop for ease of reference.)
  • Reboot your system.
  • If the above do not work: Uninstall the VPN client, reboot, and reinstall the VPN client and your profiles.

In most cases, checking your network connection and rebooting your system will solve the problem. If new software or patch installation is part of the problem, you may need to take the third step of uninstalling and reinstalling your VPN client.

If you've tried all three steps above and continue to receive error messages, contact the Help Desk in the Mudd building, room 103, or at helpdesk@rice.edu, or at extension 4357.

Screen savers, hibernation/sleep mode, and the VPN software

On several operating systems, the Cisco VPN client will have problems when the system engages a screen saver, goes into hibernation, or goes into sleep mode. This is because the VPN client expects to have constant communication with the server. When the system goes into a state of lower activity, some hardware devices can also be put into standby, including wireless and Ethernet cards. If this is done, it interrupts the network connection the VPN client is using to communicate with the server.

On Windows, some network cards are put into standby when a screen saver engages or hibernation starts. The VPN client often becomes unable to communicate with the server even after the screen saver or hibernation is ended and normal network card activity resumes. Stopping and restarting the client will not solve the problem; you will need to reboot the system in order to be able to connect correctly again. You should always log out of the VPN client software and exit it before letting your system go into screen saver or hibernation mode.

This has not been reported as an issue for Unix or Mac OS X users. However, any system that has been configured to shut down its wireless or Ethernet card as a power-saving measure will likely be affected by this behavior.

I'm not getting prompted for my password. Why not?

The most likely problem is that you don't have an appropriate DHCP-assigned IP address.

If you do have an appropriate DHCP-assigned address, there may be networking problems between you and the VPN server.

I've got a third-party internet connection and a VPN account. I've followed all the client installation steps, but I can't seem to connect. Now what?

  1. Can you connect without the VPN to your usual Internet Service Provider (whether it's Rice or a third-party ISP)?
    If you can't connect to your ISP even when you're not trying to use the VPN, the problem is related to the ISP rather than the VPN system specifically. Contact your ISP's technical support department for assistance.

  2. DHCP lease times:
    If you can connect to the VPN, but then are disconnected after a certain amount of time, you may have a DHCP lease which is too short for the amount of time you need to connect. Network users may encounter a DHCP lease-renewal problem that on-campus users will not face. More details are given below.

  3. For cable modem and DSL users only:
    There are several factors that may affect users who connect via cable modem or DSL that dialup users may not experience.

    One common device that many cable modem users have attached to their home network is a cable modem router. Most cable modem routers act as firewalls and Network Address Translation (NAT) devices. Both the firewall rules and the NAT may affect their ability to connect via VPN.

    First, try plugging your computer straight into the cable modem or DSL device, rather than going through the router.

    • If you can connect to the VPN server when you're not going through the router, then you've confirmed that the problem is specifically in getting the VPN to talk through the router. In that case, this area of the FAQ is likely to help you solve your problem.

    • If you cannot connect to the VPN server even when you're not going through the router, then this section of the FAQ will not address your problem and you will need to investigate other possible connection issues in other areas of the FAQ.


    When you select your profile and click Modify, the Cisco client has a check box to enable transparent tunneling in the Transport tab.

    If you've determined (through the above test) that the router is your source of communication problems:

    • The first suggested course of action for these users is to try to connect with the transparent tunneling box checked and UDP as the preferred transport method. (This is the default behavior in the profiles distributed by Rice.)
    • If that doesn't work, try again with the box unchecked.
    • Finally, try with the box checked and the option set to TCP/IP port 10000.
    • If none of these options work, contact the Rice Help Desk.
    • Use this link to determine if NAT transparency affects you.

    Firewall ports
    It is also imperative that the firewall rules allow the VPN traffic to pass. Many of these devices are not configured to pass such traffic by default; you may need to reconfigure them yourself in order to permit the VPN connection. Configuration of the these devices is beyond the scope of this document. However, the ports that are required for VPN traffic are:

    4. Service

    Protocol number

    Source port

    Destination port

    PPTP Control Connection

    6 (TCP)

    1023

    1723

    PPTP Tunnel Encapsulation

    47 (GRE)

    N/A

    N/A

    ISAKMP/IPSEC Key Management

    17 (UDP)

    500

    500

    IPSEC Tunnel Encapsulation

    50 (ESP)

    N/A

    N/A

    IPSEC NAT Transparency

    17 (UDP)

    10000 (default)

    10000 (default)

  4. Once you've connected to your ISP, can you ping 128.42.247.200 or other campus machines?
    If you can ping campus IP addresses through your ISP connection, there is probably an installation or configuration problem with your VPN client software. For further assistance, contact the Help Desk at extension 4357, helpdesk@rice.edu, or in the Mudd building, room 103.

    If you cannot ping campus IP addresses through your ISP connection, there may be a network problem, or there may be a ping block on a location you're trying to access. To check whether the block is to the campus as a whole or restricted to the ping command in specific, try to load a couple of campus web pages in your browser, such as http://www.rice.edu/ or http://www.owlnet.rice.edu/. If those pages come up, click on a random link within the page to make sure you're getting fresh data rather than a cached image. If this link check succeeds, then you're back on your way; if not, continue to the next step.

    If you can neither ping campus IP addresses nor access any campus IP web pages, there is probably a network problem between your network connection and the VPN server. We recommend you try again after a while. If the problem remains, please request assistance from the Help Desk at helpdesk@rice.edu, along with date, time, and details of your problem.

  5. Are you certain the VPN is distributing a different (Rice-based) IP address for you?
    To test this, use the VPN software to connect to the VPN server, then open an SSH terminal window to a location where you have a Unix shell account.

    Note: If you connect to the student/staff cluster and you see a menu with a list of single-letter options, you're running menushell. Select U to get to a shell prompt.

    Once you have a shell prompt, type:
    who | grep yournetid

    (Replace "yournetid" with your own Network ID or the name you logged into the server with.)

    The response should resemble the following:
    yournetid pts/200 Oct 26 11:45 (xxxxxx.vpn.rice.edu)

    If the end of the line does not end with .vpn.rice.edu, you are not receiving a DHCP-assigned IP address from the VPN server. For further assistance, contact the Help Desk in the Mudd building, room 103, helpdesk@rice.edu, or extension 4357.

  6. Are you receiving any specific error messages from your software?
    If so, check the documentation for that software for further assistance. (If the error message is about an incorrect password, check with the Help Desk in the Mudd building, room 103, helpdesk@rice.edu, or extension 4357. about whether you remember your password correctly or should change it.)

  7. If none of the above steps have helped:
    For further assistance, contact the Help Desk in the Mudd building, room 103, helpdesk@rice.edu, or extension 4357.

I can connect, and the VPN works for a while, but then it stops working. What do I do?

There are three common problems that can make the VPN connection stop working:

  1. Your computer goes into screen saver/hibernation/standby mode, or powers down the network card to save energy. This is further explained in the hibernation item above.

  2. Your computer loses its connection to the VPN server briefly. This can happen when the signal strength of a wireless access point fluctuates or when the wired network connection you are using is too busy to permit the VPN client to maintain its connection with the VPN server.

  3. You are having problems renewing your DHCP lease. When a DHCP lease expires and cannot be renewed, you lose the IP address you'd been using, and this confuses the VPN client.

    • If you have control of your DHCP lease time, extend the amount of time a lease lasts. The longer your lease lasts, the longer you can stay connected to the VPN client.

    • If you don't have control of your DHCP lease time, disconnect from the VPN client whenever you're not using it. Renew your lease while you're not connected to the VPN, and then when you connect again, you'll have a new length of time to use the VPN before the new lease expires. (If you don't want to renew your lease using the instructions given, you can also reboot your system.)

About NAT Transparency:

Checking the NAT Transparency box when it isn't needed may prevent the client from working properly. When attempting to connect from a new location, follow this test sequence:

  1. Select the profile you wish to use and click the Modify button, then the Transport tab.

  2. First, try connecting with the default options (transparent tunneling enabled and UDP as the transport method).

  3. If that doesn't work, try turning off transparent tunneling by un-checking the box. Save your modifications to the profile and try connecting again.

  4. If neither option works, then try checking the box and using IPSec over TCP on port 10000.

  5. If none of these solutions have worked, contact the Help Desk in the Mudd building, room 103, helpdesk@rice.edu, or extension 4357.

Here's why you should try troubleshooting NAT in this order:

The NAT Transparency box is needed if a user is behind a NAT device that is doing PAT (Port address translation) rather than a 1 to 1 NAT. This is common when there are a limited number of routable IP addresses available and many unroutable IP addresses are being mapped to one routable IP address. Some ISPs and some cable/DSL routers may use PAT for this purpose.

If you can connect and authenticate to the VPN server, but are not able to pass traffic, more than likely you need the transparent tunneling enabled (either UDP or TCP 10000). If you are not able to authenticate to the VPN server, the transparent tunneling box may not by itself fix the problem.

If the VPN client can specify a port for NAT transparency, there are two ports that the client can try. The VPN server is configured for NAT Transparency on port 80 and port 10000. (Port 80 is the new default for the client and server software; Port 10000 is provided as an alternate port in case you are behind a firewall or other device that may interfere with port 80 traffic.) You can configure either of these ports in your client.

If the VPN client cannot specify a port for NAT Transparency, it will use Port 80. If you are using both NAT behind a device that blocks port 80 traffic and a firewall or other device that blocks the alternate port of 10000, you may not be able to use the VPN server unless you can work without either NAT or the device that is blocking UDP and TCP port 10000.

Acknowledgements

Page content courtesy of CITES, University of Illinois at Urbana-Champaign.

 
 
 

 
  
6100 Main, Houston, Texas 77005-1827
Mailing Address: P.O. Box 1892, Houston, Texas 77251-1892
© Copyright Rice University
Page content reviewed: 9/14/05 by Web Team. Markup: 8/30/07 by Hassan Usmani

Rice University Rice University Information Technology