07-18-2014 12:21 PM - edited 03-11-2019 09:29 PM
Customer request to use destination NAT and port forwarding to access a server from inside to dmz. The packet tracer shows it is using the Dynamic NAT instead of the static NAT if I use the following command and traffic will fail. (traffic NAT out the outside Interface)
nat (inside) 1 0.0.0.0 0.0.0.0
global (outside) 1 interface
static (inside,dmzr) tcp 192.168.212.117 2383 192.197.205.154 2383 netmask 255.255.255.255
When I use this NAT command traffic will work.
static (dmzr,inside) tcp 192.197.205.154 2383 192.168.212.117 2383 netmask 255.255.255.255
From packet tracer there is a phase 4 type UN-NAT before the route phase
Phase: 4
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
static (dmzr,inside) tcp 192.197.205.154 2383 192.168.212.117 2383 netmask 255.255.255.255
nat-control
match tcp dmzr host 192.168.212.117 eq 2383 inside any
static translation to 192.197.205.154/2383
translate_hits = 0, untranslate_hits = 1
Additional Information:
NAT divert to egress interface dmzr
Untranslate 192.197.205.154/2383 to 192.168.212.117/2383 using netmask 255.255.255.255
What is the different between these two command? I notice the xlate table shows different. How to explain that? I never see Cisco document the 2nd way.
static (inside,dmzr) tcp 192.168.212.117 2383 192.197.205.154 2383 netmask 255.255.255.255
static (dmzr,inside) tcp 192.197.205.154 2383 192.168.212.117 2383 netmask 255.255.255.255
Solved! Go to Solution.
07-20-2014 07:22 AM
Hi,
Even i had this confusion some years back. But when you want to take a control of devices in one zone from the other zone..... your statement differs....
If you want to access inside segment from DMZ then your 1st statement will do that....
static (inside,dmzr) tcp 192.168.212.117 2383 192.197.205.154 2383 netmask 255.255.255.255
If you want to access DMZ segment from inside then your 2nd statement will do that....
static (dmzr,inside) tcp 192.197.205.154 2383 192.168.212.117 2383 netmask 255.255.255.255
Regards
Karthik
07-20-2014 08:42 AM
Hi,
The 2nd command works because you are publishing the web server itself that is located in the DMZ to be accessed by internal users. So, you should refer to the DMZ interface first in your NAT command. Many people are still doing this mistake thinking that NAT rules are like access lists. When i use (inside,dmzr), people think that i am translating the inside world to the DMZ world in order to access resources in DMZ. Nope! This is not how it works. It works like BGP. When you advertise routes for your AS, you're actually controlling INBOUND traffic even though the routes are advertised in the outbound direction. The same thing with publishing a server. When you publish a server, you are actually announcing the public to access that server not the server access you.
Hope this helps.
AM
07-20-2014 07:22 AM
Hi,
Even i had this confusion some years back. But when you want to take a control of devices in one zone from the other zone..... your statement differs....
If you want to access inside segment from DMZ then your 1st statement will do that....
static (inside,dmzr) tcp 192.168.212.117 2383 192.197.205.154 2383 netmask 255.255.255.255
If you want to access DMZ segment from inside then your 2nd statement will do that....
static (dmzr,inside) tcp 192.197.205.154 2383 192.168.212.117 2383 netmask 255.255.255.255
Regards
Karthik
07-24-2014 09:32 AM
Thank you all for your reply. It is very helpful.
07-20-2014 08:42 AM
Hi,
The 2nd command works because you are publishing the web server itself that is located in the DMZ to be accessed by internal users. So, you should refer to the DMZ interface first in your NAT command. Many people are still doing this mistake thinking that NAT rules are like access lists. When i use (inside,dmzr), people think that i am translating the inside world to the DMZ world in order to access resources in DMZ. Nope! This is not how it works. It works like BGP. When you advertise routes for your AS, you're actually controlling INBOUND traffic even though the routes are advertised in the outbound direction. The same thing with publishing a server. When you publish a server, you are actually announcing the public to access that server not the server access you.
Hope this helps.
AM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide