I would not apply an extended ACL to the VTY lines. You will probably end up locking yourself out if you are not careful! They do not work (certainly on switches I have used). By the time the data gets to the L7 VTY lines (where the ACL is referenced) the destination is stripped out so the ACL can only match by source. Always use a standard ACL on your VTY lines. With regards to restricting to certain interfaces I am not sure how you would do this. ACLs applied to interfaces (or VLAN interfaces) only apply to routed traffic and not traffic with a destination of the device itself (as far as I know)
What you describe is normal behavior. And I believe that most of us would say that it is desirable.
If you think about it, telnet and SSH are remote access sessions to a device. When someone does telnet or SSH to your device I can understand wanting to control who can access your device (via authentication) and I can understand want to control where they come from (the source address controlled via access-class on the vty). But I do not understand being concerned about what address they use to get to the box.
Is there something in your environment that makes it different if they telnet to the address of VLAN 3 or to the address of VLAN 5?
Assumption: this is one of the devices that services students/teachers/others
Assumption: students are intelligent and inquisitive.
Assumption: you are the only one/group that should have access to the device.
First your 6500 chassi is/are available on several different VLANS.
this I would stop at once IF there is no special reason for it to be configured that way.
My guess is that if it is not hacked, then it is not far from getting just that.
it does not mean that someone is doing anything malicious with it, but there might be misconfigurations and stuff that disrupts service.
I would actually if possible stop all telnet/ssh/http/https traffic to the device itself.
Atleast stop telnet and http since they send the login information in cleartext.
if the student have a sniffer they will have the loginnames and passwords quickly.
Get a firewall (asa5505?), and setup a pc behind it with a direct connected serial cable to the 6500 (and other switches maybe ?) to connect to the pc you would then open up the firewall only for appropriate communication means (ipsec vpn/ssl vpn/AAA TCP communication)
use personal usernames and passwords so that everyone have their own username and password to login to the equipment.
dont forget to set up NTP. that will help not only with time, it will also help with who was last on.
This method secures the device from malicious use or accidental missconfiguration from someone not authorised to use it in that way.
if this is not possible or desireable in your case, ACLs are used to control what ip address are allowed to access the unit.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...