ESP traffic through NAT!!!!!

Hey security experts-

I'm using Cisco VPN client v5 and an ASA 5505 running v8.2.

I am connecting to the ASA using the VPN client. I am behind a NAT firewall. If I disable Transparent Tunneling on the VPN client, the VPN tunnel will still work! I ran a packet capture. The VPN is using ESP packets through a NAT device! ESP packets through a NAT device!!! A few searches on cisco's site shows this is a new feature in the past few years! This is amazing! How does NAT not break the ESP checksum validation? I tested this using 2 different NAT firewalls. The first firewall was a Cisco 871. A 'show ip nat trans' command shows the IOS uses the SPI to xtranslate the traffic. The second firewall was a SonicWALL E7500.

Security experts, have you ever seen this? There's not much use for this as it is heavily dependent on the NAT firewall supporting ESP multiplexing. But still, I was always told ESP can't work through NAT because the IP header is used in the ESP checksum validation.

ESP through NAT.. Amazing!

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

Ahriakin

Are you sure NAT-T (as opposed to cisco transparent tunnelling) is not still enabled?
Also ESP works with NAT, it only needs encapsulation with PAT.

_maurice

Hi Ahriakin,

I have taken a packet capture on the computer running the VPN client, and on the ASA. The packet capture shows no NAT-T or NAT-D ISAKMP Vendor IDs. After passing phase 2, encrypted traffic is sent via ESP, not ESP within UDP. I have attached the packet captures from both the computer and the ASA. I also ran a 'show ip nat trans esp' on the Cisco 871 (the NAT firewall) and it shows the SPI being used as a "port" to multiplex traffic. I also did a 'show cry ipsec sa' on the ASA showing the IPSec endpoints use ESP.

Cisco document explaining ESP through NAT: Support for IPSec ESP Through NAT [Cisco IOS Software Releases 12.2 T] - Cisco Systems

My packet captures: http://72.222.130.156:81/caps.zip

cisco871#sh ip nat tran esp
Pro Inside global Inside local Outside local Outside global
esp 72.222.130.156:0 1.2.3.3:0 68.3.2.207:0 68.3.2.207:4C3B805A
esp 72.222.130.156:0 1.2.3.3:CD5F55EA 68.3.2.207:0 68.3.2.207:0

ciscoasa# sh crypto ipsec sa
interface: outside
Crypto map tag: dynamic-crypto-map, seq num: 1, local addr: 68.3.2.207

local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (2.0.0.10/255.255.255.255/0/0)
current_peer: 72.222.130.156, username: poop
dynamic allocated peer ip: 2.0.0.10

#pkts encaps: 227, #pkts encrypt: 227, #pkts digest: 227
#pkts decaps: 313, #pkts decrypt: 313, #pkts verify: 313
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 227, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0

local crypto endpt.: 68.3.2.207, remote crypto endpt.: 72.222.130.156

Ahriakin

Ahriakin wrote: »

Also ESP works with NAT, it only needs encapsulation with PAT.

ESP+NAT is fine with just about everything these days (has been on Cisco boxes for years). You only need encapsulation with PAT as ESP has no ports to map.

_maurice

Ahriakin wrote: »

ESP+NAT is fine with just about everything these days (has been on Cisco boxes for years). You only need encapsulation with PAT as ESP has no ports to map.

Hi Ahriakin,

Can you please elaborate on this? When you say encapsulate with PAT, do you mean encapsulate the ESP payload in a UDP header?

Please take a look at my packet captures. Or take a look at my output of 'show ip nat trans esp'. Or take a look at the Cisco doc I posted in my previous post.

This ESP payload is not encapsulated in anything other than an IP header. And the SPI of the VPN security association is used as the port for NAT. Take a look at this output:

Router# debug ip nat ipsec

5d21h:NAT:new IKE going In->Out, source addr 192.168.122.35, destination addr
192.168.22.20, initiator cookie

0x9C42065D

5d21h:NAT:IPSec:created In->Out ESP translation IL=192.168.122.35 SPI=0xAAE32A0A,
IG=192.168.22.40, OL=192.168.22.20,

OG=192.168.22.20

5d21h:NAT:IPSec:created Out->In ESP translation OG=192.168.22.20 SPI=0xA64B5BB6,
OL=192.168.22.20, IG=192.168.22.40,

IL=192.168.122.35

5d21h:NAT:new IKE going In->Out, source addr 192.168.122.20, destination addr
192.168.22.20, initiator cookie

0xC91738FF

5d21h:NAT:IPSec:created In->Out ESP translation IL=192.168.122.20 SPI=0x3E2E1B92,
IG=192.168.22.40, OL=192.168.22.20,

OG=192.168.22.20

5d21h:NAT:IPSec:Inside host (IL=192.168.122.20) trying to open an ESP connection to
Outside host (OG=192.168.22.20),

wait for Out->In reply

5d21h:NAT:IPSec:created Out->In ESP translation OG=192.168.22.20 SPI=0x1B201366,
OL=192.168.22.20, IG=192.168.22.40,

IL=192.168.122.20

_maurice

I'm trying to show ESP is being NAT'ed by using the SPI as the port. Take a minute to look at the captures or the documentation. It is quite wild.

Ahriakin

NAT (one-one) tracks by host so the SPI can be used, PAT requires ports for tracking so PAT breaks ESP (or ESP breaks PAT, depends on how you want to look at it

). You'll notice in the page you linked they do a simple 1-1 static NAT.
The whole reason we use encapsulation of any kind is to use a transport that does use port numbers so PAT has something to 'latch on to'.

_maurice

Ahriakin,

I agree with what you are saying. But I do not have a static NAT for this host. I am NAT overloading my public IP address. Here is an output from my NAT firewall:

cisco871#sh ip nat tran esp
Pro Inside global Inside local Outside local Outside global
esp 72.222.130.156:0 1.2.3.3:0 68.3.2.207:0 68.3.2.207:4C3B805A
esp 72.222.130.156:0 1.2.3.3:CD5F55EA 68.3.2.207:0 68.3.2.207:0

Do you see how the SPI is used as the "port".

Also Ahriakin, have you ever wondered how an ICMP packet is port address translated? There is a Sequence Number in the ICMP header that acts as a unique port number like TCP/UDP.

The same way you explain PAT latching on to the port in a TCP/UDP packet, is the same way I am explaining the cisco IOS can latch on to an SPI for esp traffic.

Ahriakin

I understand the concept of non UDP/TCP based tracking. Yes you can track connections/xlates on any protocol by any unique identifier on the source packet, whether it be a sequence number/SPI or whatever, but this is vendor (and usually also device/OS) specific, not to mention it is much more resource intensive since some form of deeper inspection is required to find the pattern you wish to match on. That's why even though some Cisco models can perform passhthrough they have essentially deprecated it in recent years in favour of industry standards like NAT-T. For the sake of interoperability (even among devices from the one vendor) it's best to forget passthrough even exists.