DMZ to INSIDE access

[ronshuster]

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?

[Jon Marshall]

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]

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]

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]

Thanks for the explanation Jon.

John

[John Blakley]

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]

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]

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