LAN and General Networking Issues Affecting Remote Access VPNs
| Three LAN related issues are known to affect remote access VPNs: the improper configuration of a NAT device, availability of necessary firewall holes, and the method a NAT device uses to manipulate multiple VPN clients. Configuration of the NAT device is beyond the scope of this discussion. However, if the device is a Cisco product, you can consult www.cisco.com for the configuration commands, examples, and SW versions. The need for necessary firewall holes to be available was previously discussed. Another alternative is to implement TCP encapsulation on well-known ports. Finally, the third case described for the handling of multiple VPN clients connected behind a NAT device warrants further coverage. Multiple VPN Clients Behind a NAT DeviceDepending on the NAT device used, you can establish multiple remote access IPSec VPN connections to the same concentrator or different concentrators. Other times, you might observe that a single client can establish an IPSec VPN connection to a concentrator, but this client is disconnected if a second client establishes a connection to the same concentrator. In an environment that uses a different NAT device, you observe that you can have multiple IPSec client connections to the same concentrator. The explanations for the different observations are provided now. First, a NAT device in a PAT environment overloads private IP addresses on a single public IP address. To differentiate the traffic destined for each host on the private network, a unique TCP or UDP port is assigned to the private IP address. The NAT device handles all communication with public networks by using its single public IP address, and correctly distributes traffic destined for devices on the private network based on the unique TCP or UDP port assignment. However, when implementing IKE-based VPNs, several manufacturers misinterpreted the ISAKMP specification. These vendors incorrectly designed their products so that the UDP source port of an ISAKMP exchange must be 500. As a result, instead of the traditional NAT, vendors had to identify the different devices on the private network with IKE-based VPN connections by using the SPI as the identifier. The VPN 3000 concentrators allow multiple ISAKMP connections from the same IP address, if the source port of each of the ISAKMP streams is different. If you use a Cisco 806 IOS-based NAT device, you already know that the source port behavior is configurable. For other NAT devices, it is recommended that you contact the manufacturers of the equipment to learn their specific capabilities and support plans. MTUA Critical Factor for Troubleshooting Internet IPSec ConnectivityThe MTU, the largest possible size of a network Layer 2 payload or Layer 3 packet, is not constant throughout the Internet. It is the source of many issues for IPSec tunnels. Also, the Path MTU (PMTU) feature of the VPN client might not function if your concentrator is behind a firewall that does not permit Internet Control Message Protocol (ICMP) pings from the Internet. As a result, you need to identify and resolve issues related to the MTU with regards to IPSec communications. Basically, any intermediary IP routers that are encountered on the Internet (hops), which are set to an MTU less than 1500, often fragment packets, which divides them into smaller units before sending them out the respective interface. In an IPSec tunnel, the VPN client and concentrator are the only parties that can change the size of the packets that they exchange. Any attempt to change the packet content and size being sent in an IPSec tunnel by another router or device causes the IPSec connection to fail because the MTU requirements set by the originator of the packets, either client or concentrator, were not met (see the immutable fields concept in Chapter 19). The MTU is normally set in conjunction with the maximum segment size (MSS) and the TCP Receive Window (RWIN). MSS is the largest segment of TCP data that the Microsoft Winsock is prepared to receive on a connection. MSS must be smaller than the MTU by at least 40 bytes, which accommodates the IP and TCP headers that are each 20 bytes. RWIN determines how much data the receiving computer is prepared to receive. If RWIN is set too large, it results in greater loss of data if a packet is lost or damaged. If it is set too small, transmission is slow. Normally, RWIN is set to be four, six, or eight times the MSS (see TCP Windows scale option in RFC 1323). Practical examples in which the MTU is greater or equal to MSS+40 bytes is demonstrated by the following default IOS setting examples, for 8xx series routers running Cisco IOS ver.12.2+:
However, it is far more common to set the MTU for all traffic passing through an interface. Some common MTU settings include the following:
To illustrate further, the discussion is divided into the following sections:
Determining a Functional MTU Between the VPN Host and ConcentratorThe MTU value that you use with the Cisco VPN client is limited by the minimum MTU value of all segments between your host, and the concentrator to which you are trying to establish an IPSec tunnel. To determine the MTU of this path, you must first determine the path, then through a sequential process of pings with specific packet sizes, determine the minimum MTU of all the segments. In the following example, the ping utility determines a functional MTU from a client in Northern California by using AT&T Broadband Internet over cable, IP address 12.234.185.224, to www.cisco.com, IP address 198.133.219.25. At the command prompt, enter the following: C:/>ping -f -l [packetsize] [www.cisco.com] The elements are as follows:
If you exceed the minimum MTU of all the segments, the message you will most likely receive is "Packet needs to be fragmented, but DF set." If you receive this message, you need to decrease the size of the packet and repeat the ping as many times as required until you receive a successful echo reply from the remote host. To extract the MTU size from this information, assuming that the first successful echo reply message is when the packetsize is set to 1300, you can examine the results of a ping to 198.133.219.33 from a host with the IP address 12.234.185.224, as shown in Example 21-28. Example 21-28. Sniffer Capture Results from the Command[View full width] C:/>ping f l 1300 198.133.219.33 ! Performed from a Win2K host with IP=12.234.185.224. - - - - - - - - - - - - - - - - - - - - Frame 1 - - - - - - - - - - - - - - - - - - - - Frame Status Source Address Dest. Address Size Rel. Time Delta Time Abs. Time Summary 1 M [12.234.185.224] [198.133.219.25] 1342 0:00:00.000 0.000.000 02/03/2002 04:17:54 PM DLC: Ethertype=0800, size=1342 bytes IP: D=[198.133.219.25] S=[12.234.185.224] LEN=1308 ID=440 ICMP: Echo DLC: ----- DLC Header ----- DLC: DLC: Frame 1 arrived at 16:17:54.2930; frame size is 1342 (053E hex) bytes. DLC: Destination = Station 00301931778C DLC: Source = Station GtwCom462E8E DLC: Ethertype = 0800 (IP) DLC: IP: ----- IP Header ----- IP: IP: Version = 4, header length = 20 bytes ! Indicates the IP header size is 20 bytes. IP: Type of service = 00 IP: 000. .... = routine IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: .... ..0. = ECT bit - transport protocol will ignore the CE bit IP: .... ...0 = CE bit - no congestion IP: Total length = 1328 bytes ! The complete IP packet includes the IP header (20 bytes) + ! ICMP header (8 bytes) + ICMP payload (1300 bytes). IP: Identification = 440 IP: Flags = 4X IP: .1.. .... = don't fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 128 seconds/hops IP: Protocol = 1 (ICMP) IP: Header checksum = 8BAB (correct) IP: Source address = [12.234.185.224] IP: Destination address = [198.133.219.25] IP: No options IP: ICMP: ----- ICMP header ----- ICMP: ICMP: Type = 8 (Echo) ICMP: Code = 0 ICMP: Checksum = B5D2 (correct) ICMP: Identifier = 512 ICMP: Sequence number = 6400 ! The overall size of all previous fields in the ICMP header is 8 bytes, ! followed by the 1300 byte payload. ICMP: [1300 bytes of data] ! Indicates echo ICMP packet requests an echo reply from ! 198.133.219.25 with packet size 1300. ICMP: ICMP: [Normal end of "ICMP header".] ICMP: ! The following is the echo reply from 198.133.219.25. - - - - - - - - - - - - - - - - - - - - Frame 3 - - - - - - - - - - - - - - - - - - - - Frame Status Source Address Dest. Address Size Rel. Time Delta Time Abs. The MTU exceeds the parameter 1300 with only 20 + 8 = 28 bytes. NOTE The rule for setting MTU is that the largest value that does not result in the error "Packet needs to be fragmented, but DF set," is your ISP's MTU less 28 bytes. This excludes the IP (20 bytes) and ICMP (8 bytes) headers. Based on this rule and the findings from the example, you can set the MTU size of this VPN client to 1300 + 28 = 1328 bytes. 1300 might not be the maximum MTU that allows the VPN client to establish an IPSec tunnel and pass traffic. After you determine a packet size that does not respond with a successful ping, try to ping the router one hop closer to you, which you can identify with the traceroute utility (tracert on W2K hosts). If that's not successful, try to ping the next router one hop closer, and so on until you either receive a successful response or reduce the packet size and start the ping process over again. Effects of Packet Size on PerformanceData transfer performance is significantly impacted by the packet size, which affects the MTU. In this section, you review how latency and throughput, two parameters that are affected by changes in MTU, affect data transfer performance. In particular, you learn about the following:
Packet Size Versus LatencyIn this example, a data transfer over a standard ADSL line with a download speed of 600 kbps is examined using MTU packet sizes of 1500 and 576 on the same line. The following formula for latency applies:
NOTE MTU = MSS + (IP header + TCP header). Using these different MTU sizes (1500 and 576), you can calculate the latency as a function of the packet size, as follows:
Assuming a transfer over 10 hops, the 1500 MTU would yield 200 ms delay, while a 576 MTU would only take 76.9 ms to be downloaded. It is obvious the smaller packets will be transmitted faster. However, the amount of data transferred will be less by a factor of 1500 / 576 = 2.6 times. Throughput Versus Packet SizeUsing the same formula from the previous example, assume you need to transfer a 1 megabyte file over a T1 line:
If MTU = 1500, the delay would be 20 ms per hop and the MSS = 1460. 1 megabyte / MSS = 1,048,576 bytes / 1460 = 718.2. 719 packets are required to transfer 1 megabyte. The time required to transfer 1 megabyte = 719 packets x 20 ms per hop = 14.38 seconds per hop. Multiplied by 10 hops, this is 143.8 seconds. If MTU = 576, the delay would be 7.69 ms per hop and the MSS = 536. 1 megabyte / MSS = 1,048,576 bytes / 536 = 1956.3. 1957 packets are required to transfer 1 megabyte. The time required to transfer 1 megabyte = 1957 packets x 7.69 ms delay per hop = 15.049 seconds per hop. If you are transferring the 1 megabyte file over the same 10 hops, it will take 150.49 seconds. The difference is because of the fact that, when using larger packets, the overhead is smaller. Every packet carries header information. Smaller packets will require a greater number of packets (more headers) to pass the same amount of data. For example, to transfer 1 megabyte with an MTU of 1500, the overhead would be 719 (packets) x 40 (IP header + TCP header) = 28,760 bytes. If using an MTU of 576, the overhead would be 1957 x 40 = 78,280 bytes; an additional 49,520 bytes of headers are transferred for each megabyte. For the 10-hop transfer, the additional overhead will result in an extra 6.69 seconds difference in transfer time for every megabyte. This difference might be slightly larger in practice when considering TCP options such as sliding windows or TCP Receive window. Also, modern TCP/IP implementations might use larger headers, such as an additional 12-byte header space for timestamps. The provided calculations are not precisely correct because they are based on the assumption that the available access rate (physical line speed) can be used entirely for data traffic. The fact is that the effective throughput depends upon the way that TCP treats the line and line characteristics, which increases and reduces the TCP window. Generally, it's logical to assume that larger packets offer improved performance because of the following factors:
If throughput is not the ultimate goal, however, smaller packets might be more responsive because they require less time to travel throughout the network, and consequently, the probability of effects because of interference or any other factors is lower (geometric probability). This result might be preferred in some solutions, such as satellite and wireless, at the expense of throughput. The important factor here is how the error-free communication is managed. If every error requires retransmission, especially in wireless or satellite networks given the nature of these communications, the size of the window and MTU can significantly affect the overall throughput. If the error-free strategy assumes and applies correction codes, this can affect the performance model in a different way, and it is another factor to consider when comparing two solutions. NOTE Experiments with the Cisco Aironet 350 series AP show that the difference between MTU 1400 and MTU 576 can be 1:0.75 in favor of 1400 MTU with an error rate under 5 percent. Slow or Inaccessible Login to Kerberos Active DirectoryWindows 2000 and Windows XP users might be unable to log in or experience unusually long times for logging into a Kerberos Active Directory. This might be the case with either Cisco VPN Unity client or on a host connected through an IPSec VPN tunnel that is started by the Cisco VPN 3002 Hardware client, Cisco Easy VPN client, or Cisco PIX Hardware client. The time to login can exceed 20 minutes. Source of the Slow Login Is the Use of Kerberos over UDP FragmentsThe source of the issue is the use of Kerberos over fragmented UDP packets, and the problem can be especially acute when connected behind a NAT/PAT device that does not handle packet refragmentation correctly. ResolutionForce Kerberos to Use TCP Instead of UDPForcing Kerberos to use TCP instead of UDP packets eliminates this issue. On a Windows 2000 or Windows XP host, you can force Kerberos to use TCP by setting the Registry as follows: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters Value Name : MaxPacketSize Data Type : REG_DWORD Value : 1 Starting with v3.5.1c, the Cisco VPN Unity client installation package automatically changes the Registry to force Kerberos to use TCP. If you do not want to force Kerberos to use TCP when installing v3.5.1c or later versions of the client, change the VPN client installation file, oem.ini, as follows: [9]
[Main] DisableKerberosOverTCP = 1 |
Time Summary 3 [198.133.219.25] [12.234.185.224] 1342 0:00:00.018 0.018.214 02/03 
EAN: 2147483647
Pages: 235