From: Kenneth Wygand (KWygand@customonline.com)
Date: Sun Jul 25 2004 - 17:09:28 GMT-3
?
Georg,
I'm glad I could help. It's nice when things start to make sense! ;-)
Ken
________________________________
From: Georg Pauwen [mailto:pauwen@hotmail.com]
Sent: Sun 7/25/2004 3:21 PM
To: Kenneth Wygand; K.Peetermans@chello.be; dansheedy@gmx.net; rohang@cisco.com
Cc: ccielab@groupstudy.com
Subject: RE: How "Access-class" on VTY lines actually works
Hello Ken,
excellent explanation. When I debugged the whole process, I noticed that a
random port above 11000 is chosen, your story puts it into the right
context...:)
Regards,
Georg
>From: "Kenneth Wygand" <KWygand@customonline.com>
>Reply-To: "Kenneth Wygand" <KWygand@customonline.com>
>To: "Koen Peetermans" <K.Peetermans@chello.be>, "Georg Pauwen"
><pauwen@hotmail.com>, <dansheedy@gmx.net>, <rohang@cisco.com>
>CC: <ccielab@groupstudy.com>
>Subject: How "Access-class" on VTY lines actually works
>Date: Sun, 25 Jul 2004 13:34:04 -0400
>
>Koen,
>
>You are correct in your statements. I tested this out myself to verify and
>can support your findings. However, I can explain why it is that way.
>
>The telnet service runs locally on a router. It is a -local- service to
>the router itself. The service is not "bound" to any particular interface
>by design. This is different than say, a Windows 2000 server, where
>services are bound to a particular interface. If you've ever set up, for
>example, IIS server to host a website, you manually select which interfaces
>you want to run this service on. The telnet service on Cisco routers is
>not bound to any interface, as sessions can come in any interface.
>
>Having that said, when you telnet into a router, you must first pass the
>interface ACL. Once that passes, if the system determines your packet is
>destined for any local IP address, it will de-encapsulate the IP packet and
>pass it up to the transport layer. At this point, the service is determine
>to be "telnet", so the packet is then handed off to the local service
>running on the router. It is at precisely this point that the traffic is
>funneled through the "access-class". While the source IP address is
>maintained internally, the destination is now really the local service, no
>longer having a true "destination" IP address. This is really just a
>"missing" IP address, and you will only see this if you add the "log"
>statement to your access-list tied to your access-class. If you try to
>telnet to 0.0.0.0, you will not telnet to the local router. Thus, this
>0.0.0.0 address is just sort of a placeholder.
>
>If you want to permit or deny telnet based on destination IP address, you
>must do this with an ACL at the -interface- level. This is the only point
>in the process where the destination IP address is still intact and can be
>matched. Of course, you will have to put this ACL on all possible incoming
>interfaces to ensure a consistent filtering of telnet packets inbound to
>the router.
>
>An easy way to see this is to configure the following access-lists:
>
>access-list 100 permit ip host 12.12.12.2 host 12.12.12.1 log
>access-list 100 permit ip host 12.12.12.2 any log
>access-list 101 permit ip host 12.12.12.2 host 12.12.12.1 log
>access-list 101 permit ip host 12.12.12.2 any log
>
>Note that both access-lists (100 and 101) are identical. Now apply
>access-list 100 to the incoming -INTERFACE- through an access-group and
>apply access-list 101 to the telnet -SERVICE- through an access-class.
>
>After telnetting into this router, you will notice the following output:
>
><SNIP>
>R1(3620)#
>*Mar 1 00:42:31.011: %SEC-6-IPACCESSLOGP: list 100 permitted tcp
>12.12.12.2(0)
>-> 12.12.12.1(0), 1 packet
>*Mar 1 00:43:16.167: %SEC-6-IPACCESSLOGP: list 101 permitted tcp
>12.12.12.2(110
>05) -> 0.0.0.0(23), 2 packets
>R1(3620)#
>R1(3620)#show access-lists
>Extended IP access list 100
> 10 permit ip host 12.12.12.2 host 12.12.12.1 log (10 matches)
> 20 permit ip host 12.12.12.2 any log
>Extended IP access list 101
> 10 permit ip host 12.12.12.2 host 12.12.12.1 log
> 20 permit ip host 12.12.12.2 any log (2 matches)
>R1(3620)#
></SNIP>
>
>Hope this helps!
>Ken
>
>________________________________
>
>From: nobody@groupstudy.com on behalf of Koen Peetermans
>Sent: Sun 7/25/2004 11:19 AM
>To: 'Georg Pauwen'; dansheedy@gmx.net; rohang@cisco.com
>Cc: ccielab@groupstudy.com
>Subject: RE: Access-class
>
>
>
>It is apparently impossible to check for destination ip, if you log your
>access-list you will see this :
>
>Rack1R5(config)#access-list 100 permit tcp any any log
>Rack1R5(config)#line vty 0 4
>Rack1R5(config-line)#access-class 100 in
>Rack1R5#sh ip int brief
>Interface IP-Address OK? Method Status
>Loopback0 150.1.5.5 YES NVRAM up
>Rack1R5#telnet 150.1.5.5
>Trying 150.1.5.5 ... Open
>
>
>User Access Verification
>
>Password:
>00:21:02: %SEC-6-IPACCESSLOGP:
>list 100 permitted tcp 150.1.5.5(11001) -> 0.0.0.0(23), 1 packet
>Rack1R5>
>
>So apparently the telnet session goes to a sort of internal software "loop"
>(or how should I call it), and you won't see the destination IP, only
>0.0.0.0
>Never understood why this is, and it limits the extended ACL to checking
>only the tcp port, not the destination IP.
>
>Kind regards,
>
>Koen.
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>Georg Pauwen
>Sent: zondag 25 juli 2004 17:11
>To: dansheedy@gmx.net; rohang@cisco.com
>Cc: ccielab@groupstudy.com
>Subject: Re: Access-class
>
>Hello,
>
>this works indeed, but the access list 100 proposed by Rohan should work as
>well. It doesn4t, does anybody know why ?
>
>access-list 100 permit tcp host 1.0.0.1 host 1.0.0.2 eq telnet
>
>looks perfectly allright to me...
>
>Regards,
>
>Georg
>
>
> >From: "Daniel Sheedy" <dansheedy@gmx.net>
> >Reply-To: "Daniel Sheedy" <dansheedy@gmx.net>
> >To: "Rohan Grover" <rohang@cisco.com>
> >CC: <ccielab@groupstudy.com>
> >Subject: Re: Access-class
> >Date: Sun, 25 Jul 2004 13:27:09 +0200
> >
> >Hi Rohan,
> >
> >What if change it to a standard access list?
> >
> >access 1 permit 1.0.0.1 0.0.0.0
> >
> >You really dont care where it is going... because you are at the
> >destination
> >where you wish to test the little blighter, to see if it is allowed in or
> >not.
> >So, you only need to see that it originated from the right place.
> >If it was a packet on its way to somewhere else, then maybe you would
>check
> >the source AND the destination. But thats another story, and not
>important
> >for here.
> >
> >Then apply this on the line 0 4.
> >
> >access-class 1 in
> >
> >Then, dont forget, if R1 has multiple ways to get to R2, go over to R1
>and
> >set the source interface for the telnet, so you are not having to put
> >multiple permit lines on R2.
> >
> >ip telnet source-interface lo0
> >
> >or whatever interface grabs your fancy.
> >
> >Cheers
> >
> >Dan Sheedy
> >
> >
> >----- Original Message -----
> >From: "Rohan Grover" <rohang@cisco.com>
> >To: <ccielab@groupstudy.com>
> >Sent: Sunday, July 25, 2004 11:36 AM
> >Subject: Access-class
> >
> >
> > > Hi,
> > >
> > > This is a really simple scenario but for some reason I'm unable to get
> >it
> >to work!!
> > >
> > > R1 ----------- R2
> > > 1.0.0.1 1.0.0.2
> > >
> > > All I want to do is deny telnet access on R2 to everyone except from
> >1.0.0.1(R1) to 1.0.0.2(R2).
> > >
> > > So I use access list
> > >
> > > 'access-list 100 permit tcp host 1.0.0.1 host 1.0.0.2 eq telnet'
> > >
> > > And apply it on vty 0 4 of R2 as 'access-class 100 in'
> > >
> > > I see that this blocks ALL telnet access.
> > >
> > > If I change the access-list to
> > >
> > > 'access-list 100 permit tcp host 1.0.0.1 any eq telnet' , then it
>allows
> >telnet access only from 1.0.0.1 to any interface on R2,
> > > which is not what I want.
> > >
> > > Is there anything I'm missing regarding use of access-class? Some
> >restriction on destination host?
> > >
> > > Thanks
> > > Rohan
> > >
> > >
>_______________________________________________________________________
> > > Please help support GroupStudy by purchasing your study materials
>from:
> > > http://shop.groupstudy.com <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 <http://shop.groupstudy.com/>
> >
> >Subscription information may be found at:
> >http://www.groupstudy.com/list/CCIELab.html
>
>_________________________________________________________________
>MSN Search, le moteur de recherche qui pense comme vous !
>http://search.msn.fr/worldwide.asp
>
>_______________________________________________________________________
>Please help support GroupStudy by purchasing your study materials from:
>http://shop.groupstudy.com <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 <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 <http://shop.groupstudy.com/>
>
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:12:03 GMT-3