DMZ to INSIDE access

Unanswered Question
Dec 4th, 2008

I have a device off the DMZ interface of the firewall (PIX\ASA) and it requires access to a number of hosts on the inside (and vice versa) on a number of ports.

Does this require a NAT? ACL?

Can you provide an example?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
John Blakley Thu, 12/04/2008 - 13:33

Assuming you have the following:

DMZ Subnet: 192.168.1.0

Inside Subnet: 10.10.10.0

Try:

static (inside,dmz) 10.10.10.0 10.10.10.0 netmask 255.255.255.0

acl dmz permit tcp 192.168.1.0 0.0.0.255 10.10.10.0 0.0.0.255 eq 25

acl dmz permit tcp 192.168.1.0 0.0.0.255 10.10.10.0 0.0.0.255 eq 80

access-group dmz in interface dmz

You'll need to create an access list entry for each port you want, and you'll need to have an acl on the outside interface allowing traffic into your network. This is from memory, so I hope it works. :-)

HTH,

John

ronshuster Mon, 12/08/2008 - 11:06

John,

What is the purpose of this line:

static (inside,dmz) 10.10.10.0 10.10.10.0 netmask 255.255.255.0

I am looking for one specific server on the dmz to communicate with one specific server on the inside on a number of specific ports. All other devices on the inside should not be able to communicate with any device on the dmz.

Would the above restrict these conditions?

ronshuster Mon, 12/15/2008 - 07:15

i am unable to get this to work.

My dmz IP address : 172.20.0.6

My inside : 192.168.4.0\24 & 192.168.5.0\24

My config is:

static (inside,dmz) 192.168.4.0 192.168.4.0 netmask 255.255.255.0

static (inside,dmz) 192.168.5.0 192.168.5.0 netmask 255.255.255.0

access-group dmz_out in interface dmz

access-list dmz_out extended permit tcp host 172.20.0.35 host 10.20.4.161 eq smtp

access-list dmz_out extended permit tcp host 172.20.0.35 eq smtp host 10.20.4.161

access-list dmz_out extended permit ip any any

I am unable to ping from 172.20.0.6 to any of the 192.162.4 or 5 addresses.

Any idea?

ronshuster Mon, 12/15/2008 - 07:52

!

hostname **********

domain-name default.domain.invalid

enable password ************* encrypted

names

dns-guard

!

interface Ethernet0

description OUTSIDE

speed 10

duplex full

nameif outside

security-level 0

ip address **********

!

interface Ethernet1

description 100

nameif inside

security-level 100

ip address 10.20.99.33 255.255.255.240

!

interface Ethernet2

description dmz

nameif dmz

security-level 50

ip address 172.20.0.1 255.255.255.0

!

passwd ************* encrypted

banner exec LINE

ftp mode passive

dns domain-lookup outside

dns name-server ***********8

dns name-server ***********8

object-group service IPSS-TCP tcp

port-object eq 5023

port-object eq https

port-object eq 3389

port-object eq 5022

port-object eq ssh

port-object eq telnet

port-object eq 69

object-group service IPSS-UDP udp

access-list inside_out extended permit ip any any

access-list inside_out extended permit icmp any any

access-list outside_incoming extended permit tcp any host ***********8 eq smtp

access-list outside_incoming extended permit tcp any host *********** eq https

access-list outside_incoming extended permit tcp any host *********** eq www

access-list dmz_inside extended permit ip any any

access-list dmz_out extended permit tcp host 172.20.0.35 host 10.20.4.161 eq smtp

access-list dmz_out extended permit tcp host 172.20.0.35 eq smtp host 10.20.4.161

access-list dmz_out extended permit ip any any

access-list allownatout extended permit ip 10.20.0.0 255.255.0.0 any

access-list allowdmzout extended permit ip 172.20.0.0 255.255.255.0 any

access-list outside_cryptomap_20 extended permit ip 192.168.4.0 255.255.255.0 172.16.50.0 255.255.255.0

access-list outside_cryptomap_20 extended permit ip 192.168.4.0 255.255.255.0 172.16.70.0 255.255.255.0

access-list outside_cryptomap_20 extended permit ip 192.168.4.0 255.255.255.0 10.42.0.0 255.255.0.0

global (outside) 1 interface

nat (inside) 0 access-list inside_nat0_outbound

nat (inside) 1 access-list allownatout

nat (inside) 0 10.20.4.161 255.255.255.255

nat (dmz) 1 access-list allowdmzout

static (inside,dmz) 10.20.4.161 10.20.4.161 netmask 255.255.255.255

static (inside,dmz) 10.20.4.140 10.20.4.140 netmask 255.255.255.255

static (inside,dmz) 10.0.0.0 10.0.0.0 netmask 255.0.0.0

static (inside,dmz) 192.168.4.0 192.168.4.0 netmask 255.255.255.0

