One Global Address Shared by Both Regular and Policy Dynamic NAT in ASA (pre-8.3)?

[david.kreindler]

In a pre-8.3 ASA, is it possible for both regular dynamic NAT and policy dynamic NAT to share a single global address?

I see two configuration possibilities, but I am not sure if either of them would work.

1. Two nat statements share an ID and therefore a single global statement:

global (outside) 10 PAT_address

nat (inside) 10 10.0.0.0 255.0.0.0

nat (inside) 10 access-list ACL_name

2. Two different global statements share a single PAT address:

global (outside) 10 PAT_Address_10

global (outside) 20 PAT_Address_10

If neither possibility works, is the correct solution (to the problem of sharing a single PAT address) to add the local source subnet and use a destination of "any" in the policy NAT ACL, to simulate regular dynamic NAT in policy dynamic NAT? What if there is regular dynamic NAT in place for a subnet of the same local subnet -- doesn't switching from regular dynamic NAT, which is best-match, to policy dynamic NAT, which is first-match, mess up the precedence?

[Jouni Forss]

Hi,

If you are translating all to a single public IP address why would you need to configure both Dynamic PAT and Dynamic Policy PAT?

What are you trying to achieve with this?

- Jouni

[david.kreindler]

We have a few internal public addresses that need to be translated to the same external public address that our internal private addresses are, by default, translated to.

[Jouni Forss]

Hi,

Should this translation from the Internal Public to External Public happen whatever the destination IP address is or do you want to use Dynamic Policy PAT specifically for the reason to limit this behaviour only to certain destination networks/hosts?

If you just simply want to do Dynamic PAT for both the Internal Private and Internal Public IP addresses then you would use

global (outside) 1 interface

nat (inside) 1 10.0.0.0 255.0.0.0

nat (inside) 1 1.1.1.1 255.255.255.255

nat (inside) 1 2.2.2.2 255.255.255.255

nat (inside) 1 3.3.3.3 255.255.255.255

or

global (outside) 1

nat (inside) 1 10.0.0.0 255.0.0.0

nat (inside) 1 1.1.1.1 255.255.255.255

nat (inside) 1 2.2.2.2 255.255.255.255

nat (inside) 1 3.3.3.3 255.255.255.255

If you wanted to only do Dynamic PAT for the Internal Public IP addresses to certain destination networks then I would presume that this format would do the job

access-list INTERNAL-PUBLIC-PAT remark Condition for Dynamic PAT

access-list INTERNAL-PUBLIC-PAT permit ip host 1.1.1.1 4.4.4.0 255.255.255.0

access-list INTERNAL-PUBLIC-PAT permit ip host 2.2.2.2 4.4.4.0 255.255.255.0

access-list INTERNAL-PUBLIC-PAT permit ip host 3.3.3.3 4.4.4.0 255.255.255.0

global (outside) 1

nat (inside) 1 10.0.0.0 255.0.0.0

nat (inside) 1 access-list INTERNAL-PUBLIC-PAT

To my understanding in the above configuration everything in the network 10.0.0.0/8 should match this Dynamic PAT configuration unless there is a Static NAT / Static PAT / NAT0 / Identity NAT / Policy NAT/PAT configuration

The Dynamic Policy PAT should also only apply to the Internal Public source addresses when the destination network is 4.4.4.0/24. For all other destination addresses the Internal Public should not match any NAT configuration and go through without NAT. This naturally depends on your "nat-control" setting also.

Hopefully I have not remembered wrong something since I am already getting a bit rusty with the older format as we have updated almost all of our ASA platforms and migrated away from FWSM/PIXs

Hope this helps

- Jouni

[david.kreindler]

So you are endorsing my option #1 (policy and regular dynamic NAT sharing a single global ID)?

[Jouni Forss]

Hi,

It depends if you are trying to Dynamic PAT the Internal Public IP addresses only when they are connecting specific external public IP addressses.

If the Interna Public IP addresses should ALWAYS be translated to the same IP address as the Internal Private IP addresses when connecting to external networks then there is no real need to configure Dynamic Policy PAT usually

Unless there is some other interfaces on the firewall towards which this normal Dynamic PAT would cause problems. The most usual being the situation where the source address matches a "nat" statement but doesnt have a "global" statement towards some other firewall interface which would start then dropping the traffic. (other NAT configuration could be used to overcome this)

- Jouni

[david.kreindler]

Yes, we need policy NAT of the local public addresses in addition to the default regular dynamic NAT of the local private addresses.

[Jouni Forss]

Hi,

So if you need the Internal Public IP addresses translation to be conditional based on the destination network/address then I guess you can use the configuration format mentioned.

I mean a single PAT IP address configured with "global" command and "nat" command for both Internal Private and Internal Public

access-list INTERNAL-PUBLIC-PAT remark Condition for Dynamic PAT

access-list INTERNAL-PUBLIC-PAT permit ip host 1.1.1.1 4.4.4.0 255.255.255.0

