From: Richard Dumoulin (richard.dumoulin@vanco.es)
Date: Fri Jun 11 2004 - 22:29:21 GMT-3
What is your route-map doing ?
I would do it like this:
access-list 100 permit ip any any
Route-map toLan
Match ip address 100
Set interface loopback0
!
Ip local-policy route-map tiLan
--Richard
-----Original Message-----
From: Carlos G Mendioroz [mailto:tron@huapi.ba.ar]
Sent: viernes, 11 de junio de 2004 18:48
To: ccie2be
Cc: Kenneth Wygand; Zachary Hinz; bmcgahan@internetworkexpert.com; Richard
Dumoulin; ccielab@groupstudy.com
Subject: Re: icmp filtering
Playing with reflect, I tried to make router originated pings to work by
using a reflect in an ACL applied to local traffic (via ip local
policy routemap).
interface Ethernet0/0
ip address 172.30.0.251 255.255.255.0
ip access-group fromLan in
ip access-group toLan out
route-map localTraffic permit 10
match ip address toLan
ip access-list extended fromLan
evaluate REFLEX
ip access-list extended toLan
permit ip any any reflect REFLEX
It worked, but it did not cover router processes traffic though (an OSPF
adjacency was denied. Is there any way to set a policy for the router
processes traffic ?
ccie2be wrote:
> 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
> >
> >
> _______________________________________________________________________
> > Please help support GroupStudy by purchasing your study materials
> from:
> > http://shop.groupstudy.com
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> **********************************************************************
> Any opinions expressed in the email are those of the individual and
> not necessarily the company. This email and any files transmitted with
> it are confidential and solely for the use of the intended recipient.
> If you are
> not the intended recipient or the person responsible for delivering it
> to
> the intended recipient, be advised that you have received this email in
> error and that any dissemination, distribution, copying or use is
> strictly
> prohibited.
> If you have received this email in error, or if you are concerned with
> the
> content of this email please e-mail to: e-security.support@vanco.co.uk
> The contents of an attachment to this e-mail may contain software
> viruses
> which could damage your own computer system. While the sender has taken
> every reasonable precaution to minimise this risk, we cannot accept
> liability for any damage which you sustain as a result of software
> viruses.
> You should carry out your own virus checks before opening any
> attachments to
> this e-mail.
> **********************************************************************
>
> ______________________________________________________________________
> _
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _________________________________________________________________
> Stop worrying about overloading your inbox - get MSN Hotmail Extra
> Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/
>
> ______________________________________________________________________
> _
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
-- Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:38 GMT-3