Config Example: Static PAT (NAT) for a range of ports using ASA version 8.3

Jay Johnston · ‎06-07-2011

Recently the user Sami had a question about using the ASA to translate different ranges of ports from one external global ip to different internal (local) IP addresses. He was migrating the configuration to the ASA from another vendor. Here is his question:

Hi,

I am in the process of replacing all of our checkpoint firewalls with Cisco ASA's. I am curently running into the following problem with configuring static NATs and PATs.

At some of our locations, the external IP's are mapped to internal IP's based on port ranges, and I can't find a way to replicate that on the ASA. Here's an example:

External NAT External Port Internal Host

1.1.1.20 UDP 9000 10.10.10.1

1.1.1.20 UDP 50000-65500 10.10.10.2

1.1.1.20 ANY 10.10.10.3

I could find any way of configuring a static NAT that using the port range (50000-65500), and i'm not about to write 15000 static NAT statements.

Does anyone know how you can use the port range in the static NAT?

Thanks,

Sami

This can be accomplished easily using the NAT syntax of ASA version 8.3 or greater:

First, define objects that represent the hosts on the inside, and the global address on the outside

object network obj-10.10.10.1

host 10.10.10.1

object network obj-10.10.10.2

host 10.10.10.2

object network obj-10.10.10.3

host 10.10.10.3

object network obj-1.1.1.20

host 1.1.1.20

!

Then define the objects that represent the services that you want to translate...the key here is that they can include a range of ports

object service obj-serviceUDP9000

service udp source eq 9000

object service obj-serviceUDP50000-65500

service udp source range 50000 65500

Finally, define the manual NAT commands that will translate those port ranges from the local to the global IPs. Note that even though the connections might be initiated INBOUND (meaning from hosts on the internet to the internal network), we'll define the translations from inside to outside...we could have made the translations from outside to inside (outside,inside) but defining the translations from the outbound perspective keeps things a bit simpler...

nat (inside,outside) source static obj-10.10.10.1 obj-1.1.1.20 service obj-serviceUDP9000 obj-serviceUDP9000

nat (inside,outside) source static obj-10.10.10.2 obj-1.1.1.20 service obj-serviceUDP50000-65500 obj-serviceUDP50000-65500

nat (inside,outside) source static obj-10.10.10.3 obj-1.1.1.20

Using the 'show nat detail' command shows that these three nat statements I added to the configuration. Note that the NAT statements I created start at #4, since I have three other NAT statements in my configuration that I've omitted from this example...

ASA(config)# show nat detail

.......

4 (inside) to (outside) source static obj-10.10.10.1 obj-1.1.1.20 service obj-serviceUDP9000 obj-serviceUDP9000

translate_hits = 0, untranslate_hits = 0

Source - Origin: 10.10.10.1/32, Translated: 1.1.1.20/32

Service - Origin: udp source eq 9000 , Translated: udp source eq 9000

5 (inside) to (outside) source static obj-10.10.10.2 obj-1.1.1.20 service obj-serviceUDP50000-65500 obj-serviceUDP50000-65500

translate_hits = 0, untranslate_hits = 0

Source - Origin: 10.10.10.2/32, Translated: 1.1.1.20/32

Service - Origin: udp source range 50000 65500 , Translated: udp source range 50000 65500

6 (inside) to (outside) source static obj-10.10.10.3 obj-1.1.1.20

translate_hits = 0, untranslate_hits = 0

Source - Origin: 10.10.10.3/32, Translated: 1.1.1.20/32

Using the packet tracer tool to inject a sample packet into the ASA's outside interface, I can verify that the NAT rules I created are being hit appropriately and translating the packet!

ASA# packet-tracer input outside udp 4.4.4.4 48483 1.1.1.20 9000

......

Phase: 3

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

nat (inside,outside) source static obj-10.10.10.1 obj-1.1.1.20 service obj-serviceUDP9000 obj-serviceUDP9000

Additional Information:

NAT divert to egress interface inside

Untranslate 1.1.1.20/9000 to 10.10.10.1/9000

......

ASA# packet-tracer input outside udp 4.4.4.4 48483 1.1.1.20 50032

......

Phase: 3

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

