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

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

....

Jay Johnston · ‎03-20-2012

Alex

Starting in 8.3, a NAT translation can be completed by configuring the translation from the inbound (outside->inside) or outbound (inside->outside) direction . Meaning, the translation can be defined two different ways, but they are both functionally equivalent. Depending on which perspective you configure the translation, you'll need to use source or destination service objects. The best way to visualize this is with an example.

For example, lets suppose that a network administrator wishes to provide inbound access to TCP port 3389 (remote desktop) through an ASA 5505 firewall running version 8.4(3). Remote users on the internet will connect directly to the outside interface IP on TCP port 3389, and the ASA will perform NAT, and forward that packet on to a RDP server at 10.1.2.3 on the DMZ of the ASA.

This could be accomplished using one of the two configurations below. They are both functionally equivalent, but the first configuration is somewhat simpler. Often, network administrators will configure option 2, since they visualize the connection from the perspective of the host on the outside of the ASA, so they'll start the configuration with "nat (outside,dmz)...":

NAT config 1: From the perspective of the DMZ to OUTSIDE direction

object network RDPserver
 host 10.1.2.3
object service TCP3389-SOURCE
 service tcp source eq 3389 
!
nat (dmz,outside) source static RDPserver interface service TCP3389-SOURCE TCP3389-SOURCE

NAT config 2: From the perspective of the OUTSIDE to DMZ direction

object network RDPserver
 host 10.1.2.3
object network All-ips
 subnet 0.0.0.0 0.0.0.0
object service TCP3389-DESTINATION
 service tcp destination eq 3389 
!
nat (outside,dmz) source static All-ips All-ips destination static interface RDPserver service TCP3389-DESTINATION TCP3389-DESTINATION

Both configurations are functionally equivalent, and you can use the packet-tracer tool to inject a simulated packet and test that the connection matches. In this example, my ASA's outside interface IP is 192.168.33.44:

Using NAT config 1:

jajohnst5505(config)# packet-tracer input outside tcp 172.16.42.12 12344 192.168.33.44 3389                            

Phase: 1
Type: CAPTURE
Subtype: 
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype: 
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (dmz,outside) source static RDPserver interface service TCP3389-SOURCE TCP3389-SOURCE
Additional Information:
NAT divert to egress interface dmz
Untranslate 192.168.33.44/3389 to 10.1.2.3/3389

Using NAT config 2:

jajohnst5505(config)# packet-tracer input outside tcp 172.16.42.12 12344 192.168.33.44 3389                      

Phase: 1
Type: CAPTURE
Subtype: 
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype: 
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (outside,dmz) source static All-ips All-ips destination static interface RDPserver service TCP3389-DESTINATION TCP3389-DESTINATION
Additional Information:
NAT divert to egress interface dmz
Untranslate 192.168.33.44/3389 to 10.1.2.3/3389

I'll work to get this example on cisco.com and in the config guide.

llamaw0rksE · ‎03-20-2012

Thanks for your interest.

Two discussions here (so leaving ACL rules and NAT ordering to a diff discussion)

I am making my rules via ADSM so bear with me.

Here is a sample of my rules. When making a nat rule within the object it creates the object and the rule.....

THis is where I may be mixing up my views in that I select the OUTSIDE INTERFACE in the translated address box, but look at the NAT from inside to outside??

Edit: No, figured out just now that whatever interface you select in the advanced page for Destination drives the entry in the translated page (fills it in with the same selection)!! So the order will always be correct.

object network NAT4TFS
 host 192.168.24.34

object network NAT4TFS
 nat (main-lan,outside) static interface service tcp 8080 8080

Here is my nat rule created via objects for the first rule above..... jpeg

As you may have surmized all my static nat rules use translated address of outside interface and my advanced page indicates nat direction of inside to outside. Status, the nat maps at the bottom of the config pages looked right and packet tracing works on these nat rules.

I tried some generic RDP type rules as yourself via the two examples. the ADSM let me do both without error...

Outside / In -

translation - inside interface

object network RDP_Forwarding
 host 192.168.24.66

object network RDP_Forwarding  nat (outside,main-lan) static interface service tcp 3381 3381

Inside/ out

translation address - outside interface

object network RDP-PForwarding
 host 192.168.24.67

