From: Kenneth Wygand (KWygand@customonline.com)
Date: Sun Jul 25 2004 - 14:34:04 GMT-3
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
> >
> > 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
This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:12:02 GMT-3