cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6468
Views
5
Helpful
11
Replies

asa 5505 sw v 8.3 (1) NAT command

tanzeus129
Level 1
Level 1

I am trying to set up a site to site vpn VPN between to sites.

I have a new ASA v 8.3 at the new site. I am having issues and I believe it is all related to the NAT command that has changed with version 8.3.

I have read the release notes in regards to migrating to the new version of the NAT command, but I can't see what replaces this command.

Here is the output I get :

asa(config)# nat (inside) 0 access-list 100
ERROR: This syntax of nat command has been deprecated.
Please refer to "help nat" command for more details.

Here is my VPN portion of the config file:

==========================================

management-access inside

access-list 100 extended permit ip 192.168.10.0 255.255.255.0 192.168.0.0 255.255.255.0
access-list 110 extended permit ip 192.168.10.0 255.255.255.0 192.168.0.0 255.255.255.0

nat (inside) 0 access-list 100

crypto ipsec transform-set myset esp-des esp-md5-hmac

crypto map newmap 10 match address 110
crypto map newmap 10 set peer 1.2.3.4
crypto map newmap 10 set transform-set myset
crypto map newmap interface outside

crypto isakmp identity address
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption des
hash md5
group 1
lifetime 86400

tunnel-group 1.2.3.4 type ipsec-l2l
tunnel-group 1.2.3.4 ipsec-attributes
pre-shared-key $ecret

==========================================

Thanks for any ideas!!!

11 Replies 11

Craig Lorentzen
Cisco Employee
Cisco Employee

Hello Tan,

I understand you are having trouble with the new 8.3 "Simplified" NAT.  You will want to review the link below for an example which should answer your question.

https://supportforums.cisco.com/docs/DOC-11639

Please let us know if you still are having trouble after reviewing that document.

You may have issues with the setup though as overlaping networks can be problematic on the ASA.  I would try to seperate out the subnet(s) used on teh inside so that you do not overlap with the IPs you have on the remote side.

Regards,
Craig

I tried the following:

object network obj-local

     subnet 192.168.10.0 255.255.255.0

object network obj-remote

     subnet 192.168.0.0 255.255.255.0

nat (inside,outside) 1 source static obj-local obj-local destination static obj-remote obj-remote

no success.

Am I missing a route?

asa# show route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area

       * - candidate default, U - per-user static route, o - ODR

       P - periodic downloaded static route

Gateway of last resort is 192.168.2.1 to network 0.0.0.0

C    192.168.10.0 255.255.255.0 is directly connected, inside

C    192.168.2.0 255.255.255.0 is directly connected, outside

d*   0.0.0.0 0.0.0.0 [1/0] via 192.168.2.1, outside

asa#

hi,

The NAT config you have looks good. Are you having trouble reaching the remote site from your end? Could you run a packet-tracer and post the result here?

Cheers,

Prapanch

the sa never comes up.

I do not see any ISAKMP traffic at all in the traces

Hmmm.. Then we might have to look into the VPN config first.. Could you enable the following debugs on the ASA and send those across: "debug cry ias 127" and "debug cry ips 127"? Also, please post the output of "show cry isa sa" and "show cry ips sa"?

Cheers,

Prapanch

asa# show cry ips sa

There are no ipsec sas

asa# show crypto isakmp sa

There are no isakmp sas

asa#

Please enable the debugs mentioned above on the ASA and try generating some traffic through the tunnel. The debugs should give us an idea as to why the tunnel isn't coming up.

Cheers,

Prapanch

Trick: I had to run some traffic across the tunnel:

Jan 06 03:49:34 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0

Jan 06 03:49:34 [IKEv1]: IP = 1.2.3.4, IKE Initiator: New Phase 1, Intf inside, IKE Peer 1.2.3.4  local Proxy Address 192.168.10.0, remote Proxy Address 192.168.0.0,  Crypto map (newmap)

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, constructing ISAKMP SA payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, constructing NAT-Traversal VID ver 02 payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, constructing NAT-Traversal VID ver 03 payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, constructing NAT-Traversal VID ver RFC payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, constructing Fragmentation VID + extended capabilities payload

Jan 06 03:49:34 [IKEv1]: IP = 1.2.3.4, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 168

