Web server: In Static NAT with PAT (Out with dynamic PAT) 8.2->8.3+

[will]

so in the "old" 8.2 ASA OS, I wanted something like this:

static nat a few ports inbound for web and email traffic to an inside server (using outside IP2)

allow this inside server (and all the other DMZ servers) to browse the internet with a global PAT (using outside IP1)

8.2 Configuration:

static (DMZ,INTERNET) tcp OUTSIDEIP2 smtp DMZIP smtp netmask 255.255.255.255
static (DMZ,INTERNET) tcp OUTSIDEIP2 www DMZIP www netmask 255.255.255.255
static (DMZ,INTERNET) tcp OUTSIDEIP2 https DMZIP https netmask 255.255.255.255

!

global (INTERNET) 1 OUTSIDEIP1 netmask 255.255.255.255
nat (DMZ) 1 192.168.0.0 255.255.255.0

I'm blowing smoke out my ears because ASA looks like it now has some built-in (lack of intelligence), which is prevented this configuration in 9.1 OS:

9.1 Configuration:

nat (INTERNET,DMZ) source static any any destination static OUTSIDEIP2 INSIDEIP service s80 s80 unidirectional no-proxy-arp

nat (INTERNET,DMZ) source static any any destination static OUTSIDEIP2 INSIDEIP service s443 s443 unidirectional no-proxy-arp
WARNING: mapped-address 0.0.0.0/1024-65535 overlaps with existing static NAT in Section 1, rule 12.

nat (INTERNET,DMZ) source static any any destination static OUTSIDEIP2 INSIDEIP service s25 s25 unidirectional no-proxy-arp
WARNING: mapped-address 0.0.0.0/1024-65535 overlaps with existing static NAT in Section 1, rule 12.

nat (DMZ,INTERNET) source dynamic SN_DMZ OUTSIDEIP1 description DMZ->internet

I think its trying to tell me: Don't be stupid because you may have 2 web clients using the same source port (i.e. 1024) to browse to 80 and 443 sessions at the same time. Apparently, the ASA will flip out now because of this? it would have to open two sockets with the same source port? shouldn't the NAT translation table take into account the source/dest pair (1024,80) and (1024,443) and be able to handle this? Even if tis from the same client, the client couldn't conceivably make two requests to 80 and 443 from the same source port. NOTE: rule 12 is the s80 first NAT line configuration.

What is the best way to deal with this type of scenario? NOTE: I may be shooting myself in the foot, but I really don't like the object based NAT's. I would rather specify them in section1 (top portion) of the ASDM NAT GUI. or with command such as above. Maybe I cannot get what I want?

thx in advance,

Will

[Jouni Forss]

Hi,

I would suggest that you use a different type of NAT configuration to achieve the same configuration you had previously.

In that situation I would suggest Auto NAT / Network Object NAT for the Static PAT (Port Forward) translations and Manual NAT (Section 3) for the Dynamic PAT

So if I were to convert your above 8.2 configurations they would look something like this

STATIC PAT

As you can see below we create an "object" for each of the NAT configurations. The object itself contains the real IP address and also the "nat" command that does the actual translation. So only need one "object" configuration for each Static PAT configuration. To my knowledge there is not really good ways to handle situation with multiple ports that need to be forwarded to the same host ( I mean handling them in a single command)

You can naturally use any object name you want.  In the section <public ip> you could use the keyword "interface" if you were using the actual "INTERNET" interface IP address. In other situations you naturally use the actual public IP address.

object network STATIC-PAT-TCP25
 host <internal ip>
 nat (DMZ,INTERNET) static <public ip> service tcp 25 25

object network STATIC-PAT-TCP80
 host <internal ip>
 nat (DMZ,INTERNET) static <public ip> service tcp 80 80

object network STATIC-PAT-TCP443
 host <internal ip>
 nat (DMZ,INTERNET) static <public ip> service tcp 443 443

Dynamic PAT

Below are 2 examples how to handle the Dynamic PAT. The first ones is a simple configuration that accepts all (any) source addresses for the translation. The other example uses an "object-group" to define the source addresses/subnets/networks for which the translations will be performed by this "nat" configurations.

