the illusive inside to dmz nat issue

[gmtimmons]

I am setting up my dmz area on my new 5520 and have the outside to dmz nat for a webserver working properly. However Im having trouble understanding what needs to be done for reaching that webserver on the inside. Reading of inside to dmz nat, identity nat, etc. below is partial config.... Im trying to access the 10.2.253.16 web server in dmz from inside thanks any advice is appreciated thanks

ASA Version 8.0(3)

!

hostname cdpasa1

domain-name xx.com

enable password xxx

names

name 10.249.48.0 Hgnwhse description Hgnwhse

dns-guard

!

interface GigabitEthernet0/0

nameif outside

security-level 0

ip address 74.x.x.2 255.255.255.224

!

interface GigabitEthernet0/1

nameif inside

security-level 100

ip address 10.2.30.13 255.255.192.0

!

interface GigabitEthernet0/2

nameif DMZ

security-level 50

ip address 10.2.253.2 255.255.255.0

!

interface GigabitEthernet0/3

shutdown

no nameif

no security-level

no ip address

!

interface Management0/0

nameif management

security-level 100

ip address 192.168.1.3 255.255.255.0

management-only

!

passwd xxx

boot system disk0:/asa803-k8.bin

ftp mode passive

dns server-group DefaultDNS

domain-name cecodoor.com

same-security-traffic permit inter-interface

same-security-traffic permit intra-interface

object-group protocol TCPUDP

protocol-object udp

protocol-object tcp

access-list cecovpn_splitTunnelAcl standard permit 10.0.0.0 255.0.0.0

access-list cecovpn_splitTunnelAcl standard permit 172.0.0.0 255.0.0.0

access-list inside_nat0_outbound extended permit ip 10.0.0.0 255.0.0.0 10.2.23.0 255.255.255.128

access-list inside_nat0_outbound extended permit ip 172.0.0.0 255.0.0.0 10.2.23.0 255.255.255.128

access-list inside_nat0_outbound extended permit ip Hgnwhse 255.255.255.0 10.2.0.0 255.255.192.0

access-list outside_1_cryptomap extended permit ip any Hgnwhse 255.255.255.0

access-list outside_in extended permit tcp any host 74.x.x.13 eq www

access-list outside_in extended permit tcp any host 74.x.x.13 eq https

access-list outside_in extended permit tcp any host 74.x.x.14 eq www

access-list outside_in extended permit esp any any

access-list outside_in extended permit udp any any eq isakmp

access-list outside_in extended permit icmp any host 74.x.x.13

access-list outside_in extended permit icmp any host 74.x.x.16

access-list outside_in extended permit tcp any host 74.x.x.16 eq www

access-list outside_in extended permit tcp any host 74.x.x.16 eq https

access-list outside_in extended deny ip any any log

access-list inside_nat0 extended permit ip any 10.2.253.0 255.255.255.0

access-list inside_nat0 extended permit ip any 10.2.23.0 255.255.255.0

pager lines 24

logging enable

logging buffer-size 20000

logging monitor informational

logging buffered informational

logging asdm informational

logging from-address asa5520@cecodoor.com

logging recipient-address chays@cecodoor.com level errors

mtu outside 1500

mtu inside 1500

mtu management 1500

mtu DMZ 1500

ip local pool cdppool 10.2.23.50-10.2.23.100 mask 255.255.255.192

no failover

icmp unreachable rate-limit 1 burst-size 1

icmp permit host 10.249.48.1 outside

icmp permit any outside

icmp permit any inside

asdm image disk0:/asdm-611.bin

no asdm history enable

arp timeout 14400

global (outside) 101 interface

nat (inside) 0 access-list inside_nat0_outbound

static (inside,outside) 74.x.x.13 10.2.18.13 netmask 255.255.255.255

static (inside,DMZ) 10.2.20.0 10.2.20.0 netmask 255.255.254.0

static (DMZ,outside) 74.x.x.16 10.2.253.16 netmask 255.255.255.255

access-group outside_in in interface outside

[gmtimmons]

this access list was created by ra vpn wizard when creating my remote access vpn in which the pool addresses are 10.2.23.50-100, so I cant change these or it will break my vpn users

[ray_stone]

ok. are you able to telnet from inside machine to web server machine port? Check and confirm. Thanks Vinay Gupta.

[rkalia1]

you can try switching off "nat-control" by "no nat-control" and then you dont need to use identity nat command for going from inside to DMZ. Since you already have one nat 0 command for VPN users so this workaround may work for you. "nat-control" is ON by default in ASAs now.

[jwalker]

Your static from the inside to the dmz needs to be as follows:

static (inside,DMZ) 10.2.30.0 10.2.30.0 netmask 255.255.254.0

When you have deleted all of the old statics and added this one, you need to do a clear xlate.

It should work after that.

Jay

[kermitt95]

If you do not want to perform NAT for traffic passing between the DMZ and inside interfaces then there are two different options I am aware of that you can use. The first method makes use of the "nat (inside) 0" command and the second method involves the use of the "static (inside,DMZ)" command. From my experience, both of these options will accomplish the same goal of instructing the ASA to not perform any NAT translations for traffic passing between the inside and DMZ interfaces. Instructions for configuring each of these methods is listed below. You will want to choose one method or the other and not both. My personal preference would be to use "nat (inside) 0" since you already have it configured for other purposes. IMHO the "nat zero" method is easier to understand and makes more logical sense than using statics.

