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 |