Notice that since we are talking about Manual NAT configurations that NO "nat" configuration is located under an object. All the "object" and "object-group" mentioned below are only configured to be used in the actual "nat" command to tell the ASA the addresses involved in the translation.

object network PAT-IP
 host <public pat ip>

nat (DMZ,INTERNET) after-auto source dynamic any PAT-IP

or

object-group network DMZ-PAT-SOURCE
 network-object 192.168.0.0 255.255.255.0

nat (DMZ,INTERNET) after-auto source dynamic DMZ-PAT-SOURCE PAT-IP

I would also like to mention that the above configurations will work on a blank ASA. In a production environment its possible that some existing NAT configurations might conflict with these. What I mean bu this is that there might be some Manual NAT configurations (Section 1) that will be applied first always compared to my examples (which are Section 2 and Section 3) since they are of lower priority that defined by how they were configured.

You might also ask what makes my Dynamic PAT configurations Section 3 and your examples Section 1 even though they are both Manual NAT type configurations. The key thing there is that I have added the "after-auto" parameter which tells the ASA its of the lowest priority (Section 3). The "after-auto" refers to the fact that this rule should come after the Auto NAT / Network Object NAT section of the configurations (Section 2)  and in this examples the Static PAT configurations were Section 2.

Hope I made any sense and hope it helps :) Feel free to ask more if needed

Below is a link to a document I wrote in 2013 that might provide some basic information about configuring the new NAT 8.3+

https://supportforums.cisco.com/document/132066/asa-nat-83-nat-operation-and-configuration-format-cli

- Jouni

[Jouni Forss · Accepted solution]

Hi,

I guess if you want to use the Manual NAT for Static NAT and Static PAT configurations you could use the following configuration format

object service REAL-PORT
 service tcp source eq <port>

object service MAPPED-PORT
 service tcp source eq <port>

object network REAL-ADDRESS
 host <real ip>

object network MAPPED-ADDRESS
 host <mapped ip/public ip>

nat (DMZ,INTERNET) source static REAL-ADDRESS MAPPED-ADDRESS service REAL-PORT MAPPED-PORT

Even though its still relatively simple configuration I personally prefer the Auto NAT / Network Object NAT. My personal reasons are that I have to create less objects to clutter the CLI configuration and I can also section different type of NAT configurations using the actual Sections of ASA.

My personal preference is

• Section 1 = NAT0 and Policy Based NAT configurations if needed
• Section 2  = Static NAT and Static PAT
• Section 3 = All Dynamic NAT/PAT configurations and possibly all the Dynamic Policy NAT/PAT configurations (With combined normal and policy NAT/PAT have to take care with the ordering of the rules inside this section as the "nat" command have their own line number like ACLs.)

- Jouni

[will]

thx for reply! it was very enlightening. and it helps. there are some issues questions:

1. what is the real problem that i am facing with the warning in doing NAT in my example? Will i actually hit some traffic flow snag that justifies me getting the warning?

2. when I use the object nat, it place the reverse (bidirectional) NAT in the config for me, as well as the NAT I want. seems like it shouldn't really be needed? For example, what i really want is:

internet:any -> dmz -> web server:80

but it creates two lines:

web server:80 -> dmz -> internet:any
internet:any -> dmz -> web server:80

i shouldn't really need the first line as i don't want any traffic _originating_ from the web server on port 80, for which there was no first internet request? I guess i could rely on the DMZ interface ACL to take care of that. Since there would be no originating connection in the connection table, the DMZ interface, inbound ACL would take care of that. Seems odd though.

3. thx for the tip on the "after-auto" piece! that is an interesting feature. seems like its half-baked at the moment: i cannot seem to expose that in the ASDM, so its configurable there?

All-in-all, i think i can piece together the ASA config with your tips however, so thx again!
I am still sticking to my original complaint: this programming of NAT's could have been done much better in 8.3 and higher. I think this might be part of the reason, other competitor firewalls are gaining steam on the ASA's. This just isnt dialed in like it should be to make administration easier. Having said that, other firewalls defintiely have their challenges as well!

thx again!

Will