nat (inside,outside) source static obj-10.10.10.2 obj-1.1.1.20 service obj-serviceUDP50000-65500 obj-serviceUDP50000-65500

Additional Information:

NAT divert to egress interface inside

Untranslate 1.1.1.20/50032 to 10.10.10.2/50032

....

eric · ‎11-29-2011

Jay, does the original question from Sami and your example above imply that the 1.1.1.20 External NAT address is NOT the address assigned to the "outside" interface? I'm trying to follow your example above for some UDP ranges for VOIP and wherein my obj-1.1.1.20 is named different but has the same IP that is assigned to my "outside" interface. When I attempt the equivalent of the following:

nat (inside,outside) source static obj-10.10.10.2 obj-1.1.1.20 service obj-serviceUDP50000-65500 obj-serviceUDP50000-65500

I get:

"Error: Address MyActualPublicIP overlaps with outside interface address."

"Error: NAT Policy is not downloaded"

This error is leaving me to believe that I must have a 2nd static public IP available for use in this config. Is that right?

Jay Johnston · ‎11-30-2011

Eric, you don't have to have a new object that references the outside ip address of your firewall. Use the 'interface' keyword when you're referencing the interface IP address in a nat statement. That will pick up the IP address of the interface.

So try this:

nat (inside,outside) source static obj-10.10.10.2 interface service obj-serviceUDP50000-65500 obj-serviceUDP50000-65500

eric · ‎11-30-2011

Thanks Jay. I think I tried using "outside" where you have "interface" below. Seems the error returned was something like "outside" not being a valid network object or some such thing. If I were to use "interface" as seen below how would the nat statement know which interface I was referring to?

Would be GREAT if this will work on my ASA 5505 50 user running ASA ver 8.42 without needing a 2nd public IP.

nat (inside,outside) source static obj-10.10.10.2 interface service obj-serviceUDP50000-65500 obj-serviceUDP50000-65500

Jay Johnston · ‎11-30-2011

The ASA knows which interface to use because of the order of the "nat (inside,outside)" at the start of the command. The order here says that "inside" is the local (real) interface and outside is the global (mapped) interface. You can see below that if I type a "?" on the CLI, the ASA is expecting the global (mapped) object or interface:

ciscoASA(config)# nat (inside,outside) source static obj-192.168.1.80 ?

configure mode commands/options:
  WORD       Specify object or object-group name for mapped source
  interface  Specify interface NAT
ciscoASA(config)# nat (inside,outside) source static obj-192.168.1.80

So, the ASA is expecting information on the mapped, global address, and in this case since you said "outside" was the mapped interface, if you put "interface" at this spot, it ties it to the outside interface.

eric · ‎11-30-2011

Very good. That make sense. Thanks much Jay. I'll give it a try as soon as I can and then follow up. Could be early next week before I am back on-site to try though.

eric · ‎12-14-2011

Jay, I think the nat command worked. At least the ASA took the command. Problem I'm running into now seems to be with the ACL not allowing a range for SIP. Even though I have the ACL commnands below, I find that inbound traffic in the UDP 10000 to 20000 range is getting dropped as seen below. Calls from remote VOIP phones (apparently registering with the local VOIP server) ring on local phone VOIP phones, but there is no voice/audio when answered.

ACL:

access-list outside_access_in extended permit udp any any range 10000 20000

access-list outside_access_in extended permit udp any any range 49152 65534

Dropped traffic:

remoteASAOutsideIP 25808 LocalASAOutsideIP 19992 UDP request discarded from remoteASAOutsideIP
/25808 to outside:LocalASAOutsideIP/19992

Any issue with allowing a range in an ACL as I have done above??

Jay Johnston · ‎12-14-2011

Eric,

Ok, we're going farther down the rabbit hole here. When we see inbound packets dropped and they are destined to the outside interface IP, and the syslog reads "UDP request discarded from...to outside:LocalASAOutsideIP/"

usually this means that an inbound packet matched a nat rule higher in the table and didn't proceed down to your nat rule you created to match this traffic. Often this is because a manual NAT rule exists that performs PAT for outbound traffic (inside to outside) using the outside interface as the global PAT ip. The side effect of this is that inbound packets destined to the outside IP will match this translation first, get dropped, and not proceed further down the table to match your new NAT line.

Often the NAT rule that causes this will look like something like this:

