ASA 8.2(1) Global and NAT statements, natting certain internal hosts

[Scott Conklin]

Hi, I have what I believe will be an easy question, but I cannot find the answer and cannot afford to test it on our production ASA.

I am running an ASA firewall, we are performing PAT with one Public IP Address for all inside traffic accessing the Internet.  We need to implement a solution where whenever two or three internal hosts/servers access the Internet, they need to appear to come from a unique public IP, different than the current Global IP for all other internal traffic.  I understand I could Nat thier Internal IP Address to a public IP, but I don't need each server to have it's own public IP, I'd like for all of them to share one.

Thoughts on how to accomplish this?  Thanks!

[Jouni Forss]

Hi,

To my understanding you would just create a new Dynamic PAT configuration using different NAT ID for these hosts.

Though when you create a separate Dynamic PAT for some hosts with a new NAT ID you will have to make sure that this NAT ID has a rule towards any interface they had before.

In a very basic setup there should only be Dynamic PAT between your "inside" and "outside" interfaces (presumed thats what they are called on your firewall)

This would mean that if you had for example a network 10.10.10.0/24 and you performed Dynamic PAT for that network using the "outside" interface IP address you would then configure the following

global (outside) 1 interface

nat (inside) 1 10.10.10.0 255.255.255.0

So the above is probably the type of configuration you have at the moment?

For the 2/3 hosts you have that need a different PAT IP address you could probably configure something like this (1.1.1.1 is just an example IP instead of the actual public IP address that is different from the interface IP address)

global (outside) 2 1.1.1.1

nat (inside) 2 10.10.10.1

nat (inside) 2 10.10.10.2

nat (inside) 2 10.10.10.3

If the original ID 1 NAT rule had "global" statements for some other interface then you would most likely need ID 2 configurations for those too. Though generally Dynamic PAT is only performed towards other external networks which usually means only the "outside" interface.

Without seeing the configurations I dont think I can say much more.

Naturally "packet-tracer" is an excellent command to confirm what what NAT/PAT is applied for a hosts connection.

For example if you wanted to test host 10.10.10.1 applied ASA configurations/rules towards some external hosts you could issue this command

packet-tracer input inside udp 10.10.10.1 12345 8.8.8.8 53

This should tell you what NAT translation is performed for this traffic (it simulates a destination port UDP/53 connection towards 8.8.8.8). Naturally you can also confirm things through firewall logs and the translation table of the device.

Active translations on the firewall you can show with the command

show xlate

It does have a lot of additional parameters after the "xlate" if you want to have more specific output

Hope this helps

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

Feel free to ask more if needed

- Jouni

[Scott Conklin]

Thanks for the reply.

Our current Dynamic PAT config is as follows:

global (outside) 1 x.x.x.120

nat (inside) 1 access-list Inside-out

The Inside-out ACL entries consists of our internal network 10.x.0.0/16 as the source IP, and allows only certain services out- HTTP, HTTPS, FTP, SSH, etc.

I tried exactly what you wrote with the nat (inside) 2 and global (outside) 2 using a few test laptops here as follows:

global (outside) 2 x.x.x.132

nat (inside) 2 10.x.x.156 255.255.255.255 (this is the IP of a test machine I am using, I did have to specify the netmask 255.255.255.255 as the ASA gave me  an inconsistent netmaks error).

Unfortunately, the test machine is still getting translated to the Global 1 outside IP x.x.x.120, I am assuming because the traffic hits that access-list/NAT 1 statement first. 

I ran the packet tracer command (thanks for the suggestion), here are the NAT results-

Phase: 9

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (inside) 1 access-list Inside-out

  match tcp inside 10.x.0.0 255.255.0.0 outside any eq 80

    dynamic translation to pool 1 (x.x.x.120)

    translate_hits = 70428650, untranslate_hits = 3103829

Additional Information:

Dynamic translate 10.x.x.156/7777 to x.x.x.120/41529 using netmask 255.255.255.255

Any other ideas?  Or am i going to have to do a Static (Inside,Outside) command and waste some of our public IP Addresses?

[Jouni Forss · Accepted solution]

Ah,

I totally forgot to add the host network mask at the end of the "nat" statement.

The problem with the translation is that your current NAT configuration for users is NOT Dynamic PAT. Its Dynamic Policy PAT. Dynamic Policy PAT is processed before Dynamic PAT.

Refer to this section of the Configuration Guide for a clearer description of the order of NAT configurations

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/nat_overview.html#wp1079279

The above fact will make it harder for you to create the Dynamic PAT rule for the other specific hosts. Normally you would configure normal Dynamic PAT for users and use interface ACL to control the services, not the NAT.

What you essentially can do in this situation is either

• Remove the current Dynamic Policy PAT and change it to normal Dynamic PAT and control the services with interface ACLs and then configure the more specific Dynamic PAT with another ID number for the few hosts
• Remove the current Dynamic Policy PAT and configure a Dynamic Policy PAT for the few hosts and then reconfigure the original Dynamic Policy PAT

Atleast this is what Cisco seems to suggest. I mean that the order of the Policy NAT/PAT rules defines which will be applied and since you have an existing Dynamic Policy PAT for these hosts then the new Dynamic Policy PAT would not apply since it would be entered after the original one, though naturally you can test this with the test source IP addresses.

Both of the above options will essentially mean that any host using the Dynamic Policy PAT to be removed will have their translations tore down and remove their connections. Atleast to my understanding this will happen. So you are looking at some kind of small cut for user connections while doing the configuration change.

As I said, the problem is caused by the fact that your Dynamic PAT rule confired for all users is a Dynamic Policy PAT and the Dynamic PAT wont be processed before it.

- Jouni

[Scott Conklin]

Everything that you said is exactly what I suspected.  Thanks for your assistance with this, I'm going to have to decide which way we want to go.