Firewall – What can an ISP do to block IPSEC traffic

You can do something like this in Windows 2003 or newer OS's to add a policy, a filter list, and an entry to that filter list:

netsh ipsec static add policy name="Prevent TELNET Servers" description="Prevents running TELNET servers"
netsh ipsec static add filter filterlist="My filter list" srcaddr=any srcport=0 dstaddr=me dstport=23 protocol=tcp mirrored=yes

You can use "dstmask" and "srcmask" to specify ranges of IP addresses. Bear in mind that you'll have to actually assign that policy if you want it to do anything.

Some background on using NETSH and IPSEC is available at Microsoft at: http://technet.microsoft.com/en-us/library/cc739550(WS.10).aspx

On XP machines you'll use the IPSECCMD.EXE utility, available from the Windows 2000 resource kit.

With a little assistance from Cisco I did some deeper analysis of what was happening, and figured out the things that I needed to be checking for. The useful things that Cisco told me:

• debug crypto isakmp 5 gives enough detail to see whether problems are occurring with ISAKMP traffic
• clear crypto isakmp sa clears out any stale security associations.
• clear crypto isakmp {client_ip_address} can be used on the HQ to clear out a specific security association (you don't necessarily want to clear all your security associations if it is only one device that is having trouble!
• packet captures at both ends are really useful to figure out what is going on

Reading up a little on the IPSEC suite, and ISAKMP more specifically showed that the following need to be allowed through any firewalls in the path:

• ISAKMP traffic on UDP port 500
• ISAKMP (used for NAT-Tunnelling) traffic on UDP port 4500
• ESP traffic (IP Protocol 50)
• AH traffic (IP Protocol 51)

It seems a lot of people out there don't realise the important difference between IP protocols and TCP/UDP ports.

The following packet captures focussed on the above types of traffic. These were set up on both the remote and HQ ASAs:

object service isakmp-nat-t 
    service udp destination eq 4500 
    description 4500
object-group service ISAKMP-Services
    description Traffic required for ISAKMP
    service-object esp 
    service-object ah 
    service-object object isakmp-nat-t 
    service-object udp destination eq isakmp
access-list ISAKMP extended permit object-group ISAKMP-Services host {hq_ip_address} host {remote_ip_address}
access-list ISAKMP extended permit object-group ISAKMP-Services host {remote_ip_address} host {hq_ip_address}
capture ISAKMP access-list ISAKMP interface outside

You can then download the captures from each device at https://{device_ip_address}/capture/ISAKMP/pcap and analyse it in Wireshark.

My packet captures showed that ISAKMP traffic outlined above was getting fragmented - since those packets are encrypted, once they are fragmented it is hard to put them back together and things break.

Giving this information to the ISP meant they could do their own focussed checking, and resulted in them making some changes to a firewall. Turns out the ISP was blocking all ICMP traffic on their edge router, which meant that Path MTU Discovery was broken, resulting in fragmented ISAKMP packets. Once they stopped blanket blocking ICMP the VPN came up (and I expect all their customers started getting better service in general).