1. Home
  2. Cisco Systems
  3. Help with creating DMZ on PIX 515E

Help with creating DMZ on PIX 515E

I need some help with setting up my DMZ on a PIX515E.

We have a 515E with an outside address of 72.240.45.X7 and I want to set up a webserver in the DMZ on 72.240.45.X8. That points to an internal webserver that's connected to DMZ Interface 192.168.0.1. The Webserver internal address is 192.168.0.4.

I've tried a whole bunch of crap and can't seem to get the outside to send or receive from the DMZ but our Outside to Inside is functioning just fine with a nat to 72.240.45.X9. If someone can help me out. Reply and include your e-mail address so I can share our firewall configs.

Thanks, Aaron

Reply to
DigitalMess
Loading thread data ...

static (dmz,outside) 72.240.45.X8 192.168.0.4

access-list Outside_ACL permit tcp any host 72.240.45.X8 eq http access-group Outside_ACL in interface outside

Note: In theory, you will only need an access-group applied to the DMZ interface if you intend to initiate traffic from the DMZ to the inside interface. In practice, especially before PIX 6.3 (but somewhat in 6.3 as well) the PIX does not always notice which icmp messages (e.g., icmp unreachable) are "replies" to traffic initiated from the inside, so it is more robust to specifically permit upwards icmp 3 (unreachable) and 11 (TTL exceeded) and possibly icmp 0 (echo reply)

Reply to
Walter Roberson

Ok, here's what I had in place and wasn't working for me

static (dmz,outside) 72.240.45.X8 192.168.0.4 netmask 255.255.255.255 0

0 access-list acl_out; 3 elements access-list acl_out line 1 permit icmp any any (hitcnt=93) access-list acl_out line 2 permit ip any any (hitcnt=416) access-list acl_out line 3 permit tcp any host 72.240.45.X8 eq 85 (hitcnt=0) access-group acl_out in interface outside

Yes, temporarily I changed our webserver port from 80 to 85, so I could do static port redirects from our Outside to Inside since DMZ didn't want to cooperate... Maybe that's part of the problem. What possible configs could be in place that would stop traffic from being routed to DMZ or 192.168.0.4?

Aaron

Reply to
DigitalMess

Ok, here's what I had in place and wasn't working for me

static (dmz,outside) 72.240.45.X8 192.168.0.4 netmask 255.255.255.255 0

0 access-list acl_out; 3 elements access-list acl_out line 1 permit icmp any any (hitcnt=93) access-list acl_out line 2 permit ip any any (hitcnt=416) access-list acl_out line 3 permit tcp any host 72.240.45.X8 eq 85 (hitcnt=0) access-group acl_out in interface outside

Yes, temporarily I changed our webserver port from 80 to 85, so I could do static port redirects from our Outside to Inside since DMZ didn't want to cooperate... Maybe that's part of the problem. What possible configs could be in place that would stop traffic from being routed to DMZ or 192.168.0.4?

Aaron

Reply to
DigitalMess

From a security point of view you just opened up ALL traffic to any host with a static translation! Notice that your third line in the acl doesn't have any hits as everything is being matched on line 2 (ip any any). Oops!

What possible

Well, if the static is correct then the acl is allowing all traffic in. From the web server can you access the internet? If you can then is it's IP address translated to the same external as the static says that it should be?

Chris.

Reply to
chris

icmp is a subset of ip, and tcp is a subset of ip, so your second ACL line makes the other two redundant. You are never going to get any hits on the third line of your ACL because that case is completely covered by your second line.

Hypothetically, a conflicting static or conflicting DHCP pool or conflicting crypto map match address ACL. And, of course, the usual suspects such as mismatches between the subnet mask of the DMZ interface and that of the DMZ hosts, or the gateway (or default route) not having been set properly on the DMZ host.

What shows up if you debug icmp trace and then ping

72.240.45.X8 ?
Reply to
Walter Roberson

Chris,

I actually got it up and working but removing the ACL_OUT and changing to Outside_ACL. Now my problem is with not getting DNS resolves out from the DMZ interface. If I run the route command it'll hang for a couple minutes and then complete. But I can do any dns resolves. I have the default gateway to 192.168.0.1 and did manual DNS name server entries in resolv.conf. So I'm suspecting that I have to allow the DMZ interface to perform nameserver queries? Or what else might cause it not to route correctly?

Here's the output of my route command:

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface localnet * 255.255.255.0 U 0 0 0 eth0

10.0.0.0 * 255.255.252.0 U 0 0 0 eth1 loopback * 255.0.0.0 U 0 0 0 lo default 192.168.0.1 0.0.0.0 UG 1 0 0 eth0

What gets me is that the metric is 1 and not 0 like the reset are, so could that be part of the problem?

Thanks for everyone's help! Aaron

Reply to
DigitalMess

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.