nat (any,outside) source dynamic any interface

So if your nat rules look like this:

ASA#show run nat
nat (any,outside) source dynamic any interface
...
nat (inside,outside) source static obj-10.10.10.2 interface service obj-serviceUDP50000-65500 obj-serviceUDP50000-65500

Then you could see this problem. Try re-ordering them so that your static nat range rule is at the top, like this (notice I use the '1' when I re-enter the command, to insert it at the top of the table):

ASA#conf t
ASA(config)# no nat (inside,outside) source static obj-10.10.10.2 interface service obj-serviceUDP50000-65500 obj-serviceUDP50000-65500
ASA(config)# nat (inside,outside) 1 source static obj-10.10.10.2 interface service obj-serviceUDP50000-65500 obj-serviceUDP50000-65500
ASA(config)#
ASA(config)# show run nat
nat (inside,outside) source static obj-10.10.10.2 interface service obj-serviceUDP50000-65500 obj-serviceUDP50000-65500
nat (any,outside) source dynamic any interface
...

If that doesn't help, you should probably get a TAC case open and the TAC can take a closer look at what is going on.

You can use the 'packet-tracer' command to simulate a packet through the firewall and see which NAT rule the packet lands on; that prevents you from having to initiate a call each time to test your configuration.

eric · ‎12-14-2011

Thanks for the immediate response Jay. I am using PAT for outbound traffic, but it appears that the order base is already covered as seen here:

nat (inside,outside) source static SIP interface service SIP_10kTo20k SIP_10kTo20k

nat (inside,outside) source static SIP interface service SIP_49152To65534 SIP_49152To65534

object network obj_any

nat (inside,outside) dynamic interface

object network HTTP

nat (inside,outside) static interface service tcp www www

object network HTTPS

nat (inside,outside) static interface service tcp https https

object network MAIL

nat (inside,outside) static interface service tcp smtp smtp

...

What's odd is that single port nat commands (80, 443, 25) below the "nat (inside,outside) dynamic interface" command are working. Perhaps time for a TAC case as you suggested. Thanks again!

Jay Johnston · ‎12-14-2011

Yep, your configuration looks fine. Your service object SIP_10kTo20k specifies SOURCE and not a DESTINATION service right?

One last thing to try, if you can: In a maintenance window when you can take traffic interruption, you could clear out all the nat rules and paste them back in in the same order:

issue: 'show run nat'

copy the configs displayed to a notepad file

issue 'clear config nat',

then paste the commands back in.

The config should look just like before. If doing that suddenly allows the traffic to flow ok, then that confirms you could be hitting the bug

CSCtt11890 ASA: Manual NAT rules inserted above others may fail to match traffic

You can review the release-note of this bug, which describes the symptoms, at the bug toolkit:

http://tools.cisco.com/Support/BugToolKit/action.do?hdnAction=searchBugs

Either way, a TAC engineer can perform diagnosis to determine the root cause of the problem.

eric · ‎12-15-2011

I'm not sure if I follow your question about my SIP_10kTo20k service object, but now that I look at it to reply here it IS configured for udp 10000-20000 for BOTH the "Destination Port/Range" AND the "Source Port/Range". I'm just looking to specify that inbound traffic with a DESTINATION port in udp range of 10000-20000 gets nat'd to my VOIP server. Same for inbound traffic with a DESTINATION port in udp range of 49152-65534 on my

SIP_49152To65534 service object. With that in mind seems only the "Destination Port/Range" on the service objects should specify the range. The SIP network object simply specifies the LAN IP of the VOIP server.

A bug actually came to mind yesterday and again today because after my last comment yesterday because, without me making a change, users in the remote office reported taking and making calls. Then calls stopped working again. We restarted the VOIP server last night and as of about 10 min ago the remote office appeared to be able to take calls again. No one was there to test making an outbound call which is the traffic that I showed dropped in my 11:50 a.m comment from yesterday.

Jay Johnston · ‎12-15-2011

Eric,

Since your nat translation was configured in the inside->outside direction (nat (inside,outside)...), the translation is configured from the "outbound" perspective, aka the perspective of the host on the inside, even though the actual traffic you're concerned with will be initiated "inbound" from outside->inside. NAT translations are bi-directional, so you can technically configure this same NAT translation from the inbound or outbound perspective and they would be functionally equivalent. By specifying that the translation must match both the source and destination ports, you're restricting what packets will match this translation, and this might be where your problem lies.

