PIX not allowing traffic from Inside Interface to device in DMZ

[Kevin Melton]

I am working at a client site. We have an issue where a PIX Firewall is not allowing access to a device in a DMZ network from devices on the Inside interface.

Here are the security levels of the interfaces:

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 DMZ security50

Network 172.16.43.0 is off of the inside interface. Network 192.168.155.0 is the DMZ (DMZ interface address is 192.168.155.1).

I have ran captures this morning and determined that 1) traffic destined for a device in the 192.168.155.0 network makes it to the inside interface and 2) traffic seen on the inside interface for this device never makes it into the DMZ.

There is not an ACL in place on the DMZ interface, and right now I cannot determine why the Firewall is blocking this traffic.

I am going to include the running configuraton of this.

The device we are trying to connect to is 192.168.155.6. The device we are trying to connect from is 172.16.43.144.

[acomiskey]

static (inside,DMZ) 172.16.43.0 172.16.43.0 netmask 255.255.255.0

[Kevin Melton]

thanks for the response. I implemented the static tranlsation as published, but unfortunantly it did not resolve the issue. We still cannot get from 172.16.43.144 to 192.168.155.6.

This is a very strange problem. I ran "capture" on the inside interface, and was able to see frames on that interface destined for 192.168.155.6. I then placed the capture on the DMZ interface, and you never see the frames. I am not sure why the FW is blocking...

[javzone]

please add a static route for dmz network

route dmz 192.168.155.0 255.255.255.0 nexthop (ip add)

HTH

[Kevin Melton]

should the ip address for next hop (ip add) be the address of the device in the dmz? or the IP address of the dmz interface on the PIX?

thx

[acomiskey]

192.168.155.0 is directly connected, you do not need a route to it.

[Kevin Melton]

You are exactly correct. It displayed the following when I tried to add the route the other gentleman suggested:

ODEC-RS-FW(config)# route dmz 192.168.155.0 255.255.255.0 192.168.155.6

Route already exists

ODEC-RS-FW(config)# route dmz 192.168.155.0 255.255.255.0 192.168.155.1

Route already exists

ODEC-RS-FW(config)# sho route

outside 0.0.0.0 0.0.0.0 24.154.93.1 1 OTHER static

outside 24.154.93.0 255.255.255.0 24.154.93.12 1 CONNECT static

inside 172.16.43.0 255.255.255.0 172.16.143.2 1 OTHER static

inside 172.16.143.0 255.255.255.252 172.16.143.1 1 CONNECT static

DMZ 192.168.100.7 255.255.255.255 192.168.155.6 1 OTHER static

DMZ 192.168.155.0 255.255.255.0 192.168.155.1 1 CONNECT static

ODEC-RS-FW(config)#

acomiskey - - do you have any other recommendations as to what to configure next. We are really stuck on this issue...

Thanks!

[acomiskey]

Please post your new configuration.

Take this line out, you don't need it...

no access-list DMZ_nat0_outbound permit ip 192.168.155.0 255.255.255.0 172.16.43.0 255.255.255.0

[Kevin Melton]

acomiskey

At present it seems that negating the ACL statement that you recommended may have resolved the problem. I need to confirm this by the local users on that site.

I will update you once this is confirmed and mark post "resolved issue"

Thanks for your guidance with this!

[acomiskey]

The reason you don't need that nat 0 on the dmz interface is because you already had one defined on the inside interface for the traffic between .43 and .155. So you have 2 options here...

nat (inside) 0 access-list nonat

access-list nonat extended permit 172.16.43.0 255.255.255.0 192.168.155.0 255.255.255.0

OR another way to accomplish the same thing...

static (inside,DMZ) 172.16.43.0 172.16.43.0 netmask 255.255.255.0