static (inside,dmz) 192.168.5.0 192.168.5.0 netmask 255.255.255.0

access-group outside_incoming in interface outside

access-group dmz_out in interface dmz

route outside 172.22.4.0 255.255.255.0 ******** 1

route outside 0.0.0.0 0.0.0.0 ******** 1

route inside 192.168.200.0 255.255.255.0 10.20.99.36 1

route inside 192.168.4.0 255.255.255.0 10.20.99.36 1

route inside 192.168.100.0 255.255.255.0 10.20.99.36 1

route inside 10.20.4.140 255.255.255.255 10.20.99.36 1

route inside 10.20.4.141 255.255.255.255 10.20.99.36 1

route inside 10.0.107.0 255.255.255.0 10.20.99.36 1

route inside 10.0.0.0 255.0.0.0 10.20.99.36 1

route inside 10.20.4.128 255.255.255.128 10.20.99.36 1

route inside 10.20.4.161 255.255.255.255 10.20.99.36 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

timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout uauth 0:05:00 absolute

!

!

policy-map global_policy

class inspection_default

inspect dns maximum-length 512

inspect ftp

inspect h323 h225

inspect h323 ras

inspect netbios

inspect rsh

inspect rtsp

inspect skinny

inspect sqlnet

inspect sunrpc

inspect tftp

inspect sip

inspect xdmcp

inspect esmtp

inspect http

inspect icmp

!

service-policy global_policy global

Cryptochecksum:9ac58aa592c9a77984d18af3b5864def

: end

John Blakley Mon, 12/15/2008 - 09:48

Ron,

You'll need to have an access list applied to your inside interface for your dmz to be able to access it.

Try creating one that allows everything for the time being, and then apply it to the inside interface.

HTH,

John

cisco24x7 Mon, 12/15/2008 - 10:44

why does he need access-list applies on the

inside interface? The default is that "inside"

has the priority of 100 so it can go just about

everywhere?

John Blakley Mon, 12/15/2008 - 10:46

Maybe I read it wrong, but his original statement:

"I am unable to ping from 172.20.0.6 to any of the 192.162.4 or 5 addresses."

Tells me that he's trying to go from DMZ (lower security) to inside (higher security) meaning he needs an ACL to allow that traffic through. Am I incorrect?

John

ronshuster Mon, 12/15/2008 - 10:54

That is correct, I am unable to ping from 172.20.0.6 which is on the dmz to the inside segments 192.168.4.0 & 192.168.5.0.

I have an ACL that ends with permit ip any any on all incoming traffic to the dmz

access-list dmz_out extended permit tcp host 172.20.0.35 host 10.20.4.161 eq smtp

access-list dmz_out extended permit tcp host 172.20.0.35 eq smtp host 10.20.4.161

access-list dmz_out extended permit ip any any

should this not allow traffic from the dmz access the inside?

Also I have the translations for the two inside segments:

static (inside,dmz) 192.168.4.0 192.168.4.0 netmask 255.255.255.0

static (inside,dmz) 192.168.5.0 192.168.5.0 netmask 255.255.255.0

What else is required to allow traffic from the dmz to the inside?

John Blakley Mon, 12/15/2008 - 10:58

Can you ping to a host in the DMZ from an inside host? Does that part work?

John Blakley Mon, 12/15/2008 - 11:04

Ron,

I also noticed that your 192.168.4.0 subnet gets routed through another device at 10.x.x.36. Is this a proxy server or another router?

John

Jon Marshall Mon, 12/15/2008 - 11:11

Ron

Your 192.168.4.x and 192.168.5.x subnets are not directly connected to the ASA inside interface.

So you need to check the routing back to the ASA ie. do your 192.168.4 & 5.x clients know how to route back to 172.20.0.x network.

As John has asked what is device 10.20.99.36 and does this device know how to route to 172.20.0.x network.

Try ping 10.20.99.36 from the DMZ, does it work or not ?

Also try ping 192.168.4.x client from the ASA - does that work ?

By the way you don't need an acl applied to the inside interface.

Jon

John Blakley Mon, 12/15/2008 - 11:19

Also, I think you can remove:

nat (inside) 0 access-list inside_nat0_outbound

I don't see that ACL anywhere. And yes, you don't need the ACL. I was mistaken, and I've since looked at another config to see what I was thinking and it was something totally different. :-)

John

ronshuster Mon, 12/15/2008 - 12:29

I can ping from the inside to the dmz, ie. server from 192.168.4.0 can ping 172.20.0.6

but not the other way (this is where the problem is)

routes from the firewall to the internal network is 10.20.99.36, that is a demarc vlan between the core switches and the firewall where 10.20.99.36 is the hsrp address on the core (cat6500)

192.168.4.x & 192.168.5.x are routed on the core switches

