From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Fri Jun 11 2004 - 17:39:06 GMT-3
Ken,
> Are you saying your access-list cannot be only "evaluate" statements
> with an implicit "deny-all" at the end?
It can, but with sometimes unpredictable results. Remember that
in IOS an empty access list is an implicit permit. There used to be a
problem in older versions when you had an access-list that said just
"evaluate REFLECT". I just tested it in 12.2T and it's fine, but I'm
not sure what version it was fixed in. The problem was as follows.
The "evaluate" statement in the access-list is basically a
pointer to another access-list. More specifically it is a pointer to a
reflexive list that is dynamically generated based on traffic going
through "reflect" statements. Suppose your access-list read as follows:
ip access-list extended INBOUND
evaluate REFLECT
When traffic attempts to go through the list INBOUND applied on
the interface, the packet is checked against the reflexive list REFLECT.
The caveat was that if no traffic had yet to be reflected to the
reflexive list (REFLECT in this case), the list was treated as empty,
and hence implicit permit. This meant that all traffic was allowed to
come into the network until a point in time at which traffic exited and
was reflected.
While not documented (as far as I can tell) this is the reason
why in the CCO examples for reflexive lists you see something like this:
ip access-list extended INBOUND
evaluate REFLECT
deny ip any any
or other non-empty list configurations. With the empty list you
run the risk of letting traffic into the network during periods that the
reflexive list is empty. By simply adding lines you are working around
this.
Again this problem is version dependent, and as I just checked
it today it's fixed in at least 12.2(15)T.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
> -----Original Message-----
> From: Kenneth Wygand [mailto:KWygand@customonline.com]
> Sent: Friday, June 11, 2004 8:38 AM
> To: Zachary Hinz; Brian McGahan; richard.dumoulin@vanco.es;
> ccie2be@nyc.rr.com; ccielab@groupstudy.com
> Subject: RE: icmp filtering
>
> Hey Zachary,
>
> I'm a little confused by your statement "Finally it hit me to try to
> apply
> further ACL statements after the "evaluate" statement. Seems simple,
> but
> you won't see it on the DOC page, and if you aren't experienced with
> them
> configuring them you wouldn't know you could do it."
>
> Are you saying your access-list cannot be only "evaluate" statements
> with an implicit "deny-all" at the end?
>
> Sorry, I haven't had much experience with reflexive ACLs to this
point.
>
> TIA,
>
> Kenneth E. Wygand
> Systems Engineer, Project Services
> CISSP #37102, CCNP, CCDP, ACSP, Cisco IPT Design Specialist, MCP, CNA,
> Network+, A+
> Custom Computer Specialists, Inc.
> "The only unattainable goal is the one not attempted."
> -Anonymous
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Zachary Hinz
> Sent: Tuesday, June 08, 2004 11:22 PM
> To: bmcgahan@internetworkexpert.com; richard.dumoulin@vanco.es;
> ccie2be@nyc.rr.com; ccielab@groupstudy.com
> Subject: OT: icmp filtering
>
> This is why this forum is so great. In my job I have to implement
some
> pretty weird stuff to get everything working the way that is expected.
>
> I just had to apply a reflexive ACL to create a pseudo DMZ, which
needed
>
> Internet access, and couldn't figure out how to get it done exactly
> right
> with the examples given on the DOC page. Finally it hit me to try to
> apply
> further ACL statements after the "evaluate" statement. Seems simple,
> but
> you won't see it on the DOC page, and if you aren't experienced with
> them
> configuring them you wouldn't know you could do it. Long story
> short...You're always learning!
>
> Zac
> 12419
>
>
> ----Original Message Follows----
> From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> Reply-To: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> To: "Richard Dumoulin" <richard.dumoulin@vanco.es>, "ccie2be"
> <ccie2be@nyc.rr.com>, "Group Study" <ccielab@groupstudy.com>
> Subject: RE: icmp filtering
> Date: Tue, 8 Jun 2004 18:16:51 -0400
>
> inside network - R5 - outside network
> behind R5 - R5 - in front of R5
>
>
> It says behind because it's not asking for locally generated.
> Since an
> outbound access-list does not match locally generated traffic, it
cannot
> be
> evaluated without additional configuration, such as local policy
> routing.
>
> See this thread for more info:
>
> http://www.groupstudy.com/archives/ccielab/200311/msg01170.html
>
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
>
> ________________________________________
> From: Richard Dumoulin [mailto:richard.dumoulin@vanco.es]
> Sent: Tuesday, June 08, 2004 5:10 PM
> To: Brian McGahan; ccie2be; Group Study
> Subject: RE: icmp filtering
>
> Something I usually find confusing is "behind R5". How do you know
what
> is
> behind and not ?
> Normally by using common sense I deduct that ICMP initiated from the
> inside
> should be allowed to return from the outside but the word "behind"
> confuses
> me,
> --Richard
> -----Original Message-----
> From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> Sent: miircoles, 09 de junio de 2004 0:02
> To: ccie2be; Group Study
> Subject: RE: icmp filtering
>
> Tim,
> What about the question and solution implies this? The
> question
> says:
> "Configure your network so that ICMP traffic is only allowed into your
> network if the traffic was initiated from behind R5. For diagnostic
and
>
> troubleshooting purposes, ensure that users throughout your network
are
> still able to traceroute from behind R5."
> The solution is:
> R5:
> interface Ethernet0/1
> ip access-group DENY_SNMP in
> ip access-group EVALUATE_ICMP out
> !
> ip access-list extended DENY_SNMP
> deny udp any any eq snmp
> permit icmp any any time-exceeded
> permit icmp any any unreachable
> evaluate ICMP
> deny icmp any any
> permit ip any any
> !
> ip access-list extended EVALUATE_ICMP
> permit icmp any any reflect ICMP
> permit ip any any
> Essentially you are watching ICMP traffic that is exiting:
> permit icmp any any reflect ICMP
> and you are allowing it back in only if was initiated from
the
> inside:
> evaluate ICMP
> deny icmp any any
> but you are allowing trace replies back:
> permit icmp any any time-exceeded
> permit icmp any any unreachable
> How does this relate to echo or echo-reply?
> HTH,
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
Behalf
> Of
> > ccie2be
> > Sent: Tuesday, June 08, 2004 4:40 PM
> > To: Group Study
> > Subject: icmp filtering
> >
> > Hi guys,
> >
> > I hope this isn't too dumb a question, but...
> >
> > Can someone confirm what this acl entry does?
> >
> > ip access-list ext ping
> > permit (or deny) icmp any any <-----
> >
> > In particular, does this allow all icmp message types or just
> echo-request
> > and
> > echo-reply?
> >
> > I've search the Doc Cd and the whole of cisco.com but couldn't find
> > anything definative.
> >
> > I would think it would allow ( or deny) all icmp message types but,
> I'm
> > doing
> > practice IE lab 2, task 10.8 - 10.10 and the solution seems to
> indicate
> > that
> > it only permits message types echo-request and echo-reply.
> >
> > Any feedback would be appreciated. Also, if someone knows of any
> links
> > which
> > discusses in detail, please let me know.
> >
> > TIA, Tim
> >
> >
>
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:38 GMT-3