Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

NAT before VPN - ASA 8.3 L2L???

Answered Question
Jul 10th, 2012
User Badges:

Hi there,

I have the following scenario:-

Net A - (under my control) network

Net B - Public (out of my control) network

I have a bunch of servers on the Net A ( network I'd like to PAT behind a Public IP before transmission over a VPN to the remote (Net B) site. In quickly doing some reading thus far, my understanding is that I'll need to:-

a) Perform an "inside/outside" PAT on Net A "interesting traffic" to my PAT Public address before I then...

b) Apply the new Public PAT address to both the crypto and "NAT 0" ACL's.




nat (inside) 20 access-list NET_A_PAT

global (outside) 20 MY_PUBLIC_PAT

then b)

access-list NO_NAT extended permit ip host MY_PUBLIC_PAT NET_B_NETWORK NET_B_NETMASK

access-list CRYPTO_MAP extended permit ip host MY_PUBLIC_PAT NET_B_NETWORK NET_B_NETMASK

First question is - is this right? I believe it is, but am just wanting clarification.

Second question is - I also run a "standard" PAT on the "outside" (Internet) interface of the ASA for normal internet traffic - browsing etc. If I am performing an inside/outside PAT as above, will that not then try and transmit the encrypted packets using my "new" PAT instead of the interface IP to the remote VPN endpoint? Or does the crypto process take my first PAT then re-encapsulate it using the "real" outside interface IP PAT?

Hope I'm reasonably clear - many thanks in advance.

Correct Answer by Jennifer Halim about 5 years 1 month ago

a) Correct

b) Partly correct, the crypto ACL is correct, however, you don't need NAT 0 ACL as you are doing a PAT.

Second question - no, PAT comes first, then it will encrypt the packet with the interface IP which is the VPN termination point.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Correct Answer
Jennifer Halim Tue, 07/10/2012 - 05:51
User Badges:
  • Cisco Employee,

a) Correct

b) Partly correct, the crypto ACL is correct, however, you don't need NAT 0 ACL as you are doing a PAT.

Second question - no, PAT comes first, then it will encrypt the packet with the interface IP which is the VPN termination point.

damianbell Tue, 07/10/2012 - 06:50
User Badges:

Hi Jennifer, thanks for the reply. So basically if I'm using fictitious Public IP's it looks like the following:-

Net A (



Net A ---> NET_A_PAT ACL ( -> ---> CRYPTO_MAP ACL ---> FW_OUTSIDE_IP ( -> = VPN transmission?

Many thanks again for your help.

Jennifer Halim Tue, 07/10/2012 - 07:50
User Badges:
  • Cisco Employee,

Cheers, pls kindly mark the post as answered so others can learn from your question. Thank you.

damianbell Wed, 07/25/2012 - 04:58
User Badges:

Hi Jennifer,

...trust you're well. So I rolled in this config last night, but unfortunately it appears that it didn't work. I'm getting a phase 1 and 2 completion OK, however the remote end (Checkpoint) is coming back and saying that there's an issue with locating and routing to the correct PAT peer at my end.

The issue (according to the firewall consultant that I spoke to) is that as I am using a /32 public IP for my PAT that's in the same range as the /24 public range of the outside interface of the ASA (the VPN tunnel endpoint), the ASA is trying to arp for the /32 PAT on the outside interface and as such isn't routing the packet "internally" correctly. Apparently this guy has seen this issue with ASA's before.

Is this something you've seen yourself? Might you have a suggestion as to a workaround?

One option I thought about was potentially removing the unique PAT for this specific VPN completely, and quite simply let everything PAT behind the public interface IP (as per the rest of my regular internet traffic), but I'm unsure whether the ASA will support me defining my encryption domain as the public interface of the firewall, along with the same /32 IP acting as the tunnel endpoint. Is this a feasible solution?

Many thanks (again) in advance.


Jennifer Halim Wed, 07/25/2012 - 09:08
User Badges:
  • Cisco Employee,

If you are configuring PAT, the traffic needs to be initiated from your end as PAT just uses 1 ip address, so the CheckPoint end can't initiate the connection towards the PAT address.

If you configure PAT, the ASA will definitely ARP for that public IP Address on the outside interface. But for PAT, connection needs to be initiated from inside to outside as it doesn't work the other way round. If you need to initiate traffic from outside to inside, then you would need to configure static NAT.

What you have configured is already correct, just the usage is incorrect, ie: you would need to initiate the connection from inside to outside, not the other way round.

damianbell Wed, 07/25/2012 - 09:31
User Badges:

The traffic is definitely being initiated from my end - the process is basically that the remote end is seeing a SYN coming from my Host A, is replying with a SYN ACK from his Host B. At this point he's saying it's being dropped with the following error:-

Date:                           24Jul2012

Time:                           16:50:29

Type:                           Log

Action:                         Drop

Protocol:                       tcp

Service:                        tcp.xxxx

Source:                         Cisco_ASA_PAT (not transmission interface)

Destination:                   DESTINATION_PUBLIC_IP

Source Port:                    51695

Encryption Scheme:              IKE

VPN Peer Gateway:               CISCO_ASA_OUTSIDE_INTERFACE

Encryption Methods:             ESP: AES-256 + SHA1 + PFS

Information:                    service_id: tcp.xxxx

                               encryption failure: Cannot identify peer for encrypted connection (VPN Error code 04)

Might the suggestion I've made above be of use?



Jennifer Halim Thu, 07/26/2012 - 09:47
User Badges:
  • Cisco Employee,

Can you please share the output of:

show cry ipsec sa peer

Also, what did the remote end configured for the crypto ACL. It needs to mirror image.

damianbell Thu, 07/26/2012 - 09:53
User Badges:

Hi - output sent again via PM, and the remote end has definitely got the exact same configuration. Their encryption domain is only configured as my PAT address, and I've verified P1 and P2 settings with them end to end.

Jennifer Halim Thu, 07/26/2012 - 10:04
User Badges:
  • Cisco Employee,

The error message is suggesting that it can't identify which peer to send the traffic to at their end.

They need to check why is the case. I would triple check again that they have configured remote encryption domain as your PAT address, and the local encryption domain should be just the 3 ip addresses listed in your object-group.


This Discussion