| Most of the issues discussed in this section cause problems during or after tunnel buildup. For instance, the tunnel might have been built up properly, but users might be unable to send data for one of the following reasons: NAT With IPsec Issues NAT can interact or interfere with IPsec in the following ways: NAT in the Tunnel End Points There can be either a dynamic or static NAT entry configured on tunnel end points (routers). For IPsec to function correctly, be sure to configure NAT on the router to bypass the IPsec packets. Example 6-36 shows a sample output of bypassing dynamic NAT entries on the Dhaka router shown in Figure 6-6. Example 6-36. Sample Output of Bypassing Dynamic NAT Entries on Dhaka Router as Shown in Figure 6-6 ! The following line is perform PAT for the internet bound traffic for inside network ! 10.1.1.0/24 Dhaka(config)# ip nat inside source route-map nonat interface Ethernet1/0 overload ! Following deny statement on the ACL is to exclude the traffic from NAT/PAT. This is the ! traffic will go through the IPSec tunnel. Dhaka(config)# access list 150 deny ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255 ! Rest of the traffic will be translated Dhaka(config)# access list 150 permit ip 10.1.1.0 0.0.0.255 any ! Need to apply the ACL under the route map Dhaka(config)# route-map nonat permit 10 Dhaka(config)# match ip address 150 Dhaka(config)#
|
Bypassing static NAT entries is a bit tricky. Static NAT entries can be bypassed using a loopback interface and policy routing for Cisco IOS images in versions earlier than 12.2.4T; starting from 12.2.4T, a route-map can be used with static NAT to bypass NAT. Example 6-37 shows the configuration required to bypass static NAT on the Dhaka router. Example 6-37. Configuration Steps Required for Bypassing Static NAT Entries for Dhaka Router Shown in Figure 6-5 Dhaka# show running-config crypto map to_Doha 10 IPsec-isakmp set peer 30.1.1.1 set transform-set myset ! This is the ACL that defines the traffic that needs to go through the IPsec tunnel. ! When configuring NAT, you need to bypass this traffic match address 101 ! Create a loop back interface so that static NAT can be pointed here as outgoing Interface loopback 0 ip address 1.1.1.1 255.255.255.252 interface Ethernet1/0 ip address 20.1.1.1 255.255.255.0 ! This is the outgoing interface (facing towards the internet) ip nat outside ! Crypto map is applied here crypto map to_Doha interface Ethernet0/0 ip address 10.1.1.1 255.255.255.0 ! This is the inside interface for the NAT ip nat inside ip route-cache policy ! This policy route will be triggered before NAT and the crypto which will take care of ! the bypassing of the IPSec traffic. ip policy route-map nonat ! ACL 1 defines what traffic needs to be NATed. ip nat inside source list 1 interface Ethernet0/3 overload ! This is the static NAT ip nat inside source static 10.1.1.12 20.1.1.20 ! This access-list 1 is used in the NAT statement to traffic that traffic that needs to ! be translated access list 1 permit 10.0.0.0 0.255.255.255 ! This ACL is to define the IPSec interesting traffic access list 101 permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255 ! This ACL is used in the route map to define the traffic that needs to bypass the NAT access list 120 permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255 ! This route map is applied on the Ethernet 0/0 interface route-map nonat permit 10 match ip address 120 set ip next-hop 1.1.1.2 Dhaka#
|
Example 6-38 shows how to bypass static NAT using route map on the Dhaka router shown in Figure 6-6. Example 6-38. Shows How to Bypass Static NAT Using Route Map on Dhaka Router Shown in Figure 6-6 Dhaka# show running-config crypto map to_Doha 10 IPsec-isakmp set peer 30.1.1.1 set transform-set myset match address 101 interface Ethernet1/0 ip address 20.1.1.1 55.255.255.0 ip nat outside crypto map to_Doha interface Ethernet0/0 ip address 10.1.1.1 255.255.255.0 ip nat inside ip nat inside source list 1 interface Ethernet0/3 overload ip nat inside source static 10.1.1.1 20.1.1.20 route-map nonat access-list 1 permit 10.1.1.0 255.255.255.0 access-list 101 permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255 access-list 120 deny ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255 access-list 120 permit ip 10.1.1.0 0.0.0.255 any route-map nonat permit 10 match ip address 120 Dhaka#
|
Note Example 6-38 shows how to bypass static NAT, which is a better method than bypassing static NAT as shown in Example 6-37.
If NAT is broken, execute the following debug to troubleshoot NAT issues on the router. show ip nat translation debug ip nat debug ip policy
NAT in the Middle In many cases, VPN clients are behind NAT/PAT, a device that causes IPsec tunnel establishment failure. To work around this problem you can configure IPsec over NAT (NAT-T), which was first introduced in 12.2(15)T for IOS routers. The IPsec pass-through feature is supported on certain NAT/PAT devices; ISAKMP cookie and ESP Security Parameter Index (SPI) are used to build a translation table. NAT-T is turned on by default on Cisco IOS. You should use ESP authentication rather than AH because NAT devices modify the outer IP header, which causes the AH integrity check to fail. Also, use Tunnel mode instead of Transport mode. More detailed discussions on the NAT with IPsec issues can be found in the following links: http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110c03.html http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00801541de.html http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110bca.html Firewall and IPsec Issues In some situations, a firewall can play a role in IPsec implementation. Firewall in the middle If you have a firewall in the middle between two IPsec peers that are blocking ISAKMP (UDP/500), Phase 1 and 2 of IPsec tunnel establishment fails, because both Phases I and II of IPsec happen on UDP/500. If a UDP/500 port is open but IP/51 for AH and IP/50 for ESP are blocked by the firewall, the tunnel will be established with IKE and IPsec SA, but the data will not pass across the tunnel. So, in addition to opening UDP/500 port for ISAKMP, you also need to open up IP protocol 50 for ESP and IP Protocol 51 for AH. Additionally, if you have NAT-T configured, you need to open up UDP/ 4500, and for IPsec over TCP you need to open up the TCP/10000 on the firewall. Firewall on the IPsec tunnel end points If you have an access list configured on the egress interface of the tunnel end points router, you need to open up all the ports in your access list as discussed in the previously listed item.
Maximum Transmission Unit (MTU) Issues When sending IPsec traffic across the tunnel for both LAN-to-LAN and Remote Access VPN connections, MTU can cause problems. This is because IPsec adds additional overhead to the original packets. The problem is aggravated when you configure GRE over IPsec, as the GRE adds additional overhead to the original IP packets in addition to IPsec. The sizes of overhead vary depending on a number of variables, but usually a rough estimate for overhead when using configured IPsec tunnel mode is 60 bytes with ESP encryption and authentication. If transport mode is used, you can save 20 bytes, because no additional IP header is added to the packet. If you use GRE over IPsec, it adds an additional 24 bytes. Large IPsec packets introduce the following two problems: If the large IPsec packet size is greater than the maximum MTU allowed on the interface where the crypto map is applied, and if the Do not Fragment (DF) bit is not set, the router will fragment the IPsec packet before it sends out to the receiving end. Path MTU Discovery (PMTUD) is a mechanism to detect the smallest MTU along the path for the packet flows from the sender to the receiver. If the DF bit is set, and packet size is greater than the size of the outgoing interface of a router, the router sends a Internet Control Message Protocol (ICMP message 3, code 4) reply to the sender asking for a reduction in the packet size. If the ICMP reply is blocked by a firewall, the sender never receives the reply, so the packet is dropped.
There are several ways to get around the MTU issue with IPsec: Reduce the MTU size on the end station (both sender and receiver). To do so, find the size of the packets allowed across the path with the help of the following test from the Windows command prompt: ping l packet_size F destination_ip_address If ICMP is blocked, this test fails. If you have a huge number of hosts, this may not be a viable solution, as you will be setting up MTU on all the hosts. In this circumstance, the best option is to use ip tcp adjust-mss on the ingress (Local LAN) interface as follows: ip tcp adjust-mss size This command works only for the TCP connection. When the initial TCP connection is made, the router using the TCP connection instructs the end hosts to set the MTU to the number configured by the ip tcp adjust-mss size command. If you want PMTUD to work, allow an ICMP unreachable (type 3, code 4) message between the IPsec peers. If you have GRE over IPsec configured, you might want to configure the tunnel path-mtu-discovery command on the GRE tunnel interface to enable PMTUD on the GRE tunnel interface. The tunnel path-mtu-discovery command helps the GRE interface set its IP MTU dynamically, rather than statically with the ip mtu command. It is recommended that both commands be used for setting the MTU. The ip mtu command is used to provide room for the GRE and IPsec overhead relative to the local physical outgoing interface IP MTU. The tunnel path-mtu-discovery command allows the GRE tunnel IP MTU to be further reduced if there is a lower IP MTU link in the path between the IPsec peers. If PMTUD and the ip tcp adjust-mss fails, and you need to fragment the packets, you should fragment the packet on the Initiator Router before the encryption. With this, de-fragmentation takes place on the end hosts, not on the Responder router. More details on pre-fragmentation can be found at the following location: http://www.cisco.com/en/US/products/sw/iosswrel/ps1833/products_feature_guide09186a008009c92c.html If the DF bit is set and PMTUD is not working due to ICMP packets block, you should configure the router to clear the DF bit to avoid packet drops. In that way, at the cost of CPU overhead on the receiving end, you are ensuring that the packets are not dropped. For more details on this, refer to the following link: http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087ae1.html#wp1015359
For a detailed discussion on MTU, refer to the following link: http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml Split Tunneling Issues If you have traffic that needs to go to the Internet or another network bypassing the tunnel, once the tunnel is established on the VPN Client, you need to configure a split tunnel. With split tunnels, you need to define the traffic that should go through the tunnel and the network that should bypass the tunnel. If split tunneling is configured incorrectly, you might not be able to access subnets outside the VPN tunnel. Example 6-39 shows an excerpt of how to enable split tunneling for the VPN connections. The access list 101 command is associated with the group as configured in the crypto isakmp client configuration group my-group command. This allows the Cisco VPN client to bypass the tunnel to access other networks that are not defined in the access-list 101. The VPN client is assigned an IP address from a pool defined with network 10.1.3.0/24. Therefore, based on access-list 101, traffic flows encrypted between 10.1.3.0/24, which is the IPsec tunnel network and the 10.1.1.0/24, which is the inside network. The rest of the traffic goes unencrypted, bypassing the tunnel (for example, Internet-bound traffic). Example 6-39. Excerpt of Configuration for Split Tunneling on Router Dhaka# show running-config ! ! This group name is configured earlier for defining the mode-config parameters. You just ! need to add the acl 101 that you have defined for the traffic that needs to go through ! the IPsec tunnel. crypto isakmp client configuration group my-group key hw-client-password dns 10.1.1.3 wins 10.1.1.2 domain cisco.com pool dynpool ! Following line is an addition to existing group configuration for turning on split ! tunneling. acl 101 ! ! The ACL must include the network that should go through the tunnel. Rest of the traffic ! from VPN clients not defined in this ACL will go in clear text. access-list 101 permit ip 10.1.3.0 0.0.0.255 10.1.1.0 0.0.0.255 ! Dhaka#
|
|