object network RDP-PForwarding
 nat (main-lan,outside) static interface service tcp 3382 3382

Both worked, so logically speaking it appears I have two choices for my NAT rules.

a. Select routing outside to inside (in which case translated address should be inside interface)

b. Select routing inside to outside (in which case translated address should be the outside interface).

Questions to be answered:

(1) I have been selecting b. with success, now why is that????

(2) I do not understand the difference in your two options as the format looks different but my format does not change.

static interface ....... Remember I am not using nat to control access by user but merely to do port forwarding.

HECK I dont think I can even get to your configs using ADSM.

(3) I did not use service objects in my rules is that part of the problem because you have used service objects with definitive source port (assuming if Put in port numbers the router by default assigns them a destination config??)

(4) If so, are you saying my rules should work but simply use service objects with source port defined info???

okay I just tried using OM1 ( a defined service port) in my nat rule instead of the port number 5080, and regardless If I definede the service port as either source or destination I received the following error.

Which is very confusing for poor ole me. What is going on........

Next box will discuss order.....

llamaw0rksE · ‎03-20-2012

Part II order of NAT and ACL.........

object network NAT4WWW2OM1
 nat (main-lan,outside) static interface service tcp 5080 www

Let outside users by selecting the wanip of our router in their browser achieve potential access to our private server on port 5080.

I combined that with an ALC rule that let only specific users access to that server on the allowed ports (including port 80 (www) but NOT port 5080).

access-list outside_access_in remark Access to Open Meetings
access-list outside_access_in extended permit object-group OMServiceGroup object-group TFS-usergroup object VS-pcIP 
access-list outside_access_in extended permit object-group CorporateServiceGroup object Corporate-user object VS-pcIP

Group of services (bold), external user (italics), private server (underline)

Guess what? No success, until I also included port 5080 in the ACL rule. In other words UNNAT had been performed (sounds like a vampire diaries segment), I was under the impression that ACLs were applied before NAT???

What is the correct reasoning?

I am also concerned with the way i have defined my service ports (destinatino vice source) that this may hamper successful nat or acls???

llamaw0rksE · ‎03-23-2012

I have come to the conclusion my setup is correct. My acls are working, my nat is working. Thus I can only concur using destination service with (inside,outside) is perfectly legitimate and most people do not understand how this router actually works. Luckily for me, I have superficial knowledge which seems to be the right mix to get it done. ;-)

here are two nat packet traces which show that external user query for a translated port gets routed correctly.