Therefore, in the service object for this translation you should specify the service object from the perspective of the host on the inside, (with the ports as a source in the service object), and not necessarily include the destination ports (even though you're wanting to match on the destination of the ip packets). I did this with my example above:

object service obj-serviceUDP50000-65500
   service udp source range 50000 65500

This way, packets inbound to the ASA hitting the outside interface with the destination port in the range of 50000 to 65500 will hit this NAT translation. It's all the order that you put the interfaces for the NAT translation that will dictate the directionality and how you configure the rest of the translation.

In your recent testing, it could be that by having both the source and destination port ranges specified, sometimes packets would match both ranges (source and destination) and match the translation, and the calls would work; other times the packet's source or destination didn't match the ranges you specified and the calls would fail.

eric · ‎12-15-2011

Good news Jay! I removed the specified DESTINATION ports as you suggested and the remote office is successfully making and taking calls now. It makes sense that calls were someontimes working when the ports happened to match the 10000-20000 range on both the source and destination ports. Definitely confusing to need to specify the SOURCE port range when I'm really targeting the DESTINATION port range though. Thanks so much for your expertise on all facets of this traffic!!!

Jay Johnston · ‎12-15-2011

Eric, I'm really glad everything is working now and that your calls are successful. Hopefully our conversation can help someone else who hits the same problem in the future!

Cheers,

Jay

llamaw0rksE · ‎03-19-2012

Good day, I just finally configured my asa 5505 8.43 with 6.x asdm. My problem was also rooted in the dual nature of my service objects. In my case I ended resolving it by using destination only and NOT source and it seems to be working fine thus far. (I noted that all the default service ports are setup as destination, which guided my choice.) Can you please confirm that these should be assigned as source not destination?? Same scenario above, authorized external users via one public wanip connecting to a pc with several servers. (no ranges). Everything works with destination in service port rules (both real world and packet trace). What am I missing and why is it working?

As to the issue of port ranges. One can do that in the ASDM by putting in port ranges in the NAT rule. Syntax is xxxx-yyyy as required.

llamaw0rksE · ‎03-20-2012

Okay two issues. I should have reported partial success.

Issue 1. Cisco Lies. ACLs are NOT performed before NAT. Or more accurately they dont mention UNNAT.

I have a port translation in nat for one set of external clients that can use port 80 at corporate but not the desired port of 5080 at the private server behind the asa 5505 (single public wanip). So I ACL ruled port 80 for them but not 5080 (no requirement right as NAT is done after ACL). WRONG EFFFING WRONG. I had no success with that server for them until this morning when I added,,,,,,,,,,,, you guessed it port 5080 to the ACL rule. Checking packet tracer an unnat process takes place before acl switching the ports the bugger.

SO the moral is the router is frigging with NAT before the ACL Rule.

IN any case I know have all servers seemingly firing on all cylinders. This is based strictly on rudimentary logging in a number of users but not much functionality. So it remains to be seen.

Issue 2. ONe particulare service port is a pain to switch from source to destination or vice versa UNLIKE all my other service ports. I do not know why and here is the error message received.

object service TFS
[ERROR] service tcp destination eq 8080
Object is used in IPv6 access-list outside_access_in. Can't change IP to IPv4.
ERROR: object (TFS) updation failed due to internal error

Now I checked in ACLS and everywhere else. I have no IPV6 anywhere. So WTF over. I was able to change the name of the service object then change the port number, which let me create a new service object which I then had to insert into the ACL rules and then could delete the now old one. Any geniuses out there that explain that one?

Issue 3. (just checking to see if anyone noticed I said 2 above LOL) The whole discussion for static nat, and service port definition. They would NOT work when I chose source and they WORK when I select destination. (they also did not work when I had both source and destination selected in service ports). So on one hand there are the xperts saying oh lads, you have to put in source, it seems backwards but please do.... and on the other hand you have two facts, one my setup works with them in destination and EVERY DEFAULT service object uses destination.

Conclusioin, too many docs, videos, blogs, discussions, forums. and only a vague sense of unease is my reward.