Access-List for vty lines on ISR-4331 running IOS-XE

[Billm]

This is driving me insane.

I've looked at multiple posts, nothing works.

I just want access to vty lines from my inside network.

The latest:

ip access-list standard Inside-Machines
permit 10.10.0.0 0.0.255.255

line vty 0 4
access-class Inside-Machines in
exec-timeout 0 0
transport preferred none
transport input ssh
line vty 5 15
access-class Inside-Machines in
exec-timeout 0 0
transport preferred none
transport input ssh

[Richard Burts]

Bill

Thanks for the additional information. Yes I have seen  sl_def_acl  before and it is something that IOS has generated and certainly is not anything you have done. I am not sure what it is for but am sure that it does not relate to the current issue. 

I see this in your output

Standard IP access list Inside

-

Machines

10 permit 10.10.0.0, wildcard bits 0.0.255.255 log

and wonder about the log parameter. I agree that it would be nice to see the IP of the connection request but I do not think that works when used in access-class. Please remove it and let us know if it makes any difference.

If we want to identify the source address I would suggest configuring an extended ACL and applying it inbound on the interface where the SSHY request will be received. The ACL would permit inbound SSH with log parameter and then permit any any. It might look like this

access-list 101 permit tcp any any eq 22 log

access-list 101 permit ip any any

HTH

Rick

[Billm]

Removing the log variable did not change the behavior.

Thanks

[Richard Burts]

Thanks for confirming that removing the log parameter did not change the behavior. I know that there are some ways to use ACL where log is not supported and using log will cause unexpected behavior. I was not sure if access-class was one of those. Apparently it is not.

The syntax seems right but the behavior does not seem to match what we expect from that syntax. To me that suggests one of two things:

1) perhaps there is a bug in this version of code. You can check the release notes and look into the bug listings to see if there is a known issue about this. Of you might just try a different version of code to see if the behavior changes.

2) perhaps there is something about the SSH request that does not match what we expect. Is it possible that the source address is not 10.10.101.7? We might use debug ip packet with an access list to limit the debug output. Something like this

access-list 101 permit tcp any any eq 22

debug ip packet 101

then try the SSH connection attempt. The debug output should show us the information from that packet.

HTH

Rick

[Billm]

Could this have anything to do with IOS-XE version?

Technology Package License Information:

-----------------------------------------------------------------
Technology    Technology-package           Technology-package
              Current       Type           Next reboot
------------------------------------------------------------------
appx             None             None             None
uc               None             None             None
security         None             None             None
ipbase           ipbasek9         Permanent        ipbasek9

[Matt Zweil - CCIE 35553 · Accepted solution]

It is likely that you are attempting to access this device on the management interface, and it is in a VRF. For the newer code versions, throw the "vrf-also" tag at the end of your access-class statement and it will work again, like so:

line vty 0 4
access-class STD_ACL_NAME in vrf-also

[Billm]

I just revisited this.
Works. Good job!

[Richard Burts]

Thanks for posting back to the forum to let us know that making that change did get SSH to work. That is good to know.

HTH

Rick

[sajan podikunju]

I see this post is old, but one thing to check is put vrf info undre line vty

line vty 0 4

access-class 12 in vrfname Mgmt-vrf

I am assuming you have vrf info on the management interface as an example below

interface GigabitEthernet0/0
 vrf forwarding Mgmt-vrf