Understanding ‘transport output’ and ‘access-class’

Several years ago I wrote an article called The Elusive “access-class out” CommandMy 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.

Topology

Understanding Telnet:SSH Client Restrictions

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#

Conclusion

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.

 

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in How-To. Bookmark the permalink.