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

DigitalMess

In article <. com>,
DigitalMess <> wrote:
>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.

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)

Walter Roberson wrote:
> In article <. com>,
> DigitalMess <> wrote:
> >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.
>
> 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)


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

Walter Roberson wrote:
> In article <. com>,
> DigitalMess <> wrote:
> >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.
>
> 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)


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

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

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
> configs could be in place that would stop traffic from being routed to
> DMZ or 192.168.0.4?

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.

In article < .com>,
DigitalMess <> wrote:

>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

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.


>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?

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 ?

chris wrote:
> > 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
> >
>
> 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
> > configs could be in place that would stop traffic from being routed to
> > DMZ or 192.168.0.4?
>
> 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.

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