VTY access-class Behavior With VRFs

Over the past few weeks, I have posted several introductory articles that deal with the concept of VRFs. One behavior that is modified when VRFs are introduced is the VTY access-class command. A router that is configured for VRFs will actually allow incoming VTY (telnet and ssh) sessions from any VRF or from connections arriving in the global IP instance.

To demonstrate this, we will use the VRF topology we have been working from for the past few weeks.

To test a VTY session establishment from a VRF, we will connect to R1 from R2.

R2#telnet 192.168.1.1    
Trying 192.168.1.1 ... Open

User Access Verification

Password:
R1>exit

[Connection to 192.168.1.1 closed by foreign host]

To demonstrate the behavior with an access-class, we will build an ACL on R1 that permits R2. Then we will apply it as an access-class in the VTY section.

R1(config)#access-list 1 permit host 192.168.1.2
R1(config)#line vty 0 15
R1(config-line)#access
R1(config-line)#access-class 1 in

Now if we run our original test again, we find that the telnet session fails. This is true even though the IP address from R2 is permitted by the access-list.

R2#telnet 192.168.1.1
Trying 192.168.1.1 ...
% Connection refused by remote host

R2#

//by default all VRFs are blocked by access-class

If it is truly our desire to allow VTY sessions from traffic arriving in a VRF instance, we can modify the behavior of the access-class. This is done using the “vrf-also” option.

R1(config-line)#access-class 1 in ?
  vrf-also  Same access list is applied for all VRFs

R1(config-line)#access-class 1 in 

R1(config-line)#access-class 1 in vrf-also
R1(config-line)#do show run | sec vty
line vty 0 4
 access-class 1 in vrf-also
 password cisco
 login

Now if we test our connection from a source in a VRF, we see that the VTY connection is permitted (assuming it matches the acl identified in the access-class command).

R1(config)#

R2#telnet 192.168.1.1
Trying 192.168.1.1 ... Open

User Access Verification

Password: 

R1>

From this example, we can see that IOS devices will accept all VTY connections by default. However, if an access-class is used, the assumption is that connections should only arrive from the global IP instance. If there is truly a need and a desire to control the IP source while allowing VTY connections from VRF instances, we have a configuration option. However, due to the fact that the same IP source may exist in multiple VRFs, this option might not give the desired granularity of control.

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 Network, Security, Technology and tagged , , , , . Bookmark the permalink.

2 Responses to VTY access-class Behavior With VRFs

  1. Manjunath K P says:

    Thanks Paul..:)

  2. akjol says:

    Thank’s!

Leave a Reply