RE: NAT-T over IPSec Question

From: Lab Rat #109385382 (techlist01@gmail.com)
Date: Sun Nov 26 2006 - 16:44:49 ART

Petr,

 

Thanks for the info, but my question is would you see NAT-T occurring on
routers automatically? In other words, isn't it expected that NAT-T will
not be used unless going through a PAT device?

 

When would one have to issue the command "no crypto ipsec nat-transparency
udp-encap" command explicitly?

 

Thanks,

 

Ed

 

 

From: petrsoft@gmail.com [mailto:petrsoft@gmail.com] On Behalf Of Petr
Lapukhov
Sent: Sunday, November 26, 2006 7:46 AM
To: Lab Rat #109385382
Cc: cisco@groupstudy.com; Cisco certification; Groupstudy
Subject: Re: NAT-T over IPSec Question

 

During it's evolment, IPsec suite has develpoed a bunch of ways to deal with
NAT.

Just to mention a few

1) NAT-T
2) SPI matching & IPsec aware NAT
3) IPsec over UDP and IPsec over TCP

With the exception of the first, other are proprietary, and are not that
common.

Now, If you want to verify whether NAT-T takes place with IOS routers, you
may issue
the following commands:

1) debug crypto isakmp

The output should show something like this:

NAT-Discovery Phase for router behind NAT:
....
*Mar 2 06:00:25.608: ISAKMP (0:1): constructed HIS NAT-D
*Mar 2 06:00:25.608: ISAKMP (0:1): constructed MINE NAT-D
.........
*Mar 2 06:00:26.160: ISAKMP:received payload type 17
*Mar 2 06:00:26.160: ISAKMP (0:1): Detected NAT-D payload
*Mar 2 06:00:26.160: ISAKMP (0:1): NAT does not match MINE hash
*Mar 2 06:00:26.160: hash received: 16 26 6 5E DB 49 79 94 C1 ED A7 9B B1
A0 D1 16
*Mar 2 06:00:26.160: my nat hash : E1 12 C9 D8 EE B7 50 9 3 3 4E E3 6D 53
A8 11
*Mar 2 06:00:26.164: ISAKMP:received payload type 17
*Mar 2 06:00:26.164: ISAKMP (0:1): Detected NAT-D payload
*Mar 2 06:00:26.164: ISAKMP (0:1): NAT match HIS hash

2) show crypto ipsec sa

Look for "in use settings ={Tunnel UDP-Encaps, }"

R1#show crypto ipsec sa

interface: FastEthernet0/0
    Crypto map tag: VPN, local addr. 130.1.19.1

   protected vrf:
   local ident (addr/mask/prot/port): (150.1.1.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (150.1.4.0/255.255.255.0/0/0)
   current_peer: 130.1.239.254:4500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest 4
    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify 4
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 1, #recv errors 0

     local crypto endpt.: 130.1.19.1, remote crypto endpt.: 130.1.239.254
     path mtu 1500, media mtu 1500
     current outbound spi: 656012E7

     inbound esp sas:
      spi: 0x9E520B00(2656176896)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel UDP-Encaps, }
        slot: 0, conn id: 2000, flow_id: 1, crypto map: VPN
        sa timing: remaining key lifetime (k/sec): (4512807/3182)
        IV size: 8 bytes
        replay detection support: Y

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x656012E7(1700795111)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel UDP-Encaps, }
        slot: 0, conn id: 2001, flow_id: 2, crypto map: VPN
        sa timing: remaining key lifetime (k/sec): (4512807/3182)
        IV size: 8 bytes
        replay detection support: Y

     outbound ah sas:

     outbound pcp sas:

3) show crypto isakmp sa detail

Look for "N" keyword

R1#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       X - IKE Extended Authentication
       psk - Preshared key, rsig - RSA signature
       renc - RSA encryption

C-id Local Remote I-VRF Encr Hash Auth DH Lifetime
Cap.
1 130.1.19.1 130.1.239.254 des md5 psk 2 23:51:43 DN

4) The transit PIX firewall show output:

Look for port 4500

PIX(config)# show conn detail
5 in use, 9 most used
Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,
       B - initial SYN from outside, C - CTIQBE media, D - DNS, d - dump,
       E - outside back connection, F - outside FIN, f - inside FIN,
       G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data, i -
incomplete,
       k - Skinny media, M - SMTP data, m - SIP media, O - outbound data,
       P - inside back connection, q - SQL*Net data, R - outside
acknowledged FIN,
       R - UDP RPC, r - inside acknowledged FIN, S - awaiting inside SYN,
       s - awaiting outside SYN, T - SIP, t - SIP transient, U - up
TCP outside:130.1.239.2/11034 inside:130.1.19.1/179 flags UIOB
UDP outside:130.1.239.254/4500 inside:130.1.19.1/4500 flags - 

---

It has been correctly mentioned that NAT-T is not required with static NAT;
you may disable it even with PAT, in some cases, e.g.:

1) SPI matching IPsec-aware NAT devices
2) static port mapping for IKE (udp 500) and static map for ESP 

These two cases require separate discussion, though;

HTH

2006/11/26, Lab Rat #109385382 <techlist01@gmail.com>:

Here's my scenario:

ROUTER1  (f0 - 1.1.1.1) ------ (out - 1.1.1.2)  PIX  (in - 2.2.2.2) ------
(f0 - 2.2.2.1)  ROUTER2

If I'm doing an L2L IPSec tunnel between the two routers through a PIX (with
ROUTER2 translated via the "static" command on the PIX), does this
automatically invoke NAT-T?

If so, how can I verify this?  By UDP 4500 requests coming into the PIX?

If not, when does NAT-T apply to a static NAT scenario?  I know you have to
enable NAT-T when using PAT, but what about static NAT?

Any help would be much appreciated.

Thanks,

Ed

This archive was generated by hypermail 2.1.4 : Fri Dec 01 2006 - 08:05:48 ART