From: ccie2be (ccie2be@nyc.rr.com)
Date: Fri Jun 11 2004 - 12:39:45 GMT-3
Hey Ken et al,
I was also confused - probably in the same way as Zach.
I mistakenly thought that once a paket was evaluated against the evaluate
<name> command, if the packet was denied, that was it. Processing stopped.
End of story.
But, that is totally wrong. Here's why.
The reflect keyword and evaluate command work together. Although I don't
know the exact details, what happens, in essense, is this.
Assume there's an acl inbound and an acl outbound on an interface. In the
outbound acl, there are entries which include the reflect keyword. And, of
course, in the outbound acl, there's an evaluate command.
When a packet that matches the criteria of the entry with the reflect
keyword in it leaves the interface, the reflect keyword causes a temporary
entry to be "reflected" to a state table. What also happens (in effect, if
not in actuality) is that a temporary permit entry is created on the inbound
acl that is the mirror image of the state table entry, so that when a packet
comes in it's evaluated against all the entries in the inbound acl. The
entries in the inbound acl can be a combo of static entries that were
manually entered and dynamic entries put in there as a result of the reflect
and evaluate commands.
Note that there can be many entries in the outbound acl that include the
reflect <name> keyword, but there's only one entry in the inbound acl that
includes the evaluate <name> entry.
So, as a result, if there are, for example, 4 entries in the outbound acl
with the reflect test1 keywords, the single evaluate test1 entry in the
inbound acl creates 4 permit entries. I don't know if this is exactly how
it happens in the router, but you can think of the evaluate <name> as a
shortcut way of creating temporarily an appropriate mirror image permit
entry for each outbound acl entry with the reflect <name> keywords.
Then acl processing occurs as normal. So, when a packet comes into the
interface, it's processed against the inbound acl which includes the static
entries which were entered manually and the dymanic entries put in there by
the combo of the reflect and evaluate. And, just like when a packet doesn't
match a particular permit statement in a regular acl, the packet is then
evaluated against the next entry in the acl. The same thing happens whether
or not the entries were put in statically or dynamically. Therefore, when a
packet comes into the interface, it's evaluated against all the entries,
static or dynamic, in the order in which the entries are entered. If a
packet is evaluated against the last dynamic entry and it doesn't match that
entry, if there's another entry, then the packet will be evaluated against
that next entry. This continues until the either the packet matches a
particular entry and is denied ot permitted based on that entry or until
there are no more entries against which to evaluate the packet and is denied
by virtue of the implicit deny any at the end of all acl's.
There's a great example of this in the IE workbook in labs 2 and 3. (If
anyone is planning on taking the real lab and doesn't already have this
workbook, I strongly recommend they invest in this workbook. It's only $200
bucks and it has some of the best examples I've seen anywhere.) It took me a
while to fully understand why each entry was there. But, once I did, it made
perfect sense.
Consider this example:
The requirement is to allow pings and traceroutes that originate from within
the network to get back in while denying pings and snmp from the outside
from getting in.
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
***********************************
First consider the EVALUATE_ICMP acl. This acl is applied in the outbound
direction. Because of the first entry, "permit icmp", a temporary permit
entry is made to the inbound acl, DENY_SNMP. If you think, like I did, that
the inbound entry would look like "permit icmp any any", you would be wrong.
The inbound entry will create a mirror image of the ACTUAL ping packet(s)
that went out. In other words, it would have the ACTUAL source and
destination ip addresses that were in the outbound ping packet EXCEPT the
source and destination addresses are swapped. And, it's against these actual
swapped ip addresses that the inbound ping packets are processed. If the
inbound ping packet matches the temporory permit created by the reflect ICMP
statement, they'll be let back in, otherwise they'll be dropped. As a
result, not any ping packet is allowed in - only a ping packet that is a
response ping and therefore a mirror image of the ping packet that went out
is allowed back in.
That's why the "deny icmp any any" statement is needed after the evaluate
command in the inbound acl. The "evaluate ICMP" statement allows pings that
originated from within the network back in. The "deny icmp any any"
statement that follows prevents any pings that originate from outside from
getting in.
At this point, the ping part of the requirement is taken care of. Pings
that originate from inside can get back in and pings that originate from
outside can't get in.
Now, consider the traceroute part of the requirement. As you know, cisco's
traceroute uses udp packets. Since nothing in the outbound acl prevent udp
packets, they can transit the interface. Now, keep this in mind. When
cisco traceroute begins, it will set the ttl to one in the first upd packet.
When the first router gets this udp, it will decrement the ttl to zero and
send back icmp time-exceeded packet. That's why there's the "permit icmp
any any time-exceeded" in the inbound acl. The next udp packet will have
the ttl set to 2. If the destination ip address still isn't reached,
another icmp time-exceeded packet will be sent back. This continues until
the destination ip address is reached. Once that happens, an icmp
"unreachable" packet will be sent back. This is because cisco traceroute
sends the udp packet to an unreachable port number. And, that's why you see
the "permit icmp any any unreachable" statement.
One last thing to note. I've mentioned several times that the reflect
keyword creates a TEMPORARY entry in the inbound acl. But, how long is
temporary? By default, it's 300 seconds, but this can be changed globally
with "ip reflexive-list timeout <seconds> or on per entry basis by adding
the timeout <seconds> keyword to the end of the staement. This is important
because, unlike TCP, which can end a connection with the reset bit set, udp
and other type packets don't have such a capability.
HTH, Tim
----- Original Message -----
From: "Kenneth Wygand" <KWygand@customonline.com>
To: "Zachary Hinz" <z_hinz@hotmail.com>; <bmcgahan@internetworkexpert.com>;
<richard.dumoulin@vanco.es>; <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
Sent: Friday, June 11, 2004 9:37 AM
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