[c-nsp] Access-list application

[Amol Sapkal]

On Wed, 22 Sep 2004 07:37:38 -0400, Rodney Dunn <rodunn at cisco.com> wrote:
> On Wed, Sep 22, 2004 at 07:12:55AM +0530, Amol Sapkal wrote:
> > Yes,
> >
> > I checked it yesterday for ICMP, traffic generated within the router
> > does actually pass outbound. So the access-list did not stop the
> > traffic outbound.
> > I know about ip local policy, but thought it comes in play only for
> > taking routing decisions and not access-list application.
> 
> Well, for a policy to work you have to do two things.
> a) match
> b) set
> 
> meaning you have to first classify the traffic and then decide
> what you want to do with the traffic that matches.
> The point was if you want to prevent traffic from originating
> from the router for a certain reason you can leverage PBR
> to either permit or deny by the set clause.
> 
> It wasn't originally designed to do that but it so happened
> to solve this problem too.
> 
> >
> > Like, if my router's default is interface X, and there is source based
> > routing for traffic from subnet A.B.C.D to go out via interface Y -
> > 1. with ip local policy enabled, an extended trace on the router (with
> > a loopback as source, which is in the subnet ABCD), will take
> > interface Y.
> > 2. with ip local policy disabled, the trace would still take the
> > default interface X.
> 
> Well, I'm not sure why you would ever want to do that.
> "ip local policy" *only* applies to traffic that is originated
> by the router going out.  If you want to redirect that traffic
> to a different path than the routing table says you do it.
> Otherwise you shouldn't use local policy.
> 
> The only reason your above example does anything different is
> because the ICMP response built by the router is evaluated
> against the local policy.  That doesn't make much sense to me
> because one of the purposes of traceroute/ping is to verify
> path connectivity.  If you force just that traffic to reroute
> then your data path and ICMP paths diverge and one can work
> and the other not.
> 
> Rodney
> 


This was required so that my trace and ping traffic follows the same
path as my actual data. this could help my team do a proper
troubleshoot on Internet paths.


> 
> 
> >
> >
> >
> >
> > On Wed, 22 Sep 2004 02:27:29 +0300, Volodymyr Yakovenko
> > <vovik at dumpty.org> wrote:
> > > On Tue, Sep 21, 2004 at 05:36:10PM -0400, Rodney Dunn wrote:
> > > >Never tried it with a loopback.
> > > >
> > > >Is that packet matches for in or out?
> > >
> > > Only inbound ACL actualy matches packets.
> > >
> > > So your statement about outbound ACLs is right.
> > >
> > > >You have the ACL configured in both directions
> > > >with the same src/dst.
> > > >
> > > >On Tue, Sep 21, 2004 at 10:33:03PM +0300, Volodymyr Yakovenko wrote:
> > > >> On Tue, Sep 21, 2004 at 02:02:39PM -0400, Rodney Dunn wrote:
> > > >> >On Tue, Sep 21, 2004 at 11:15:39PM +0530, Amol Sapkal wrote:
> > > >> >> Quick question: Does an interface access-list apply to traffic
> > > >> >> generated from a router? Say a ping, if icmp is blocked, or a telnet
> > > >> >> to a site on port 80, if port 80 is blocked.
> > > >> >
> > > >> >On egress from the router no.
> > > >>
> > > >> It does work for Loopbacks:
> > > >>
> > > >> interface Loopback1
> > > >>  ip address 172.21.255.2 255.255.255.255
> > > >>  ip access-group NOME in
> > > >>  ip access-group NOME out
> > > >>  h323-gateway voip interface
> > > >>  h323-gateway voip id dp-gk1 ipaddr 172.21.255.1 1719
> > > >>  h323-gateway voip h323-id dp-msc-cis2
> > > >>  h323-gateway voip tech-prefix 1#
> > > >> ip access-list extended NOME
> > > >>  deny   tcp host 172.21.255.2 host 172.21.255.2 eq 1720
> > > >>  permit ip any any
> > > >>
> > > >> dp-msc-cis2#sh ip access-lists NOME
> > > >> Extended IP access list NOME
> > > >>     deny tcp host 172.21.255.2 host 172.21.255.2 eq 1720 (36 matches)
> > > >>     permit ip any any (36 matches)
> > > >>
> > > >> >Why?  Because it's assumed the the router sending a packet
> > > >> >out is always a valid one.
> > > >> >
> > > >> >We considered an option for them to match on the traffic
> > > >> >but since the below workaround does the job it never
> > > >> >went further.
> > > >> >
> > > >> >You can force it to do by defining a route-map, match
> > > >> >the traffic, configure "ip local policy <route-map".
> > > >> >
> > > >> >Rodney
> > > >> >
> > > >> >
> > > >> >>
> > > >> >> Detailed: If no, why?
> > >
> > > --
> > > Regards,
> > > Volodymyr.
> > >
> > >
> >
> >
> >
> > --
> > Warm Regds,
> >
> > Amol Sapkal
> >
> > --------------------------------------------------------------------
> > An eye for an eye makes the whole world blind
> > - Mahatma Gandhi
> > --------------------------------------------------------------------
> 



-- 
Warm Regds,

Amol Sapkal

--------------------------------------------------------------------
An eye for an eye makes the whole world blind 
- Mahatma Gandhi
--------------------------------------------------------------------