07-10-2012 04:24 AM
Hi there,
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.
i.e.
a)
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
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.
Solved! Go to Solution.
07-10-2012 05:51 AM
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.
07-10-2012 05:51 AM
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.
07-10-2012 06:50 AM
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)
MY_PUBLIC_PAT (1.1.1.1/32)
FW_OUTSIDE_IP (1.1.1.2/32)
Net A ---> NET_A_PAT ACL (172.20.82.0/24 -> 1.1.1.1/32) ---> CRYPTO_MAP ACL ---> FW_OUTSIDE_IP (1.1.1.1/32 -> 1.1.1.2/32) = VPN transmission?
Many thanks again for your help.
07-10-2012 06:53 AM
Absolutely correct.
07-10-2012 07:39 AM
Nice one Jennifer - cheers!
07-10-2012 07:50 AM
Cheers, pls kindly mark the post as answered so others can learn from your question. Thank you.
07-25-2012 04:58 AM
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.
Damian
07-25-2012 09:08 AM
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.
07-25-2012 09:31 AM
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?
Thanks
Damian
07-25-2012 09:40 AM
Can you please share your config. thx.
07-26-2012 06:36 AM
Sent to you via PM.
07-26-2012 09:47 AM
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.
07-26-2012 09:53 AM
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.
07-26-2012 10:04 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide