From: Carlos G Mendioroz (tron@huapi.ba.ar)
Date: Sat Jun 12 2004 - 08:21:12 GMT-3
The route-map is just evaluating the access-list, for the REFLEX list to
be populated. That works, because locally generated pings work (they do
not without that) but is not good for OSPF traffic.
So the question stands: Is there any way to police local routing traffic?
Richard Dumoulin wrote:
> 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