I have the following scenario:-
Net A - 172.20.82.0/24 (under my control) network
Net B - Public (out of my control) network
I have a bunch of servers on the Net A (172.20.82.0/24) 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.
access-list NET_A_PAT permit 172.20.82.0 255.255.255.0 NET_B_NETWORK NET_B_NETMASK
nat (inside) 20 access-list NET_A_PAT
global (outside) 20 MY_PUBLIC_PAT
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.
Solved! Go to Solution.
Hi Jennifer, thanks for the reply. So basically if I'm using fictitious Public IP's it looks like the following:-
Net A (172.20.82.0/24)
Net A ---> NET_A_PAT ACL (172.20.82.0/24 -> 22.214.171.124/32) ---> CRYPTO_MAP ACL ---> FW_OUTSIDE_IP (126.96.36.199/32 -> 188.8.131.52/32) = VPN transmission?
Many thanks again for your help.
...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.
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.
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:-
Source: Cisco_ASA_PAT (not transmission interface)
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?
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.
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.
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.