Dynamic Policy NAT Help

licensing · ‎01-13-2014

Hello,

New to the Cisco world, so bear with me.

Overview

Site - Site VPN between a Remote office 172.16.10.1/24 and Main Office with inside IP 192.168.15.22. There is a 3rd Party router with inside IP 192.168.15.1 that has access to two subnets the Remote office needs access to. The Remote Office must have it's IPs NAT'd only when accessing the 3rd Party Network to a 192.168.15.150 address (or some other open IP obviously).

Here is what I am thinking right now, and there may be some syntax issues. This is on the Main Office ASA ver 7.2. Also, I need a route on the Remote office as well correct? I am routing to the inside interface of the Main office correct? Thank you so much.

object-group network REMOTE

network-object 172.16.10.0 255.255.255.0

object-group network 3RDPARTY

network-object 10.10.10.0 255.255.255.0

network-object 10.10.20.0 255.255.255.0

access-list VPN_policy_NAT permit ip object-group REMOTE object-group 3RDPARTY

global (inside) 10 192.168.14.150

nat (inside) 10 access-list VPN_policy_NAT

Jouni Forss · ‎01-14-2014

Hi,

So if I understood you correctly the setup is as follows

Remote site connected with L2L VPN to Main Site
Remote site with network 172.16.10.0/24
Main Site with 2 third party networks behind a router.
- 10.10.10.0/24
- 10.10.20.0/24
When Remote Site connects to third party networks at Main Site their traffic should be Dynamic PATed to a single IP address

If the above is true then I am not sure why this Dynamic Policy PAT would be done on the Main Site? The naturaly place for this would be on the Remote Site.

If you have an ASA on the Remote Site then you would be configuring Dynamic Policy PAT from "inside" to "outside".

access-list DYNAMIC-POLICY-PAT permit ip 172.16.10.0 255.255.255.0 10.10.10.0 255.255.255.0

access-list DYNAMIC-POLICY-PAT permit ip 172.16.10.0 255.255.255.0 10.10.20.0 255.255.255.0

global (outside) 200

nat (inside) 200 access-list DYNAMIC-POLICY-PAT

What you would also need to notice is that you naturally have to change the Crypto ACL in the "crypto map" configuration. You would have to add the as one of the source IP address for the L2L VPN connection.

Let me know if I understood your setup wrong

Hope this helps

- Jouni

licensing · ‎01-14-2014

Wonderful Jouni,

I will be testing that today and will get back to you by tonight. Your understanding of my setup is exactly right. I was told by another technician that I should perform the PAT on the Main Office ASA, hence why I am working there. Thank you so much, and as soon as I get word of how that'll work I will respond back.

licensing · ‎01-14-2014

It seems I'm still having troubles. Attached are all the config lines ive used to attempt to get this working

route outside 10.10.10.0 255.255.255.0 192.168.15.1 1
route outside 10.10.20.0 255.255.255.0 192.168.15.1 1

access-list DYNAMIC-POLICY-PAT permit ip 172.16.10.0 255.255.255.0 10.10.20.0 255.255.255.0
access-list DYNAMIC-POLICY-PAT permit ip 172.16.10.0 255.255.255.0 10.10.10.0 255.255.255.0

access-list outside_1_cryptomap extended permit ip 192.168.15.149 255.255.255.255 VPN-Remote 255.255.255.0

global (outside) 200 192.168.15.149
nat (inside) 200 access-list DYNAMIC-POLICY-PAT

Everything looks right. When I run a packet-tracer from 172.16.10.X to one of the remote 3rd party IPs, its allowed the entire way, I see the NAT rule being applied and being translated from a 172.16.10.X to 192.168.15.149 just fine. I also see the 192.168.15.149 being allowed through the VPN tunnel when I run show crypto ipsec sa so it should be allow over the VPN.

Am I missing something entirely? I haven't done anything on the Main Office ASA, I don't think I need to allow anything as it's a 192.168.15.0 address going through the tunnel, which is already allowed through the crypto map config.

Jouni Forss · ‎01-15-2014

Hi,

Actually now I understand why you were possibly told that this should be done at Main Office.

Its because of your NAT IP address used. This is an IP address beloging directly to the Main Office ASA interface. Therefore this traffic at the moment probably wont ever be forwarded to the VPN connection atleast in the direction Main Office -> Remote Office since the 3rd party Router will try to ARP for the MAC address of the host 192.168.15.149 as it thinks that its connected directly to that network. And as there is no NAT/PAT at the moment on the Main Site for that IP address the ASA wont answer that ARP request.

This kind of makes me think that the situation originally has been so that changes can't be made to the 3rd party router and thats why you are trying to PAT the Remote Site to an IP address that the 3rd party router already has a route for (directly connected)

So next there are these questions

What is the 3rd party router using as default gateway?

Could an IP address from some new subnet be used as the Dynamic PAT IP address for the Remote Site users? This comes back to the above question as to what is the default gateway of the 3rd party router? If its not your ASA then a route for the new Dynamic PAT IP address (configured on Remote Site) would have to configured on the 3rd party router pointing it towards the ASA.

Hope this helps

- Jouni

licensing · ‎01-15-2014

The router for the 3rd Party Network at the main office is in the route statements above, 192.168.15.1

Could I do

access-list DYNAMIC-POLICY_PAT .....

global (inside) 200 192.168.15.49

nat (outside) 200 access-list DYNAMIC_POLICY_PAT

on the Main office ASA?

The 3rd Party basically won't do anything for us in way of their configuration. They will only allow the Main Office subnet, none others, and won't make a route back to the 172.16.10.0 network, hence why I am stuck in this predicament. If they would just route back to the Remote office, I wouldn't be on here trying to find a convuluted solution.

Jouni Forss · ‎01-15-2014

Hi,

I think it might work. To be honest I have never done such a setup since we simply dont accept that a situation where a 3rd party would dictate us to make these kind of unusual setups just because they can't be bothered to make changes to their devices (which are pretty simple)

What you will probably need in that "nat" command is the parameter "outside" in the end of the command. This is because you are doing Dynamic PAT from a lower "security-level" interface to a higher one.

Check this section from ASA Command Reference

http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/no.html#wp1756533

Quote

 For policy dynamic NAT and NAT exemption: 

nat (real_ifc) nat_id access-list access_list_name [dns] [outside] [[tcp] tcp_max_conns [emb_limit]] [udp udp_max_conns] [norandomseq] 




 outside 


 (Optional) If this interface is on a lower security level than the interface you identify by the matching global statement, then you must enter outside. This feature is called outside NAT or bidirectional NAT.

Again, this is not something I have done other than to test it in some labs so I am not 100% sure how it acts with the other NAT configurations. I can't see a problem at the moment atleast since its specifically made to be a Policy type of NAT.

To my understanding this Dynamic Policy PAT should work as the ASA the ASA should do NAT operations before sending traffic towards the Remote Site (would untranslate the PAT to the real IP address before VPN rules matched) and when traffic is coming from the L2L VPN towards Main Office I would imagine that when the packet is decapsulated/decrypted it would then be PATed to the correct IP address.

- Jouni