the illusive inside to dmz nat issue

Unanswered Question
Apr 25th, 2008
User Badges:

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 [email protected]

logging recipient-address [email protected] 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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
acomiskey Fri, 04/25/2008 - 05:51
User Badges:
  • Green, 3000 points or more

Mark,


This statement is all you need as long as the inside client is part of 10.2.20.0 255.255.254.0.


static (inside,DMZ) 10.2.20.0 10.2.20.0 netmask 255.255.254.0

gmtimmons Fri, 04/25/2008 - 06:04
User Badges:

I have that statement in there already, see bottom of post. I do have the dmz in vlan 50 and the inside network on vlan 33 if that makes any difference.

acomiskey Fri, 04/25/2008 - 06:08
User Badges:
  • Green, 3000 points or more

I know you had that statement, but I was making sure the client you are coming from is part of 10.2.20.0 255.255.254.0.


How are you testing connectivity, ping, http://10.2.253.16 ?

gmtimmons Fri, 04/25/2008 - 06:12
User Badges:

oh, sorry, thought you may have missed it. I am trying from a pc with 10.2.20.219 ip, so it should be able. I cant ping or access from IE. With the identity nat, I shouldnt have to add acl's, correct?

acomiskey Fri, 04/25/2008 - 06:26
User Badges:
  • Green, 3000 points or more

For ping you would need to allow the reply in the dmz interface, but no acl needed for ie.


Are you pinging 10.2.253.16 or a hostname?

gmtimmons Fri, 04/25/2008 - 06:33
User Badges:

i am pinging 10.2.253.16, I figured I should get that working before adding a dns entry. When I do a tracert from 10.2.20.219 it hits my stack (also routing) and then times out. both vlans are on this stack so the routes for 20.x and 253.x are directly connected. stack = 10.2.0.2 with 255.255.192.0 mask tracert hits 0.2 on 1st hop, then dies

rkalia1 Fri, 04/25/2008 - 11:47
User Badges:

Instead of

nat (inside) 0 access-list inside_nat0_outbound

Use the following :

nat (inside) 0 access-list inside_nat0


It should work.

gmtimmons Fri, 04/25/2008 - 12:15
User Badges:

yea I thought that would work to, but it didnt. thanks for the try though

acomiskey Fri, 04/25/2008 - 12:25
User Badges:
  • Green, 3000 points or more

Have you allowed icmp into the dmz interface yet?


access-list dmz extended permit icmp any any

access-list dmz extended deny ip any 10.2.20.0 255.255.254.0

access-list dmz extended permit ip any any

access-group dmz in interface DMZ

gmtimmons Fri, 04/25/2008 - 12:38
User Badges:

I actually added these earlier and was able to ping 10.2.253.16 and then added and acl to permit http, but was never able to access the web page on that server, I have since removed and tried other solutions (this is the only one that I received a successful ping on)

acomiskey Fri, 04/25/2008 - 12:44
User Badges:
  • Green, 3000 points or more

You don't need to add a rule for http. Can you hit the webserver from another machine on the dmz?


gmtimmons Tue, 04/29/2008 - 08:10
User Badges:

Im still battling this. I can ping webserver in dmz from inside, but cant access website from inside to dmz. I can ping my devices on inside from webserver on dmz. Here is my current running config... any other ideas.........Ive made a few changes from original posted config thanks again

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

!

!

passwd BWaQlcykry5AAxTH encrypted

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 any 10.2.253.0 255.255.255.0

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 DMZ_access_in extended permit icmp 10.2.253.0 255.255.255.0 any

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

pager lines 24


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

icmp permit any DMZ

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

nat (inside) 101 0.0.0.0 0.0.0.0

nat (DMZ) 101 10.2.253.0 255.255.255.0

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

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

static (inside,DMZ) 10.2.253.16 10.2.253.16 netmask 255.255.255.255

access-group outside_in in interface outside

access-group DMZ_access_in in interface DMZ

route outside 0.0.0.0 0.0.0.0 74.x.x.1 1

route inside 10.0.0.0 255.0.0.0 10.2.0.2 1

route inside 10.2.64.0 255.255.254.0 10.2.0.2 1

route inside 10.244.12.0 255.255.255.0 10.2.30.12 1

route outside Hgnwhse 255.255.255.0 74.x.x.1 1

route inside 172.0.0.0 255.0.0.0 10.2.30.9 1

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout uauth 0:05:00 absolute

dynamic-access-policy-record DfltAccessPolicy

http server enable

http 10.2.0.0 255.255.0.0 inside

http 192.168.1.0 255.255.255.0 management

no snmp-server location

no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart

**crypto's omitted due to length**

**vpn items omitted due to length**

ray_stone Fri, 04/25/2008 - 12:25
User Badges:

Hi, delete all nat exemption rule because by default security level number of inside network is high(100) and it will access DMZ and outside network without making any rule. Thanks.

ray_stone Fri, 04/25/2008 - 12:27
User Badges:

hi,


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


you have given wrong ip 10.2.23.0 instead of right one 10.2.253.0 check and confirm Thanks Vinay Gupta.

gmtimmons Fri, 04/25/2008 - 12:41
User Badges:

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 Fri, 04/25/2008 - 12:43
User Badges:

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

rkalia1 Fri, 04/25/2008 - 16:33
User Badges:

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.

kermitt95 Wed, 04/30/2008 - 22:54
User Badges:

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 Wed, 04/30/2008 - 23:03
User Badges:

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

*** 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.

Actions

This Discussion