OPTION 1: To successfully pass traffic between the inside and DMZ interfaces by using the "nat (inside) 0" command, you need to configure the following:

!Remove existing unneeded/unused NAT translation

no static (inside,DMZ) 10.2.20.0 10.2.20.0 netmask 255.255.254.0

!Add entries to the "no NAT" ACL that will match traffic sourced from

!either of the two networks (10./8 or 172./8) residing on the inside

!interface destined for the DMZ network. This ACL is tied to the

!"nat (inside) 0" command. A "nat" command configured with an

!identifier of "0" does not provide the same function as a "nat"

!command configured with an identifier other than "0". The "0" is

!used when you have traffic that you do not want the ASA to NAT. When

!the ASA does not perform a NAT translation it passes traffic just like

!a router does. The "nat" command you are currently using has the ACL

!"inside_nat0_outbound tied to it. Only traffic that succesfully

!matches an entry in this ACL will make use of this "nat" command and

!not be NATted. If traffic does not match this ACL then the ASA

!attempts to match the traffic with the other configured "nat" commands.

access-list inside_nat0_outbound extended permit ip 10.0.0.0 255.0.0.0 10.2.253.0 255.255.255.0

access-list inside_nat0_outbound extended permit ip 172.0.0.0 255.0.0.0 10.2.253.0 255.255.255.0

After this configuration you should run "clear xlate" to clear all existing NAT translations.

OPTION 2: To successfully pass traffic between the inside and DMZ interfaces by using the "static (inside,DMZ)" command, you need to configure the following:

!Remove existing unneeded/unused NAT translation

no static (inside,DMZ) 10.2.20.0 10.2.20.0 netmask 255.255.254.0

!This static command instructs the ASA to NAT the source address

!of packets coming from 10./8 or 172./8 to the packet's original source

!address. So in actuality, the source and destination addresses in the

!packet do not get changed and the packet gets forwarded. Although

!at first glance this command may appear to be pointless and unneeded,

!the ASA requires that this or NAT 0 be configured in order for the ASA

!to forward traffic from a lower security interface (DMZ) to a

!higher security interface (inside).

static (inside,DMZ) 10.0.0.0 10.0.0.0 netmask 255.0.0.0

static (inside,DMZ) 172.0.0.0 172.0.0.0 netmask 255.0.0.0

After this configuration you should run "clear xlate" to clear all existing NAT translations.

If you want to test connectivity from the DMZ server to an inside server using ICMP, you will need to add an access-list and apply it inbound on the DMZ interface. Here is an example:

access-list DMZ permit icmp any any

access-group DMZ in interface DMZ

[kermitt95]

**************************************************

*** This is a continuation of my previous post ***

**************************************************

Also, I suggest that you add the command "nat-control" to your config which prevents the ASA from automatically performing NAT translations, which, IMHO, is a possibe security risk. When "nat-control" is enabled, the administrator must manually configure all NAT translations by using the nat, global, and static commands which you are already doing.

I have never disabled "nat-control" so I am not exactly sure whether or not traffic flowing from either the inside->outside or from the DMZ->outside is successfully being forwarded using your current config. From what I have read about nat-control, traffic flowing in these directions should be working for you. However, I do know that if you decide to enable "nat-control", traffic flowing in these directions will not successfully traverse the ASA using the posted configuration. Without the proper "nat" commands applied to the inside and DMZ interfaces the ASA does not have permission to NAT or no NAT this traffic. If the necessary NAT translation commands are not enabled, the ASA will drop the traffic due to no translation. To fix this, you will want to add the following commands which allow the ASA to NAT/PAT, in this case PAT, traffic received on the specified interface sourced from the specified networks using the address configured with the global command.

!This command already exists in the configuration and allows the ASA to

!use the address configured on its "outside" interface for PAT purposes.

!!!global (outside) 101 interface

!This first nat command instructs the ASA to NAT traffic received on its

!inside interface with a source address in the 10.0.0.0/8 network using

!the "global" command with an identifier of 101. The destination

!address of the packet determines which interface it will be forwarded

!out of and the ASA will attempt to use the address or pool of addresses

!configured by the "global" command configured for that particular

!destination interface.

nat (inside) 101 10.0.0.0 255.0.0.0

nat (inside) 101 172.0.0.0 255.0.0.0

nat (DMZ) 101 10.2.253.0 255.255.255.0

If machines in the DMZ will need access to anything on the inside or outside interfaces, the traffic will need to be allowed through the DMZ access-list. For instance, if you want to allow DMZ servers to access webservers on the outside interface but not the inside interface, you could add the following entries to the ACL applied in the inbound direction to the DMZ interface:

access-list DMZ deny tcp 10.2.253.0 255.255.255.0 10.0.0.0 255.0.0.0 eq 80

access-list DMZ deny tcp 10.2.253.0 255.255.255.0 172.0.0.0 255.0.0.0 eq 80

access-list DMZ permit tcp 10.2.253.0 255.255.255.0 any eq 80

Please be aware that you have a route to the 172.0.0.0/8 network configured on the ASA which is directing all traffic destined for this network towards the inside of your network and not the outside. The majority of the addresses in this range are valid addresses routable over the Internet and not private RFC 1918 addresses. The range of private addresses that begin with the octet of 172 is 172.16./12 or 172.16.0.0 - 172.31.255.255, or 172.16.0.0/255.240.0.0. If you have trouble accessing certain websites or other types of Internet hosts you may want to verify that its IP address does not fall within this range.