After update ACL on vty acting strange, prevents SSH

[stolar]

Hi Cisco Community,

Last week I've updated Catalysts 3850 with one of actually Cisco recommended firmware, from 16.3.6 to ver. 16.3.8. All but one of our switches are in-band managed. This one is out-of-band managed and suffers of a strange behavior. After reboot I couldn't access that switch per SSH, SSH-Client gives "Connection refused". After short troubelshooting I've encountered, that an ACL, which is applied to vty lines and worked on 16.3.6, causes that problem. These ACL acts perfectly at all other in-band 3850. I've also zeroed match counters on that ACL to proof hits, and it shows 3 matches for one ssh attempt on permited line. Still, I am unable to connect via SSH.

When I take that ACL out of vty configuration, access via SSH works perfectly, but letting vty without access restrictions is not an option.

Can someone explain that behavior, hopefuly with a proper ongoing? Any ideas will be appreciated.

Best Regards,

Greg

[pieterh]

you mention in-band and out-of-band,

so you mean the out-of-band managed switch uses the dedicated management network interface right?

this uses a separate routing instance (vrf-mgmt) and will not route to other interfaces.

By default, the Ethernet management port is enabled. The switch cannot route packets from the Ethernet management port to a network port, and the reverse. Even though the Ethernet management port does not support routing, you may need to enable routing protocols on the port.

[stolar]

It's not a routing issue, as everything works well without acl on vty. Gi0/0 uses vrf instance, thats right.

This particulary switch (Name 1) is connected on backpanel Mgmt-Port, other end is connected to a Switchport from another Switch (Name 2) where Mgmt VLAN as access VLAN is configured.

The plan is to hold all VLANs from Switch Name 1 from production with possible remote maintenance. Thats why this one switch uses Mgmt-Port.

[pieterh]

I still think this  is a routing issue and the out-of-band address is accessed using another source ip-address than you think.

and this is not included in your acl.

please post more details about the ACL the switch configs and the source from where you are trying to access this switch.

[stolar]

Then how would you explain matches on acl with IP-Range of my laptop? Match counters was cleared before checking, extra deny any any was added at the end of acl for counting matches rest of traffic.

I've seen my own IP with show users on that switch when no acl was applied.

[stolar · Accepted solution]

I've found reason for that behavior, clue appeared from Router issues. Just added on line vty:

access-list NAME in vrf-also

After that all runs smoothly, VTY is with ACL secured and allows SSH from permited list.

Case closed.