“Access-class out” seems to never work as expected. At first, it seems that the reason why this the case is because you must telnet into the router first. In other words, it has no effect to telnet connections that are attempted from a console session. Well that’s not completely true. Access-class out is a restriction that is applied to an exec process. An exec process is spawned when you attach to a line (aux, vty, con). So if we are wanting to restrict where the exec process on line con 0 can go, we must attach the access-class out to “line con 0”. If we desire to control where a telnet session can telnet back out to, that restriction must be applied to the “line vty x y”.
Anthony Sequeira has put together a great video demonstrating how to deny an outbound telnet session when the exec process is started from an inbound telnet session. Below the video, you can find a sample of my testing using a console connection as opposed to an inbound telnet session.
I decided to expand on Anthony’s example and use it on the console line. This helped my get my mind around the fact that it is a restriction on the process as opposed to the vty ports being considered the source of the secondary telnet session.
Trying 10.23.23.1 … Open
Password required, but none set <<Outbound Telnet Still Permitted (message from remote router)
[Connection to 10.23.23.1 closed by foreign host]
Enter configuration commands, one per line. End with CNTL/Z.
RouterB(config)#access-list 1 deny any
RouterB(config)#line con 0
RouterB(config-line)#access-class 1 out
Trying 10.23.23.1 …
% Connections to that host not permitted from this terminal
RouterB#sho run | sec con|access-list
Current configuration : 1109 bytes
access-list 1 deny any
line con 0
access-class 1 out