Jan 06 03:49:34 [IKEv1]: IP = 1.2.3.4, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 124

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, processing SA payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, Oakley proposal is acceptable

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, processing VID payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, Received NAT-Traversal ver 03 VID

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, processing VID payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, Received NAT-Traversal ver 02 VID

debug crypto isa 127Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, constructing ke payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, constructing nonce payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, constructing Cisco Unity VID payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, constructing xauth V6 VID payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, Send IOS VID

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, Constructing ASA spoofing IOS Vendor ID payload (version: 1.0.0, capabilities: 20000001)

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, constructing VID payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, Send Altiga/Cisco VPN3000/Cisco ASA GW VID

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, constructing NAT-Discovery payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, computing NAT Discovery hash

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, constructing NAT-Discovery payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, computing NAT Discovery hash

Jan 06 03:49:34 [IKEv1]: IP = 1.2.3.4, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NAT-D (130) + NAT-D (130) + NONE (0) total length : 264

Jan 06 03:49:34 [IKEv1]: IP = 1.2.3.4, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NAT-D (130) + NAT-D (130) + NONE (0) total length : 264

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, processing ke payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, processing ISA_KE payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, processing nonce payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, processing VID payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, Received xauth V6 VID

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, processing VID payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, Received DPD VID

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, processing VID payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, Received Cisco Unity client VID

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, processing VID payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, Processing IOS/PIX Vendor ID payload (version: 1.0.0, capabilities: 000000a5)

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, processing NAT-Discovery payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, computing NAT Discovery hash

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, processing NAT-Discovery payload

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, computing NAT Discovery hash

Jan 06 03:49:34 [IKEv1]: IP = 1.2.3.4, Connection landed on tunnel_group 1.2.3.4

Jan 06 03:49:34 [IKEv1 DEBUG]: Group = 1.2.3.4, IP = 1.2.3.4, Generating keys for Initiator...

Jan 06 03:49:34 [IKEv1 DEBUG]: Group = 1.2.3.4, IP = 1.2.3.4, constructing ID payload

Jan 06 03:49:34 [IKEv1 DEBUG]: Group = 1.2.3.4, IP = 1.2.3.4, constructing hash payload

Jan 06 03:49:34 [IKEv1 DEBUG]: Group = 1.2.3.4, IP = 1.2.3.4, Computing hash for ISAKMP

Jan 06 03:49:34 [IKEv1 DEBUG]: IP = 1.2.3.4, Constructing IOS keep alive payload: proposal=32767/32767 sec.

Jan 06 03:49:34 [IKEv1 DEBUG]: Group = 1.2.3.4, IP = 1.2.3.4, constructing dpd vid payload

Jan 06 03:49:34 [IKEv1]: IP = 1.2.3.4, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + ID (5) + HASH (8) + IOS KEEPALIVE (128) + VENDOR (13) + NONE (0) total length : 92

Jan 06 03:49:34 [IKEv1]: Group = 1.2.3.4, IP = 1.2.3.4, Automatic NAT Detection Status:     Remote end is NOT behind a NAT device     This   end is NOT behind a NAT device                                                 sh runJan 06 03:49:38 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0

Jan 06 03:49:38 [IKEv1]: Group = 1.2.3.4, IP = 1.2.3.4, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.

Jan 06 03:49:43 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0

Jan 06 03:49:43 [IKEv1]: Group = 1.2.3.4, IP = 1.2.3.4, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.

Jan 06 03:49:47 [IKEv1 DEBUG]: Pitcher: received a key acquire message, spi 0x0

Jan 06 03:49:47 [IKEv1]: Group = 1.2.3.4, IP = 1.2.3.4, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.

i also get this once in a while:

asa# show cry isakmp

   Active SA: 1

    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)

Total IKE SA: 1

1   IKE Peer: 1.2.3.4

    Type    : L2L             Role    : initiator

    Rekey   : no              State   : MM_WAIT_MSG6

Hi,

Based on the debugs, there aren't any NAT devices in between the 2 end points. Also, MM_WAIT_MSG6 implies there si some issues with the group-authentication using pre-shared key.

Could you confirm if the pre-shared-key is the same on both the ends? What device is on the other end of the VPN tunnel?

Thanks and Regards,

Prapanch

5505 but not sw v 8.3

It is possible my colleague used the wrong key.

I will keep you posted.

BTW. Your help is awesome.