the real ip address of the demarc vlan (10.20.99.34) CAN ping 172.20.0.6

but again, not the other way

I did not try to ping the demarc vlan (10.20.99.36) from the dmz (172.20.0.6), but again, the other way works.

Take a look at this example (DMZ to Inside):

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807fc191.shtml

I noticed that the static nat here is different than what I have. In my config I am not doing any translation, ie:

static (inside,dmz) 192.168.4.0 192.168.4.0 netmask 255.255.255.0

static (inside,dmz) 192.168.5.0 192.168.5.0 netmask 255.255.255.0

where on their example (URL) they are translation, ie:

ASA-AIP-CLI(config)# static (inside,DMZ) 192.168.2.20 172.20.1.5 netmask 255.255.255.255

That is the only difference I can find between the two

Jon Marshall Mon, 12/15/2008 - 12:46

Can you add this to your config and retry

access-list nonat permit ip 172.20.0.0 255.255.255.0 192.168.4.0 255.255.255.0

access-list nonat permit ip 172.20.0.0 255.255.255.0 192.168.5.0 255.255.255.0

nat (dmz) 0 access-list nonat

Jon

John Blakley Mon, 12/15/2008 - 12:50

Jon,

In your example, does:

static (inside, dmz) 192.168.4.0 192.168.4.0 netmask 255.255.255.0

OR

static (inside, dmz) 172.20.0.0 192.168.4.0 netmask 255.255.255.0

do the same thing as your example?

Thanks!

John

Jon Marshall Mon, 12/15/2008 - 13:01

John

Reason i suggested the addition was because of this line in the config -

nat (dmz) 1 access-list allowdmzout

and the accompanying acl -

access-list allowdmzout extended permit ip 172.20.0.0 255.255.255.0 any

This is quite unusual in that usually on the DMZ you have servers you want accessed from the Internet so you can't use dynamic NAT as above, you need static statements.

So i was wondering if a connection initiated from the DMZ hit the nat statement on the dmz interface but then found no corresponding global statement on the inside interface. Note that traffic destined to 192.168.4/5.x would match the acl above. So i suggested a nat exemption for traffic from the DMZ to the inside. Not 100% sure it will work but i suspect this is the issue.

In answer to your direct question neither statement matches what i have suggested -

static (inside, dmz) 192.168.4.0 192.168.4.0 netmask 255.255.255.0

means 192.168.4.x is presented as 192.168.4.x to the DMZ and the dmz can initiate connections to 192.168.4.x from the DMZ.

static (inside, dmz) 172.20.0.0 192.168.4.0 netmask 255.255.255.0

means 192.168.4.x addresses are presented to the DMZ as 172.20.0.x addresses and the dmz can initiate connections to 172.20.0.x when it wants to talk to 192.168.4.x. Clearly there would be a problem with this in that 172.20.0.x is already in use on the DMZ so you could either

1) map individual 192.168.4.x addresses to UNUSED 172.20.0.x addresses on the DMZ

OR

2) Use a totally different subnet instead of 172.20.0.x

Jon

John Blakley Mon, 12/15/2008 - 12:48

You can do a couple of things:

Do a show xlate and look for the translation. If it's not there, try to run "clear xlate." (you'll lose existing connections, but they rebuild quickly.)

If you see the translation, try to run debug icmp trace. Ping the 192.168.4.0 host, and see what the firewall is reporting. If it's a translation issue, it will tell you.

HTH,

John

ronshuster Tue, 01/13/2009 - 09:26

Jon,

On your last reply you mentioned the following:

nat (dmz) 1 access-list allowdmzout

and the accompanying acl -

access-list allowdmzout extended permit ip 172.20.0.0 255.255.255.0 any

This is quite unusual in that usually on the DMZ you have servers you want accessed from the Internet so you can't use dynamic NAT as above, you need static statements.

If there are no dynamic translations, how would a dmz device access the Internet?

In most cases DMZ nodes are accessed from the Internet but at the same time they require access to the Internet as well (to be initiated), how would you do that if not for the dynamic translation, ie. see nat above as well as the allowdmzout ACL.

Not sure if my problem is still solved, I have asked someone to initiate traffic from the DMZ to the inside (192.168.4.x) and I will then check the debug icmp as l.blakley suggested.

I didn't think that allowing a DMZ device access to a specific host or vlan restricted to a given port(s) is so complicated.

hunnetvl01 Wed, 01/14/2009 - 10:44

I have the same struggle with a PIX 6.3 , so dont worry its pretty complicated as in " IT DOESNT FRICKIN' WORK!"..

Anyway good luck with this!

Try this maybe :

NAT (DMZ) 1 172.20.0.0 255.255.0.0 outside

Global(Inside) 1 interface

For me it did not work, but people say it did the job for them...

Vlad

Actions

This Discussion