Several years ago I wrote an article called The Elusive “access-class out” Command. My primary goal was to help CCNA students understand both the behavior of and placement of this command. My friend Anthony Sequeira done a great job in the video that is also shown in my original post. Today, I want to share another command and expand on there behavior.
For all of the demonstrations in this article, the following topology will be used. The router named iosv-2 will be the primary focus and the only place changes will be made.
Backing up for a moment, there are a couple of messages that might be displayed when an IOS device blocks outbound telnet or ssh sessions from the current exec session. These are demonstrated with a quick configuration of an transport output and access-class restriction.
//the first error is unique depending on //if ssh or telnet is being used iosv-2(config)line con 0 iosv-2(config-line)#transport output none iosv-2(config-line)#do telnet 192.168.0.3 % telnet connections not permitted from this terminal iosv-2(config-line)#do ssh -l cisco 192.168.0.3 % ssh connections not permitted from this terminal //now we can re-enable all the protocols //and demonstrate the other error message iosv-2(config-line)#transport input all iosv-2(config-line)#access-list 1 deny 192.168.0.3 iosv-2(config)line con 0 iosv-2(config)#access-class 1 out iosv-2(config-line)#do telnet 192.168.0.3 Trying 192.168.0.3 ... % Connections to that host not permitted from this terminal
It is worth noting that in the second example, the error message is agnostic to the protocol being used (ssh or telnet).
The important question I would have for everyone is where do we place the commands to disable the transport protocols or block certain destinations with an access-class. Observant readers will notice that I have placed them under line con 0. While that is one option, the answer isn’t that simple. This worked in this case because I was physically connected to the console port (line con 0). However, there are two other ways I can connect to an exec session on iosv-2.
To demonstrate my point, I am going to leave the “access-class 1 out” applied to line con 0. I am also going to change the prompt to show the TTY line for clarity.
iosv-2(config)#prompt %h:%n%p iosv-2(config)#exit iosv-2#exit ... iosv-2:0> iosv-2:0>en Password: iosv-2:0#show run | sec line con 0 line con 0 access-class 1 out password cisco //as we have seen this prevents a connection to 192.168.0.3 transport output none iosv-2:0#telnet 192.168.0.3 % telnet connections not permitted from this terminal
Notice that the console is indicated by :0 in the prompt. Now without making any changes, I will connect to the AUX port and attempt the same connection.
iosv-2:1#disable iosv-2:1>enable Password: iosv-2:1#telnet 192.168.0.3 Trying 192.168.0.3 ... Open //truncated output
Notice that we are in the AUX line, indicated by “:1” in the prompt. Also notice that the telnet session was permitted. To restrict this, the access-class command must be applied to line aux 0.
iosv-2:1#conf t iosv-2(config)#line aux 0 iosv-2(config-line)#access-class 1 out iosv-2(config-line)#exit iosv-2(config)#exit iosv-2:1#telnet 192.168.0.3 Trying 192.168.0.3 ... % Connections to that host not permitted from this terminal
This same behavior is demonstrated with a telnet session into iosv-2. This is shown by connecting to iosv-2 from iosv-1 (using ssh or telnet).
//start at iosv-1 connect to iosv-2 iosv-1#telnet 192.168.0.2 Trying 192.168.0.2 ... Open User Access Verification Username: cisco Password: //now from iosv-2 connect to iosv-3 iosv-2:578# iosv-2:578#telnet 192.168.0.3 Trying 192.168.0.3 ... Open User Access Verification Username: cisco Password: iosv-3# //output truncated
As can be seen above, the VTY line numbers shows up as a much larger line number (578 in my example). It can also be seen that the subsequent connection to iosv-3 is successful. This can be resolved in the same way as it was for line aux 0. This time the access-class will be added under line vty 0 15.
iosv-2:578#conf t Enter configuration commands, one per line. End with CNTL/Z. iosv-2(config)#line vty 0 15 iosv-2(config-line)#access-class 1 out iosv-2(config-line)#exit iosv-2(config)#exit iosv-2:578#telnet 192.168.0.3 Trying 192.168.0.3 ... % Connections to that host not permitted from this terminal iosv-2:578#
Most people grasp what the access-class x out and the transport output commands do. What I don’t think everyone accurately thinks about is the impact of the placement of these commands. Many blindly assume since we are affecting telnet or ssh traffic that these commands should be entered under line vty 0 15. While that may be true in some cases, that truth only holds if the initial connection into the telnet client is done through telnet or ssh.
More accurately stated, an administrator connected to a router is in an exec session. That session is attached to a con, aux or vty line. That attachment determines where the command or commands must be entered to affect subsequent outbound telnet or ssh sessions. I think the typical best practice is that we would expect all lines to behave similarly so we should probably consistently configure the access-class and transport output methods across all three line types.
Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This
may or may does not reflect the position of past, present or future employers.