From: Jeff K. (jeffbk@xxxxxxxxxxxxx)
Date: Sat Apr 28 2001 - 12:28:55 GMT-3
Here is a (hopefully) better summary of what I was trying to say. My PIX
behaves totally as expected. If the conduit is not there, which it normally
isn't, I cannot ping anything at all, including inside to DMZ or inside to
outside. This is the expected behavior. I had someone trying to tell me
that icmp is included in the PIX's design of allowing responses to
inside-initiated sessions (like tcp / udp), but this is simply not true from
my experience. That is definitely the easiest piece of PIX setup info to
find and one of the easiest things to test... Anyway, when I put the
conduit in place, I can ping everything that I should be able to ping. The
only point to saying I can ping the outside of the PIX from the outside
(i.e., my border router) was because someone was saying this couldn't be
done. I have it filtered on the outside of my border router, but the PIX
will definitely respond to it by default if the echo makes it there. The
'odd' point I was talking about is when you take an inside host and try to
ping the PIX's outside interface (not a host on the outside subnet, which
works fine, but the PIX's outside address itself), which was the question in
the original post that I responded to. This ping fails consistently and
reproducibly. There are no routing issues at all in this design nor are
there any icmp filters from inside to outside when this is tested. No IP
ACLs on the inside router, the conduit permit icmp any any in the PIX, the
correct route <inside / outside> statements in the PIX, etc. Connectivity
is confirmed by the inside host pinging the PIX inside, DMZ hosts, outside
host; the outside pinging the PIX outside; and the PIX being able to ping
the inside router, inside hosts, and outside hosts. Pretty standard / ideal
setup (once the ACLs are put back in place, of course). NAT is also
configured properly. About the ping that fails: I remembered reading an
article on CCO that said this is basically because of the way IP works. It
said that the PIX's inside will receive the icmp echo packet destined for
the PIX's outside interface. Being destined for a subnet off the outside
interface, it then forwards it according to its ip route <outside> statement
(sort of like a frame interface without a map statement trying to ping its
own serial interface -- it forwards it across the wire). In turn, this next
hop looks at the packet, realizes it is destined for the same subnet on
which it was received, and does nothing to it and it is dropped -- Yes,
comparable to split horizon, I suppose. The point is, it never gets back to
the PIX so the PIX doesn't respond. Since the PIX is not doing any routing,
I think this makes sense. I would think the PIX won't respond to packets
destined for it's outside interface unless received by the outside
interface, which is why it forwards these packets. This also makes sense
considering the PIX's outside interface responds to the outside hosts. If
this is a security design to not respond to pinging the PIX's outside
interface, it seems backward -- wouldn't it be better to disallow pings from
the untrusted network as default behavior if that was the intent? Anyway,
like I said, I just remember reading an article discussing on CCO, but I
can't find it; but, I will try to mess around with some debugs when I can.
This may not be the reason for this behavior - just like everyone else here
I have learned to take things with a grain of salt. But, like I said, it
really does seem like a plausible reason to me. If anyone has any ideas,
let me know. We are all here to learn...
Take care,
-Jeff
BTW, I am back to using my personal e-mail (this one) for the list instead
of my work address (the original post).
----- Original Message -----
From: "Todd Veillette" <tveillette@home.com>
To: <Jeff.Kline@ci.austin.tx.us>
Cc: <ccielab@groupstudy.com>
Sent: Friday, April 27, 2001 8:19 PM
Subject: Re: pix firwall
> I disagree with your forwarding theory. With a standard "conduit permit
icmp
> any any" all hosts all interfaces are reachable. There can be other
external
> factors that would not allow reachability, all of which are solvable.
>
> ----- Original Message -----
> From: <Jeff.Kline@ci.austin.tx.us>
> To: <chris@pacinter.net>; <Steve.Munro@integralis.com>;
> <ccielab@groupstudy.com>
> Sent: Friday, April 27, 2001 12:53 PM
> Subject: RE: pix firwall
>
>
> > Sure it will. I have security 0 on the outside and I can ping from the
> edge
> > router's inside interface to the PIX outside with no problem (even
without
> > the permit icmp conduit). All other outside sourced pings fail, as they
> > should without the conduit. I will try to find the link on CCO, but I
am
> > pretty sure that the problem is with the PIX forwarding that ping
request
> to
> > the outside subnet, where it gets dropped.
> >
> > -----Original Message-----
> > From: chris@pacinter.net [mailto:chris@pacinter.net]
> > Sent: Friday, April 27, 2001 11:04 AM
> > To: Kline, Jeff; Steve.Munro@integralis.com; ccielab@groupstudy.com
> > Subject: Re: pix firwall
> >
> >
> > The PIX will not respond to a ping to its local interface with the
> security
> > 0 command in place for that interface. Make sure the DMZ interface your
> > trying to ping is not in security 0
> > ----- Original Message -----
> > From: <Jeff.Kline@ci.austin.tx.us>
> > To: <Steve.Munro@integralis.com>; <ccielab@groupstudy.com>
> > Sent: Friday, April 27, 2001 8:41 AM
> > Subject: RE: pix firwall
> >
> >
> > > Actually, the icmp conduit must be open already since the original
> e-mail
> > > says that ping from inside to an outside host works. If I remember (I
> > read
> > > something about this on CCO, but can't seem to find it today), this is
> > more
> > > an issue with the way the IP packets are forwarded in the PIX.
> Basically,
> > > the PIX will receive your inside packet with a destination of the
> outside
> > > subnet (specifically it's outside interface). The PIX then forwards
> this
> > to
> > > the next hop you defined in your ip route outside statement (yes, even
> > > though it is for it's own interface), but you border router looks at
it
> as
> > > being destined for that locally connected subnet, so it does not
forward
> > > back to the pix and the packet is dropped. If you are trying to test
> PIX
> > > connectivity, just make sure that your inside host can ping the PIX
> inside
> > > and the PIX can ping the outside next hop. I'm not sure why the PIX
> > doesn't
> > > just respond to the ping instead of forwarding that packet...
> > >
> > > -----Original Message-----
> > > From: Steve Munro [mailto:Steve.Munro@integralis.com]
> > > Sent: Friday, April 27, 2001 5:34 AM
> > > To: ccielab
> > > Subject: FW: pix firwall
> > >
> > >
> > > -----Original Message-----
> > > From: Steve Munro
> > > Sent: Friday, April 27, 2001 10:50 AM
> > > To: 'dongbiao lee'
> > > Subject: RE: pix firwall
> > >
> > >
> > > Unless you explicitly allow a ping to the firewall it will be denied -
> > > standard security policy
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: dongbiao lee [mailto:dongbiao@yeah.net]
> > > Sent: Friday, April 27, 2001 10:41 AM
> > > To: ccielab@groupstudy.com
> > > Subject: pix firwall
> > >
> > >
> > > i devide the network into three zones: inside,dmz and outside.
> > > ican ping from a pc in the inside zone to the pc in the outside zone,
> but
> > i
> > > can't ping
> > > from the inside pc to the pix interface of the outside. why?
> > >
> > > dongbiao lee
> > > dongbiao@yeah.net
> > > **Please read:http://www.groupstudy.com/list/posting.html
> > > Integralis
> > > Theale House
> > > Brunel Road
> > > Theale, Reading
> > > RG7 4AQ
> > > +44 (0) 118 9306060
> > >
> > > A member of the Articon-Integralis Group
> > >
> > > info@Integralis.com
> > > http://www.integralis.com
> > >
> > >
> > > DISCLAIMER
> > > Any opinions expressed in this email are those of the individual and
not
> > > necessarily the Company. This email and any files transmitted with it,
> > > including replies and forwarded copies (which may contain alterations)
> > > subsequently transmitted from the Company, are confidential and solely
> for
> > > the use of the intended recipient. It may contain material protected
by
> > > attorney-client privilege. If you are not the intended recipient or
the
> > > person responsible for delivering to the intended recipient, be
advised
> > that
> > > you have received this email in error and that any use is strictly
> > > prohibited.
> > >
> > > If you have received this email in error please notify the IT manager
by
> > > telephone on +44 (0)118 930 6060 or via email to
> > > internal.security@integralis.com, including a copy of this message.
> Please
> > > then delete this email and destroy any copies of it.
> > > **Please read:http://www.groupstudy.com/list/posting.html
> > > **Please read:http://www.groupstudy.com/list/posting.html
> > **Please read:http://www.groupstudy.com/list/posting.html
> **Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:30:00 GMT-3