Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

access list on line vty

hi,

I have one L3 switch with two vlan interfaces 10.1.1.1 and 20.1.1.1. On the same switches two hosts are there in each vlan. Now I want that only 10.1.1.11 can telnet the switch from the vlan interface IP's (10.1.1.1 and 20.1.1.1)

I wrote access list

access-list 101 permit tcp host 10.1.1.11 host 10.1.1.1 eq 23

access-list 101 permit tcp host 10.1.1.11 host 20.1.1.1 eq 23

and applied it as

line vty 0 4

access-class 101 in

but none of the host is able to connect to switch but if I apply that as access-class 101 out then both systems get access.

None of the direction is achieving the goal and I want to use exteneded list only becaue when I use std list as access-list 1 permit 10.1.1.1 and apply to line as access-class 1 in goal is achived..

Please suggest abt the extended list behavioue to perform this task

thanks !!!

1 ACCEPTED SOLUTION

Accepted Solutions
Hall of Fame Super Silver

Re: access list on line vty

Hello Hermant,

I made a search in netpro using topright search button.

most of examples provided by colleagues use an any destination when using extended ACL in access-class in command

I'm afraid this is a limitation on using extended ACLs for access-class.

I remember a thread where Rick Burts explained this.

I usually configure a standard ACL for access-class.

see this from John Blakley

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=WAN%2C%20Routing%20and%20Switching&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40^1%40%40.2cd3247b/6#selected_message

Hope to help

Giuseppe

19 REPLIES
Hall of Fame Super Silver

Re: access list on line vty

Hello Hemant,

you can use a standard ACL to restrict telnet access on vtys

access-list 11 permit host 10.1.1.11

line vty 0 4

access-class in

this automatically allows telnet to all IP addresses of multilayer switch from source 10.1.1.11/32

usually we allow telnet connections from NOC IP subnets

Hope to help

Giuseppe

Community Member

Re: access list on line vty

Dear friend,

that I am able to do but it is not happening with extended list I want that 10.1.1.11 can only telnet the switch not ssh etc

Please suggest what changes needs to be done in the extended list in my last post

Thanks !!!

Purple

Re: access list on line vty

If you don't want ssh just use "transport input telnet" on the vty's this will disallow SSH .

Community Member

Re: access list on line vty

Thanks for the suggestion !!!

Now is there any workaround to use extended access list to use for telnet. please refer to my first post where i have written the whole configuration.

Community Member

Re: access list on line vty

Is there anyone who can reply on my first post to implement ext acces list on vty !!!

Hall of Fame Super Silver

Re: access list on line vty

Hello Hermant,

try this

access-list 111 permit tcp host 10.1.1.1 any eq 23

to see if in this way you can limit access to telnet only and to specified host.

Glen's suggestion is valid: if you don't want to use SSH you can do in that way.

Hope to help

Giuseppe

Community Member

Re: access list on line vty

buddy,

you mean to say if host is 10.1.1.11 then

access-list 111 permit tcp host 10.1.1.11 any eq 23

So, now i am able to telnet the switch from both vlan interfaces. Thanks for this.

Now what is the explaination of any in the acl above, also if i am applying ext acl why i cannot use int ip 10.1.1.1 or 60.1.1.1 in place of any.

or

what if I want this host 10.1.1.11 to telnet through 10.1.1.1 only not through 60.1.1.1

or if you donot mind, could you share you email ID so that we can chat !!!

Thanks and waiting for your support

Community Member

Re: access list on line vty

Hi,

Please extend your valuable support

Thanks,

Community Member

Re: access list on line vty

Hello Everyone,

Please help me in this problem

Thanks !

Community Member

Re: access list on line vty

No one seems to give the answer to this !!!

Hall of Fame Super Silver

Re: access list on line vty

Hello Hermant,

I made a search in netpro using topright search button.

most of examples provided by colleagues use an any destination when using extended ACL in access-class in command

I'm afraid this is a limitation on using extended ACLs for access-class.

I remember a thread where Rick Burts explained this.

I usually configure a standard ACL for access-class.

see this from John Blakley

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=WAN%2C%20Routing%20and%20Switching&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40^1%40%40.2cd3247b/6#selected_message

