Allan Eising wrote:
I can't see why you should use an extended acl to do that. "transport
input telnet ssh" should allow access only through those two
protocols, so filtering that through an ACL is a bit redundant in my
opinion.
You should be able to use a standard acl like:
ip access-list standard vty
permit 10.0.0.0 0.0.0.255
permit 10.1.0.0 0.0.0.255
deny any log
!
line vty 0 4
transport input telnet ssh
access-class vty in
!
The objective was to allow one group to use telnet and another to use
ssh. This would require an extended ACL.
Ang Kah Yik wrote:
I think more specifically, he wanted to be able to permit a particular
group
of users to use telnet and another to use ssh.
While I'm not sure why it'd be good to use telnet when ssh is available, I
suppose it would be possible to apply an ACL on the VTYs to deny access to
telnet/ssh as required.
--
Jay Hennigan - CCIE #7880 - Network Engineering - [EMAIL PROTECTED]
Impulse Internet Service - http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
