Management access from directly connected Anyconnect client 9.18+

[Stuart Patton]

Hi,

I have an FTD2140 running ASA and use management0/0 for SSH and HTTP management access to the firewall whether on-prem or remote.  On the 9.12 train, we can manage the same firewall we are landing on with "management-access management".  After upgrading to 9.18 this has stopped working.

ChatGPT suggests there are inconsistent issues using 0.0.0.0 as the management ACL, so I've added additional rules for the Anyconnect client ranges (no luck).  It also suggests needing an identity NAT for management-plane traffic (even though our VPN client ranges are routable within our GRT in any case) but this also has made no difference.  In another ChatGPT session, it now suggests that there are behaviour changes in 9.16 which treat management0/0 as completely OOB and dataplane traffic simply cannot reach mangement0/0, however it cannot cite any release notes or field notices that confirm this.

Same behaviour seen on 9.20 too.

Has anyone got this working at all or will we have to configure management ACLs against the inside interface specifically for when working remote?

Thanks

[Ben Weber]

Hey @Stuart Patton 

Cisco implemented a proprietary SSH stack (CiscoSSH stack) in 9.17. The CiscoSSH stack does not support SSH to a different interface over VPN (management-access). The CiscoSSH stack became the default in 9.19(1).

If you want to keep using this feature, run no ssh stack ciscossh to disable the CiscoSSH service and go back to the default ASA SSH stack.

[Stuart Patton]

Hi Ben,

The CiscoSSH stack isn't running and hasn't been running.  It also affects HTTPS (ASDM) too.

[Stuart Patton · Accepted solution]

Ok, I've found a workaround that is acceptable for my environment.

ASA 9.18(2) allows loopback interfaces to be created, so I have created a /32 lo0 and added management ACL rules that permit access from the VPN client range.  It doesn't even need to be advertised into the inside routing table, except of course, you would need to know what firewall you are landing on to know whether to use the management IP or the loopback IP.  I imagine we will transition our day-to-day admin access over to the loopback, and leave the management as a backdoor for niche cases, like if we are changing OSPF config on the inside *or* reloading the downstream switch where the OSPF neighbour lives.