| There are several common issues that you might encounter with the tunnel build-up process or with sending data across the tunnel. These have been discussed in the preceding relevant troubleshooting sections. This section reiterates all the following common problems in more detail and provides solutions. NAT with IPsec Issues NAT can interact or interfere with IPsec in two ways, which are discussed in detail in this section. NAT in the tunnel End Point If you have NAT configured on the tunnel end points (for example, on PIX-A or PIX-B or both), for IPsec to work properly, you must configure a NAT exemption. You would do so under the following circumstances: If the nat-control command is enabled If the nat-control command is on, you must configure NAT; otherwise, PIX will not pass traffic. Under this configuration setup, you need to configure NAT because the traffic requires translation (usually Internet-bound traffic), and create a NAT exemption for the VPN traffic. If the nat-control command is disabled, but the PIX is configured with NAT If the nat-control command is turned off, but you have NAT configured, which translates the source network of the VPN traffic, you need to create the NAT exemption to bypass the NAT for the VPN traffic. If the nat-control is disabled, and NAT is not configured With this configuration setup, you do not need any configuration to bypass the NAT for the VPN traffic.
You can configure NAT exemption for both LAN-to-LAN and Remote Access VPN traffic. See the "Troubleshooting LAN-to-LAN" and "Troubleshooting Remote Access VPN" for configuration details. In some special cases, you also may need to perform the translation for the VPN traffic. Examine an example that illustrates this point. Assume that the PIX-A in Figure 7-1 has a private network 192.168.1.0/24 network, and PIX-B has the same private network. If these private networks need to communicate with each other through VPN tunnel, you must translate either side to avoid the duplicate network problem. Assume that 192.168.1.0/24 on PIX-B is translated to 192.168.2.0/24 by static command. For a successful tunnel build-up, you must include the translated IP address in the interesting traffic ACL for crypto map. NAT Device In the Middle of Tunnel End Points If you have a NAT device between the IPsec peers (for both LAN-to-LAN) and remote access, regular IPsec may not work. For this circumstance, a few work-arounds are discussed in this section. IPsec over NAT Transparency (NAT-T) If you have a NAT device between a VPN client and a PIX firewall for Remote Access VPN, or between two PIXen in the case of a LAN-to-LAN VPN, you can configure NAT Transparency (NAT-T). NAT-T encapsulates IPsec traffic in UDP using port 4500, thereby providing NAT devices with port information. NAT-T auto-detects any NAT devices, and only encapsulates IPsec traffic when necessary. NAT-T is disabled by default on the PIX firewall. When you enable NAT-T, PIX Firewall automatically opens port 4500 on all IPsec-enabled interfaces. You can enable IPsec over NAT-T globally on the PIX firewall by using the command isakmp nat-traversal natkeepalive. If you want to set the keepalive value to one hour, you can use the following command: PIX-A(config)# isakmp nat-traversal 3600
The default keepalive is 20 seconds. This keepalive is used to prevent the NAT device translation from timing out. To configure NAT transparency, open the VPN Client by going to Start > Programs > Cisco Systems VPN Client > VPN Client. Select the profile, and click on Modify. Click on Transport and check the Enable Transparent Tunneling check box. Finally, choose IPsec over UDP(NAT/PAT) radio button. IPsec over TCP IPsec over TCP encapsulates both the ISAKMP and IPsec protocols within a TCP packet, and enables secure tunneling through both NAT and PAT devices and firewalls. This feature is disabled by default. It is important to note that IPsec over TCP does not work with proxy-based firewalls. This feature is available only for Remote Access VPN, not for LAN-to-LAN tunnel. The default port is TCP/10000. To configure IPsec over TCP, you need to configure both the PIX and the VPN client software. On the PIX firewall, use the following command to turn on IPsec over TCP on the port you choose. Use the default port. You can leave the port off. isakmp ipsec-over-tcp [port port 1...port0]
The following example shows how to set up IPsec over TCP on port 425: PIX-A(config)# isakmp ipsec-over-tcp port 425
To configure IPsec over TCP, open VPN Client by going to Start > Programs > Cisco Systems VPN Client > VPN Client. Select the profile, and click on Modify. Click on Transport and check the Enable Transparent Tunneling check box. Finally, choose IPsec over TCP radio button, and define the port number you desire. When to Use NAT-T or IPsec over TCP/UDP? The PIX firewall can be configured simultaneously for standard IPsec, IPsec over TCP, NAT-Traversal, and IPsec over UDP. If you have all options configured, the following is the sequence of precedence: 1. | IPsec over TCP
| 2. | NAT transparency (NAT-T)
| 3. | NAT over UDP
|
Following are the transparent tunneling options available for different types of VPN implementation: For LAN-to-LAN tunnel You can configure regular IPsec, NAT-T, and IPsec over UDP for LAN-to-LAN VPN. For Remote Access VPN You can configure all options: regular IPsec, NAT-T, and IPsec over UDP for Remote Access VPN implementation. For Hardware Clients The VPN 3002 hardware client can connect using standard IPsec, IPsec over TCP, NAT-Traversal, or IPsec over UDP.
So, depending on the types of VPN implementation, you can configure all options available or a specific transparent tunneling option. Firewall and IPsec Just like the NAT, a firewall can play a role in IPsec implementation for both LAN-to-LAN and Remote Access VPN implementation. Firewall in the middle If you have a firewall in the middle between 2 IPsec peers blocking ISAKMP (UDP/500), phase I of IPsec will fail, as both phases I and II of IPsec occur on UDP/500. If you have UDP/500 open but ESP blocked (IP/50) by the firewall, then even though the tunnel will be established with IKE and IPsec SA, data will not be able to pass across the tunnel. So, you need to open UDP/500 and ESP (IP/50). If you have configured IPsec over TCP, then you need to open TCP/10000 (by default) across the firewall. If NAT-T is configured, then the firewall needs to allow UDP/4500 packets. Otherwise, the tunnel will not be built up. Firewall on the IPsec end point Unlike IOS router, you do not need to allow the UDP/500, UDP/4500, TCP/10000, or ESP packet on the outside interface of the PIX firewall to allow the peer to build up the tunnel with the PIX firewall. However, you need to allow the decrypted IPsec packet on the interface where the tunnel is terminated. To allow all IPsec decrypted traffic, configure sysopt connection permit-ipsec to bypass ACL checking. Otherwise, allow all those decrypted data packets using access-list.
Maximum Transmission Unit (MTU) Issues When sending IPsec traffic across the tunnel for both LAN-to-LAN and Remote Access VPN, MTU can cause problems because of additional overhead on the packets imposed by IPsec. The sizes of overhead vary across several variables, but usually a rough estimate for overhead, when configured for IPsec tunnel mode, is 60 bytes with ESP encryption and authentication. If transport mode is used, you can save 20 bytes, as no additional IP header is added to the packet. The list that follows outlines two problems that large IPsec packets introduce: If the IPsec packet size is greater than the maximum MTU allowed on the interface where the crypto map is applied, and if "Do not Fragment (DF)" is set, then the PIX firewall will drop the packets. If the IPsec packet size is greater than the maximum MTU allowed on the interface where the crypto map is applied and if the DF is not set, PIX will fragment the packet, and will send it to the other side. Although this is better than dropping the packets, it poses some problems on the receiving device. The receiving device needs to defragment the packets, and if the fragmented packet comes out of order, this consumes resources unnecessarily, and can cause packet drops.
There are several ways to get around this problem: Path MTU Discovery (PMTUD) PMTUD is a mechanism for detecting the smallest MTU along the path for the packet flows from the sender to the receiver. If the DF bit is set, and the packet size is greater than the size of the outgoing interface of the PIX firewall, the PIX will send an Internet Control Message Protocol (ICMP) (message 3, code 4) reply to the sender requesting notification of the packet size. If the TCP/IP stack of the sender supports PMTUD, and if the ICMP reply packets are not blocked by a firewall, the sender will re-adjust the MTU before sending out the packets. Otherwise, packets will be dropped. It is strongly recommended that you reduce the MTU size of the packet on the end devices. This way you can avoid doing the fragmentation on the network devices. Reduce MTU size on End hosts As mentioned before, it is strongly recommended to reduce the MTU on the end hosts. If the PMTUD does not work, you need to set the MTU size on the end hosts manually. For LAN-to-LAN connections, set the MTU of the end host for the Network Interface Card (NIC) for TCP/IP stack. In case of Remote Access VPN, you have the option of setting the MTU with the "Set MTU" utility installed with the VPN client software. Before you try to adjust the MTU, find out what MTU size is allowed across the path. You can determine this with the ping l packet_size F destination_ip_address command in your Command prompt of end host, as shown in Example 7-57 (on Windows 2000 Professional): Example 7-57. Checking for MTU on Windows 2000 Professional D:\>ping -l 1450 -f www.xyz.com Pinging www.xyz.com [10.1.1.100] with 1450 bytes of data: Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Ping statistics for 10.1.1.100: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms D:\>
|
Perform the ping test readjusting the size of packet until you get a reply on the ping. The size with which you get a ping reply is the MTU allowed along the path. Dynamically adjust MTU on End Host with TCP protocol If you have a large number of hosts, and if the PMTUD doesn't work because ICMP packets are blocked along the path, setting the MTU on end host manually may not be a scalable solution. If so, you can adjust the MTU on end hosts with the sysopt connection tcpmss command on the PIX firewall. This command only works for TCP-based applications. PIX firewall has sysopt command for tcpmss turned on by default, and the tcpmss is set for 1380. This value is recommended, and will work under normal circumstances. If it doesn't work for you, you can re-adjust this value, but perform a test with the command shown in example 7-58. Example 7-58 shows how to check the MTU size of the interface, what value is set for tcpmss and how to reset this value.
Example 7-58. Checking the MTU, tcpmss Value, and Resetting this Value on the PIX Firewall PIX-A(config)# show running-config mtu ! Following shows MTU on the interface is set to 1500 bytes. Any packet larger ! than 1500 bytes will be fragmented mtu outside 1500 mtu inside 1500 PIX-A(config)# show running-config sysopt | include tcpmss ! The following line shows the tcpmss is set to 1380 bytes. This is the default ! recommended settings that is on by default on the PIX firewall. This is the ! value that will be suggested to end host by the PIX firewall. sysopt connection tcpmss 1380 sysopt connection tcpmss minimum 0 ! If there is another device between the PIX and the destination end host, and ! that device requires the packet size to be 1250, you can readjust the tcpmss ! with the following command. PIX-A(config)# sysopt connection tcpmss 1250 ! Verify the settings again PIX-A(config)# show running-config sysopt | include tcpmss sysopt connection tcpmss 1250 sysopt connection tcpmss minimum 0 PIX-A(config)#
|
For more details on MTU, refer to the following links: http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml http://www.cisco.com/en/US/partner/tech/tk870/tk877/tk880/technologies_tech_note09186a008011a218.shtml http://www.cisco.com/en/US/partner/products/hw/routers/ps4081/products_tech_note09186a0080094268.shtml Split Tunneling Issues Split tunneling allows a Remote Access VPN client to conditionally direct packets over an IPsec tunnel in encrypted form or to a network interface in clear text form, depending on your need. With split tunneling enabled, traffic that is destined for the other side of the tunnel goes through the tunnel encrypted. Other traffic goes in clear text (for instance, Internet-bound traffic). Split tunneling also allows you to access the Local LAN (for example, printer, file server, and so on) while the tunnel is up. To configure split tunneling, first set the rules for tunneling traffic by specifying the split-tunneling policy with the following command under group-policy: split-tunnel-policy {tunnelall | tunnelspecified | excludespecified}
The default policy is to tunnel all traffic on the PIX firewall. Different options for split tunneling policy are explained as follows: tunnelall This is the default option, and it dictates that the VPN client should send all traffic across the tunnel. Essentially, this option disables split tunneling. Remote users reach the Internet through the corporate network and do not have access to local networks. This is recommended when possible. tunnelspecified This option allows you to define the traffic that needs to be encrypted and go through the tunnel. This is accomplished by creating an access-list and defining the networks that need to be encrypted and encapsulated by the tunnel. Data to all other addresses travels in the clear and is routed by the remote user's Internet service provider. If you need to configure this option, be sure to install a personal firewall or Host IPS software on the VPN client hosts. excludespecified This option allows you to define a list of networks to which traffic goes in the clear. This feature is useful when you want to access devices on the local network, such as printers, while you are connected to the corporate network through a tunnel. This option is supported only on the Cisco VPN client. The list of networks for this option is defined by the access-list, and any traffic not defined by this access-list passes through the tunnel encrypted.
Work through the following steps to configure a split tunneling policy to tunnel only specified networks that are defined by access-list: | | Step 1. | Create an access-list to define the source and destination network that must go through the tunnel. The rest of the other traffic will be sent from the VPN client host in clear text (for example, Internet-bound traffic). Example 7-59 shows a standard access-list that includes network 192.168.1.0/24, and 192.168.2.0/24 for the VPN client traffic.
Example 7-59. Creating a Standard Access-List that Defines the Network that Should Go Through the Remote Access VPN Connection ! You must create a standard access-list for split tunneling PIX-A(config)# access-list 1 permit 192.168.1.0 255.255.255.0 ! The above access-list is for the network on PIX-A LAN side ! The following access-list is for the LAN network access on PIX-B if you have ! the Hairpinning configured as shown in the Case Study section. PIX-A(config)# access-list 1 permit 192.168.2.0 255.255.255.0 ! The following command verifies the configuration of access-list 1 that you ! have just created. PIX-A(config)# show running-config access-list 1 access-list 1 standard permit 192.168.1.0 255.255.255.0 access-list 1 standard permit 192.168.2.0 255.255.255.0 PIX-A(config)#
|
| Step 2. | Define the split-tunnel-policy and the network list under the group-policy that you have previously configured (the name of the policy is mypolicy). Example 7-60 shows how to apply the access-list and define the tunnel policy type.
Example 7-60. Configuring Split-Tunnel-Policy and Appyling the Network List on PIX-A PIX-A(config)# group-policy mypolicy attributes ! Following command turns on split tunneling with tunnelspcified option PIX-A(config-group-policy)# split-tunnel-policy tunnelspecified ! Following command applies the Split tunneling list 1 that you have created in ! the previous step. PIX-A(config-group-policy)# split-tunnel-network-list value 1 PIX-A(config-group-policy)#
|
Once you build up the Remote Access VPN tunnel connection, right-click on the VPN Client icon at the bottom of the screen, and choose Statistics to bring up the VPN Client Statistics window. Look under Route Details > Secured Routes. If split tunneling is working, then you should only see 192.168.1.0/24 and 192.168.2.0/24 networks listed under Secured Routes. Only networks listed under Secured Routes will go through the tunnel.
|
|