access-list INTERNAL-PUBLIC-PAT permit ip host 2.2.2.2 4.4.4.0 255.255.255.0

access-list INTERNAL-PUBLIC-PAT permit ip host 3.3.3.3 4.4.4.0 255.255.255.0

global (outside) 1

nat (inside) 1 10.0.0.0 255.0.0.0

nat (inside) 1 access-list INTERNAL-PUBLIC-PAT

- Jouni

[Jouni Forss]

Also,

Unless you have a very old software (7.0 or something like that) you can use the "packet-tracer" command to confirm the NAT behaviour. You can see what happens to the Internal Public IP addresses according to the tests.

Please let me know if it works for you or if there is any problems.

Please do remember to mark a reply as the correct answer if it answered your question.

Feel free to ask more if needed

- Jouni

[david.kreindler]

I would really like a proposed solution that is not speculative. I do not have the option of breaking the existing regular dynamic NAT while trying to add the policy dynamic NAT. Have you actually configured both regular dynamic NAT and policy dynamic NAT to use the same global statement successfully?

[Jouni Forss]

Hi,

Part of the problem is that I dont like saying a solution is 100% sure especially when I have not seen the actual configuration of the device where its supposed to be applied. Its impossible to take into consideration everything.

As I said before, we have moved away from the older software format so I dont deal with this day to day anymore. I use the new NAT format and know its operation better.

I have configured plenty of different type of NATs as we manage around 350 Cisco firewalls (virtual and physical firewalls) and have done this almost for 6 years now. Naturally everyone makes mistakes

To demonstrate the Dynamic PAT + Dynamic Policy PAT I booted my own ASA5505 back to 8.2(5) and did the following configuration

access-list DYNAMIC-POLICY-PAT extended permit ip host 1.1.1.1 host 8.8.8.8

global (WAN) 1 interface

nat (LAN) 1 access-list DYNAMIC-POLICY-PAT

nat (LAN) 1 10.0.0.0 255.255.255.0

The IP address 1.1.1.1 is located behind my ASA firewall in a Cisco routers loopback interface. The ping for the specified destination address works just fine

Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 48/49/52 ms

The "packet-tracer" command also tells us what happens with regards to NAT depending on what the source/destination IP address of the connection is.

The IP address x.x.x.x is my public interface WAN IP address

10.0.0.100 LAN to 8.8.8.8 WAN

packet-tracer input LAN icmp 10.0.0.100 8 0 8.8.8.8

Phase: 7

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (LAN) 1 10.0.0.0 255.255.255.0

  match ip LAN 10.0.0.0 255.255.255.0 WAN any

    dynamic translation to pool 1 (x.x.x.x [Interface PAT])

    translate_hits = 868, untranslate_hits = 49

Additional Information:

Dynamic translate 10.0.0.100/0 to x.x.x.x/3826 using netmask 255.255.255.255

1.1.1.1 LAN to 8.8.8.8 WAN

packet-tracer input LAN icmp 1.1.1.1 8 0 8.8.8.8

Phase: 6

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (LAN) 1 access-list DYNAMIC-POLICY-PAT

  match ip LAN host 1.1.1.1 WAN host 8.8.8.8

    dynamic translation to pool 1 (x.x.x.x [Interface PAT])

    translate_hits = 2, untranslate_hits = 0

Additional Information:

Dynamic translate 1.1.1.1/0 to x.x.x.x/30795 using netmask 255.255.255.255

1.1.1.1 LAN to 8.8.4.4 WAN

packet-tracer input LAN icmp 1.1.1.1 8 0 8.8.4.4

Phase: 6

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

nat (LAN) 1 access-list DYNAMIC-POLICY-PAT

  match ip LAN host 1.1.1.1 LAN host 8.8.8.8

    dynamic translation to pool 1 (No matching global)

    translate_hits = 0, untranslate_hits = 0

Additional Information:

Result:

input-interface: LAN

input-status: up

input-line-status: up

output-interface: WAN

output-status: up

output-line-status: up

Action: allow

As we can see the traffic doesnt match the NAT rule but is passed along by the ASA according to its other checks.

A Telnet from the Loopback to the same destination address also shows that no translation is done on the ASA for the source IP address and that the connection indeed is allowed through the ASA

ASA# sh conn long address 1.1.1.1

TCP WAN:8.8.4.4/23 (8.8.4.4/23) LAN:1.1.1.1/32450 (1.1.1.1/32450), flags saA, idle 0s, uptime 0s, timeout 30s, bytes 0

LAN-ROUTER#telnet 8.8.4.4 /source-interface loopback 1

Trying 8.8.4.4 ...

% Connection timed out; remote host not responding

Naturally the connection fails because the connection goes through without NAT with the source IP address of 1.1.1.1

Hope this clarifies things

- Jouni

[Jouni Forss]

Hi,

Did you have the chance to test your configurations?

- Jouni

[david.kreindler]

No, I realized that we have a static identity NAT statement that would override the change, due to ASA NAT precedence.