PAT incoming over VPN

[Mokhalil82]

Hi

I have a scenario where I am setting up a site to site VPN with a 3rd party that needs access to our servers. However their internal IP conflicts with an internal subnet on our side. Therefore I asked them to PAT their internal before it comes over the VPN but they advised their Meraki does not support this to another make of firewall.

Therefore I want to PAT their traffic as it hits our end. Will this config work if their internal subnet is 192.168.10.0/24

object network 3RD_PARTY
subnet 192.168.10.0 255.255.255.0
nat (outside, inside) dynamic 192.168.100.1

[Bogdan Nita]

Yes, your PAT config should work.

[Florin Barhala]

Interesting one; how did you defined the ACL_encryption domain: your_local_network as source toward 192.168.100.1/32 as destination?

[Bogdan Nita]

Good point Florin.

The crypto acl should look something like this:

access-list encrypt_acl line 1 extended permit ip <local network> <mask> 192.168.1.0 255.255.255.0

Traffic going over the vpn tunnel stills needs to be done with the original IPs.

[Florin Barhala]

Why did you use 192.168.1.0/24 as dst_network?

[Bogdan Nita]

Sorry, I missed a 0 dst should have been 192.168.10.0/24.

[Florin Barhala]

I am still at a loss.

Let's say I have 192.168.10.0/24 behind my firewall (in regard to the routing table info) and also the customer uses same network.

Business request is to have connectivity between a local segment I am using: 10.100.100.0/24 and 192.168.10.0/24 (at the customer end) can I use VPN_encryption_ACL permit  ip 10.100.100.0/24 192.168.10.0/24 ?

Obviously routing will be considered and since FW routing says: route inside 10.0.0.0/8 , how will the packet get encrypted over outside?

Thanks!

[Bogdan Nita]

Return packets will have as destination IP the NAT IP used by ASA. (192.168.100.1 in this example)
In this case route lookup will pass, then it will check pre-existing xlate and find a match, nat the packet and then encrypt it.

[Florin Barhala]

I agree with this. But what happens if the traffic will be started/initiated from "our side". From the firewall that has route inside 10.0.0.0/8; how will the packet get encrypted over outside?

[Bogdan Nita]

In the initial example, because it is a PAT, traffic initiated from the internal network will not be forwarded, but if we change the rule to something like this:

object network obj_192.168.10.10
 host 192.168.10.10
 nat (outside, inside) static 192.168.100.10

a packet coming from inside and with a destination IP: 192.168.100.10 will be first nated (in this case actually un-nat) and because the nat has the interfaces specified it will divert the packet to the outside interface without doing a route lookup. 

[Mokhalil82]

No, the destination I will be using on the crypto ACL is the original destination of 192.168.10.0/24. The connection is only required to be sourced from the 3rd party therefore once their traffic hits our firewalls, it will be natted to 192.168.100.1. So the return traffic will have a destination of 192.168.100.1 and will get natted at our firewall

[Akbar ali Sultan]

if that doesn't work you need to configure Destination NAT. destination Nat use very rarely conflict the IP is one of the case. here are the syntax,

1. write the object for all involved addresses.

2. Create the destination nat also called twice NAT or Manual NAT