Scenario 2: Can Authenticate but Problems Passing Data
| In this scenario, the user can authenticate on the concentrator, but cannot pass data. The ability to pass data consists of downloading e-mail, browsing the company's internal web sites, and accessing the internal domain. Different things might be wrong based on the characteristics, and each possible issue is covered in the following cases. These cases introduce the following issues:
Case 1: Cannot Pass Traffic and Using NAT Connection EntryIf you are using NAT on your LAN, you must use a specific connection entry on the VPN client. The concentrator must be aware that you are using NAT, because that might be the main reason for the not passing data issue. The Internet Assigned Numbers Authority (IANA) RFC 1918 reserved the following three blocks of IP address space for private networks (see www.ietf.org/rfc/rfc1918.txt?number=1918 for more information):
To identify if you are using NAT, check your IP address. Refer to Table 22-2 to determine the IP address that your computer is using. If your address is in any of the three ranges listed above, you are NATing and you must use the NAT connection entry. The NAT connection entry, or profile, does not point you to a different concentrator from the standard connection entry. The main difference between the two profiles is the group that you are assigned by the concentrator. If you review the two profiles, NAT and standard, you will notice that each has a different group name and password (the password is encrypted). The concentrator has a group set up to allow IPSec clients to operate through a firewall, using NAT through UDP. The easiest way to create groups is to create a base group. After you have the base group that works with your current network, you can add groups and have them inherit the settings from the base group. Both the standard and NAT groups have the same properties except for the group name, password, and the IPSec over User Datagram Protocol (UDP)box must be checked on the NAT group. It is located under Mode Config. After you have created both groups on the concentrator, users can use the new groups after they have their .pcf files modified. See Chapter 20, "Remote Access VPN Design and Configuration Solutions," for more information about creating groups on the concentrator. Case 2: MTU Causing Packet LossIn Scenario 1, Case 1, it was explained how the default MTU size (1500) can cause authentication failures. The method to test MTU size was also explained and although this information was covered in detail already, this case advises you that different types of problems are associated to the MTU setting. The MTU is the largest number of bytes that a frame can carry, not counting the frame's header and trailer. A frame is a single unit of transportation on the data link layer. It consists of header data, plus data passed down from the network layer, and possibly trailer data. An Ethernet frame has an MTU of 1500 bytes, but the actual size of the basic Ethernet frame can be up to 1524 bytes (20-byte header, 4-byte CRC trailer). If you can connect with the Cisco VPN client but cannot send or receive data, it is likely an MTU problem. Common failure indicators include the following:
If you are experiencing any of these issues, you must lower your MTU. To determine what size to set your MTU and where to set it, see Scenario 1, Case 1. Case 3: Connection Keeps DroppingThere are a couple of reasons why a VPN connection might be dropping. It can be a problem with the ISP, or ports can be closing on a firewall that you are going through. It is unlikely that the concentrator is dropping your connection, but it is not impossible. In this case, you are shown how to use some tools to help maintain your VPN tunnel, and ways to pinpoint where the problem exists. The following sections cover these issues:
Bad ISP ConnectionThe first thing to determine is the quality of your ISP connection by using the ping or tracert commands. Set up a continuous ping to your corporate firewall or concentrator (if it is in front of the firewall). This identifies if there is any heavy latency or packet loss along the way, and both of these issues can cause a tunnel to drop. For certain technologies, such as satellite, you have to expect some degree of latency. Satellite services can result in up to 1500-3000 ms round-trip time (RTT), depending on the packet size. That much latency does not disrupt browsing capabilities to the external web, but it does severely impair the speed of a VPN connection. Some VPN over satellite users have compared it to speeds of analog dialup connections. To set up a continuous ping to your corporate firewall, use the ping command from Example 22-5. Example 22-5. Continuous pingto the Corporate Firewall to Determine if There Is Packet LossC:\>ping -t w 4000 firewall.company.com ! The w sets the ping to 4000 ms before timing out Pinging firewall.company.com [65.1.1.2] with 32 bytes of data: Reply from 65.1.1.2: bytes=32 time=240ms TTL=249 ! 4000 ms or more may cause a problem Reply from 65.1.1.2: bytes=32 time=240ms TTL=249 Reply from 65.1.1.2: bytes=32 time=245ms TTL=249 Request timed out. ! Packet loss Reply from 65.1.1.2: bytes=32 time=242ms TTL=249 Request timed out. <Output Omitted> If you see any dropped packets, try tracing to the firewall a couple of times. By trace routing to the firewall, you can see exactly where the packets are getting dropped, or where the latency occurs. If you are losing packets and cannot route to your corporate firewall, you must contact your ISP. Provide them information, including how many packets are dropped and the host name of the router that you are experiencing latency connecting to or dropping packets on. Sending KeepalivesIf you run the ping and traceroute tests and find that your ISP connection is stable, try turning on ForceKeepAlive for that profile. There is a feature in each connection entry profile called ForceKeepAlive, which basically sends out Internet Key Exchange (IKE) and Encapsulating Security Payload (ESP) keepalives for a connection at approximately 20-second intervals. It helps prevent the NAT device or firewall from dropping your connection. Try turning ForceKeepAlive on and see if it helps. To turn ForceKeepAlive on, open the .pcf file with any text editor for the profile that you typically use. The profiles are located under C:\Program Files\Cisco Systems\VPN Client\Profiles. After it is open, set ForceKeepAlive = 1, which turns it on. It should dramatically reduce the number of dropped connections if it is associated with your firewall or NAT device. The ForceKeepAlive is covered in more detail in Scenario 5, Case 1. Case 4: Cannot Browse the Internal DomainIn this case, the user can connect to the concentrator and even pass data such as e-mail, and browse internal web sites. However, the one thing that does not work is accessing the internal NT domain (Network Neighborhood or My Network Places), where the user has zero to limited access to the domain. This issue can be frustrating initially because it appears everything except domain access is working. You can take two steps to solve this problem: adding the WINS addresses or further lowering the MTU. Adding WINS IPWINS is a NetBIOS name service defined in RFC 1001 and RFC 1002. WINS servers basically maintain a database of computer names to IP addresses. When WINS is configured, a computer first tries to use a WINS server for name registration and resolution. If that fails, the computer then resorts to subnet broadcasts. Unlike LMHOSTS, WINS is useful in a DHCP network where IP addresses are constantly changing because each client, during boot up, registers its name and IP address with the WINS server. In general, this step is not necessary because when the concentrator performs the configuration mode, it pushes a packet of IP addresses to the client, including WINS IPs. However, because of computer-related issues or version-related bugs, you might consider the following steps. Assign statically the corporate WINS addresses to your TCP/IP settings. The WINS addresses help guide your computer to and through the domain by giving it access to a database of computer locations. This eliminates a lot of the problems with finding the domain controller and other Microsoft issues that you might encounter. To add WINS addresses to your TCP/IP, use the following instructions. For Windows 95/98,
NOTE On Windows 95/98 workstations, the workgroup name of the workstation must be the same as the domain name that you are trying to log into, or you will not see a browse list. For Windows NT/2000,
Still Cannot Browse CorrectlyIf you are still having problems browsing the intranet and the domain, you might need to modify some networking settings. In this section, you learn how to fine-tune your network settings to work best with VPN:
Windows 95/98A majority of the time, this problem occurs with users who are dialing to an ISP, and connecting with VPN. Most dialup-only users cannot change the browser characteristics because they do not have the file and printer sharing for Microsoft Networks service configured in the Network Control Panel. To install file and printer sharing for Microsoft Networks service, go to Network in the Control Panel, click Install, and select Service. Then, choose Microsoft as the vendor along with file and printer sharing, and click Add. These settings must be configured and they are different from the File and Print Sharing buttons in the Control Panel. After the settings are installed, you can select the properties for this service under the Advanced tab. Two options can be changed, and setting the Browse Master to disable ensures that the user gets the Browse list more quickly through the tunnel. NOTE For information about the rogue master browser problem and for many other good tips for people experiencing the preceding problem, go to www.cisco.com/warp/public/473/winnt_dg.htm#xtocid882960. Windows NT/2000NT has a Registry key that indicates to the OS whether or not to maintain a list of servers for the browser function. It also indicates how the node acts in the browser context. If the key value is set to Auto (the default), the PC tries to force an election. When the workstation boots on an isolated LAN segment or for dialup, the result is that it cannot find a master browser (or backup master browser). After the tunnel is up, it sends out subnet broadcasts for a backup server, which gets forwarded across. If these go unanswered, it asks for an election. The Registry key to change is as follows (try setting it to No):
Lower the MTUAfter you complete the WINS modifications, and if you are still having problems browsing the domain, try lowering the MTU. This rarely occurs but there have been cases where the MTUs were set just a little too high. Try lowering them by 50 and see if that fixes the issue. For information on how to lower your MTU, refer to Scenario 1, Case 1. |
EAN: 2147483647
Pages: 235