Hope to help

Giuseppe

Hall of Fame Super Gold

Re: access list on line vty

Giuseppe

Thank you for remembering my discussion of this. I do not remember that specific post but will lay out the issues again.

The optimum solution for access-class applied on vty is to use a standard access list. It is possible to use an extended access list in the access-class but when you do the "destination" address must be any (which sort of defeats the purpose of using extended access lists).

While an extended access list can specify more specific addresses as source and destination when used in access-group on an interface (where it sees traffic with valid, specific source and destination addresses) it does not work that way in access-class on the vty. The reason for this has to do with how the access-class is implemented. One of the advantages of access-class is that it works on remote access to the vty ports. It does not matter which interface the request arrived on (what was the destination address) so there is no evaluation of the destination address in access-class only evaluation of the source address. So if you attempt to use an extended access list with a specific destination address it will not create a match in the logic of access-class.

HTH

Rick

Hall of Fame Super Silver

Re: access list on line vty

Hello Rick,

thanks for your clear explanation.

I remembered that thread because I had learned about extended ACLs on vty on it.

I've never tried to use extended ACLs with access-class so I couldn't provide an explanation.

I'm satisfied with it and I hope also the original poster will be.

Best Regards

Giuseppe

Silver

Re: access list on line vty

“The reason for this has to do with how the access-class is implemented.”

Hello Giuseppe & Rick,

Thanks for a nice discussion

Though Rick has already answered the question.

Was just wondering can this be a reason why access-class is implemented this way.

Lets assume there are 2 routers A & B (A-B) and both are connected with more than one link say 2. I have a host connected to router A and want to telnet router B. I have defined an extended list on access class with only one IP address of the router B.

Interface (whose IP address is defined in access list) is down then because of implicit deny at the end of access list I cannot login to router B though I have another link to reach router B.

I am thinking Cisco have saved guys from getting in trouble if by mistake they apply an extended list this way and then have caught up in situation like this where they cannot login to a remote router.

Community Member

Is this still the case these

Is this still the case these days with new IOS/IOS XE? This is a huge issue when your talking about a multi-layer switch with multiple SVIs and VRFs and needing only the management SVI/VRF to respond to any connection request coming from a source.

 

Hall of Fame Super Gold

As far as access class is

As far as access class is concerned I believe that the situation today is just as it was 6 years ago when this discussion took place. But we now have some tools available that were not available 6 years ago. I believe that you should be able to use something like Control Plane Protection or Control Plane Policing to control management access.

 

HTH

 

Rick 

Community Member

Many why cant this stuff be a

Many why cant this stuff be a bit more simple without having to learn a whole new subject of cisco....smh

Community Member

Re: Many why cant this stuff be a

Job security?

Hall of Fame Super Gold

Re: Many why cant this stuff be a

You have picked a very old thread to bring back to life (original discussion in 2009 with additional question in 2015). But having brought it back to life let us consider other answers that are possible.

 

First let us remember that when access-class was introduced and when the original question was asked that our networks were much simpler and our devices had fewer interfaces. There was a concern about how to control access to our network devices, and especially how to control where the request came from. There was not much reason to be concerned about which interface had received the request. access-class was developed to address this requirement. I would assert that it was a very effective solution to that requirement.

 

Now think about the environment quite a few years later. Our networks are more complex. Our devices have more interfaces. The sophistication of attacks has increased. Now from a security perspective we are concerned not only about where the request came from but are concerned about how the request got to us. (remember that the question in 2015 was how to differentiate a request received on the management interface from a request received on a data interface)  This is quite a change in terms of scope and complexity. While it might have been able to meet this requirement by making changes in access-class that would have been difficult and would have presented significant challenges in backward compatibility to older versions of code implementation of access-class. It was easier and cleaner to solve this new requirement by developing a new feature. And that is what Cisco chose to do.

 

access-class is still available when our requirement is just to control where the access request came from. And the new control place control processes are available when we need to address other requirements such as which interface received the request.

 

HTH

 

Rick

3743
Views
32
Helpful
19
Replies
CreatePlease to create content