the second packet trace shows the outbound (I do not know how to trace the response to an inbound so I caveat the outbound with two thoughts. One the router is unable to reach the destination because its treated as a new flow. But the translation of the port works from main lan to outside interface.

llamaw0rksE · ‎03-24-2012

Jay I have to disagree with your examples based on my experience. I think you have it backwards and furthermore I do not understand the configurations. This all may be due to my shallow knowledge but thats what these discussions are for.....to communicate facts, and evolve the truth........

(The example you use is most excellent, a typical port forwarding scenario)

For example, lets suppose that a network administrator wishes to provide inbound access to TCP port 3389 (remote desktop) through an ASA 5505 firewall running version 8.4(3). Remote users on the internet will connect directly to the outside interface IP on TCP port 3389, and the ASA will perform NAT, and forward that packet on to a RDP server at 10.1.2.3 on the DMZ of the ASA.

This could be accomplished using one of the two configurations below. They are both functionally equivalent, but the first configuration is somewhat simpler. Often, network administrators will configure option 2, since they visualize the connection from the perspective of the host on the outside of the ASA, so they'll start the configuration with "nat (outside,dmz)...":

NAT config 1: From the perspective of the DMZ to OUTSIDE direction

object network RDPserver
 host 10.1.2.3
object service TCP3389-SOURCE
 service tcp source eq 3389 
!
nat (dmz,outside) source static RDPserver interface service TCP3389-SOURCE TCP3389-SOURCE

Based on my experience this is how this rule actually works on a real asa 5505, using real firmware and creating the nat rule within the object menu of ADSM. YOu will note I refrain from calling the host the server. This is misleading to put in a NAT rule for two reasons. Simply put, if you do require ACL rules you will still need to define the object anyway and it should be clear that this acl required object is the server. Secondly, if you have more than one server on the host, or ports needed for that PC you will need multiple nat rules. These rules will all point to the same host but will required diffnames. In conclusion you should have used. Nat_for_RDPServer or something similar.

(Note my service objects for nat(inside, outside) have to be destination to work. Opposite to your suggestion.)

(service object not required for NAT rule but for ACLs. My experience differs from your example in that my ADSM does NOT permit me to put in names vice port numbers in NAt rules, unless its a default service!!!)

object service RDP

service tcp destination eq 3389

object network NAT4RDP

host 10.1.2.3

object network NAT4RDP

nat (main-lan,outside) static interface service tcp 3389 3389

(My example uses the inside (main-lan) vice DMZ but what you should note is that there is no requirement for any text between static and interface or interface and service, in fact not sure how this is even possible using ADSM?? The input is interface how the heck you got RDP server in there is confusing.)

NAT config 2: From the perspective of the OUTSIDE to DMZ direction

object network RDPserver
 host 10.1.2.3
object network All-ips
 subnet 0.0.0.0 0.0.0.0
object service TCP3389-DESTINATION
 service tcp destination eq 3389 
!
nat (outside,dmz) source static All-ips All-ips destination static interface RDPserver service TCP3389-DESTINATION TCP3389-DESTINATION

Both configurations are functionally equivalent, and you can use the packet-tracer tool to inject a simulated packet and test that the connection matches. In this example, my ASA's outside interface IP is 192.168.33.44:

(I have no clue on how to articulate this rule in ADSM so that I can test it???? )

Jay Johnston · ‎03-26-2012

I think one source of the confusion here is that you are applying the NAT configuration to the network object, while in the example I use I apply the NAT configuration within the global config space (aka Manual NAT aka "Twice" NAT).

To apply NAT config within the object in ASDM, you edit the object and click the NAT drop-down (this is what you did)

To apply NAT config within the global config space, go to Configuration->Firewall->NAT Rules

Both will work just fine, it is up to you which to use. Object NAT config is a bit simpler, but the Manual (Global space) NAT rules allow for translation of the destination of the IP packet, and the lines can be re-ordered within the configuration (the object nat rules are auto-ordered based on the netmask of the object that contains the rule).

With regard to NAT/ACL ordering, starting in 8.3 the ACLs must refer to the real address of the IP hosts and not the global (mapped) addresses. See this doc

https://supportforums.cisco.com/docs/DOC-12690#ACL_Changes

llamaw0rksE · ‎03-26-2012

Thanks Jay, would it be fair to say for simple port forwarding for external users to inside servers, the embedded nat objects are sufficient but when you need groups of inside usrs to reach specific external servers then twice nat is the way to go?

Jay Johnston · ‎03-27-2012

For this port forwarding example, both Object NAT and Manual NAT work fine. Object NAT is less effort to configure, but Manual NAT allows for specific line re-ordering and destination translation.

llamaw0rksE · ‎03-27-2012

Okay So to do manual nat I would need to go into ADSM and under NAT rules configure manually. Funny enough when I first started using the gui, thats what I did but I had to much information entered. Instead of posting the config file, it would be more helpful to show the nat rules pages with what it looks like there and maybe some screen shots of the editing required. I am not sure why I would need to use manual nat but that because i have never been worried about accessing an external server. Lets say I have 192.168.24.33 on my internal lan and it needs FTP access to an external IP at 24.666.33.12 . Why would I need to create a static nat rule for this. ACLs not needed its outgoing higher to lower security setting. I have dynamic pat for return traffic to the net (ftp request originates within the router). Not sure what you mean about destination translation.

llamaw0rksE · ‎03-31-2012

Jay, what needs to be done is add manual nat or twice nat ADSM examples to many of the posts here on this forum.

What I need to see to help understand the cisco view on interfaces and packet flows etc is the EDITING page for adding NAT rules. The embedded object nat method is as you indicated easy and straightforward but using NAT rules in the gui is another level of difficulty that is NOT well documented anywhere. Jpegs included to indicate which view I am talking about.............

One thing that needs much more explanation for sure is the relations ship between the "Tranlated Addr:" selection interface on the first NAT entry page and the "Destination Inteface:" selection on the second Advanced page.

This example shows a simple embedded nat object rule (port forwarding) with a slight twist in that incoming port 80 (what a specific external user is allowed to use, is translated to 5080, the servers port behind the router). What I need to see is twice nat or manual nat rules explained with the appropriate entries in the jpegs above, and then discussed as shown in the summary display in the adsm as per below........ I really like the presentation of this summary and the fact that the picture at the bottom displays the flow pictorially (and finally the packet trace capability).

Jay Johnston · ‎04-03-2012

Thanks for your feedback, and I agree that it would be good to have more examples of NAT configuration from ASDM.

Please check out this video which explains how to do simple port forwarding for a server behind the ASA, configured via ASDM and CLI:

https://supportforums.cisco.com/docs/DOC-17347

juliushasan · ‎07-25-2013

hai jay,i try to migrate from asa 5510 ver 7.6 to asa 5515 ver 8.6

here is the existing syntax that i want to convert to ver 8.6:

nat-control

global (OUTSIDE) 1 202.77.104.210 netmask 255.255.255.0

global (DMZ) 1 interface

nat (INSIDE) 0 access-list nonat

nat (INSIDE) 1 0.0.0.0 0.0.0.0

nat (DMZ) 1 192.168.10.0 255.255.255.0

static (CCTV,OUTSIDE) tcp 202.77.104.215 40000 192.168.0.3 40000 netmask 255.255.255.255

static (CCTV,OUTSIDE) tcp 202.77.104.215 40004 192.168.0.4 40004 netmask 255.255.255.255

static (CCTV,OUTSIDE) tcp 202.77.104.215 40003 192.168.0.3 40003 netmask 255.255.255.255

static (CCTV,OUTSIDE) tcp 202.77.104.215 40002 192.168.0.2 40002 netmask 255.255.255.255

static (CCTV,OUTSIDE) tcp 202.77.104.215 40001 192.168.0.1 40001 netmask 255.255.255.255

static (INSIDE,OUTSIDE) tcp 202.77.104.212 3389 10.17.8.56 3389 netmask 255.255.255.255

static (INSIDE,OUTSIDE) tcp 202.77.104.213 pcanywhere-data 10.17.1.112 pcanywhere-data netmask 255.255.255.255

static (INSIDE,OUTSIDE) udp 202.77.104.213 pcanywhere-status 10.17.1.112 pcanywhere-status netmask 255.255.255.255

static (INSIDE,OUTSIDE) tcp 202.77.104.212 pcanywhere-data 10.17.8.56 pcanywhere-data netmask 255.255.255.255

static (INSIDE,OUTSIDE) udp 202.77.104.212 pcanywhere-status 10.17.8.56 pcanywhere-status netmask 255.255.255.255

static (DMZ,OUTSIDE) 202.77.104.211 192.168.10.40 netmask 255.255.255.255

static (INSIDE,OUTSIDE) 202.77.104.214 10.17.1.12 netmask 255.255.255.255

the "pc anywhere" is :

access-list outside_access_in extended permit tcp any host 202.77.104.211 eq pcanywhere-data

access-list outside_access_in extended permit tcp any host 202.77.104.213 eq pcanywhere-data

access-list outside_access_in extended permit udp any host 202.77.104.213 eq pcanywhere-status

when i try to convert to ver 8.6, i try to make syntax like this:

for example:

static (CCTV,OUTSIDE) tcp 202.77.104.215 40000 192.168.0.3 40000 netmask 255.255.255.255

i make 2 object for cctv and ip public:

1.object network cctv#1

host 192.168.0.3

nat (any,any) static 202.77.104.215 service tcp 40000 40000

object-group network 202.77.104.215

network-object 202.77.104.215 255.255.255.255

2.i declared mapped source dan out mapped source,

object network in_map

host 100.100.1.1

object network out_map

host 200.200.1.1

3.final static nat will be

nat (CCTV,OUTSIDE) source static cctv#1 in_map destination static out_map 202.77.104.215

is it correct or i should change it?

then for this below syntax what will be converted to?

static (INSIDE,OUTSIDE) tcp 202.77.104.213 pcanywhere-data 10.17.1.112 pcanywhere-data netmask 255.255.255.255

please your advice

regard

natus · ‎10-26-2017

hi dear

it whith plaisir for me to discution whith you i m from franch contrie so i try in inglish sory that

im certificate CCNA . so im trableshoot

i want to public severels webserveur on same pulic adress whith forward port