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.