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