What does the Cisco ASA command “management-access” do?

Question

I'm working with a Cisco ASA 5510. I changed the management interface to a different interface. I used the command "management-access" to get the new interface working, but the old interface continues to work. So I'm not sure what this command does. I thought it would make it so only the selected interface could be used for the web interface and SSH, but that is not the case. So what does it do?

Answer 1

management-access grants access to manage your device via a specific interface. You would need to add a 'no management-access ' line to stop the access from your old interface.

Answer 2

The management-access command is a bit of a misnomer - it doesn't dictate which interface can receive management traffic.

Management traffic (which interfaces it listens on, and which addresses are allowed) is controlled by the http and ssh commands (telnet too, but leave it off!):

http server enable
http 10.0.0.0 255.0.0.0 inside
ssh version 2
ssh 10.0.0.0 255.0.0.0 inside

Note that this configuration does not include a management-access command, yet works just fine. Moreso, only one management-access interface is allowed to exist, yet multiple interfaces can easily be specified in your http and ssh commands to allow traffic to come in any number of desired interfaces.

---

So, what's the management-access command really do?

Well, Cisco says that it's just for when you need to manage the device from the far side of a VPN tunnel:

This command allows you to connect to an interface other than the one you entered the ASA from when using a full tunnel IPSec VPN or SSL VPN client (AnyConnect 2.x client, SVC 1.x) or across a site-to-site IPSec tunnel. For example, if you enter the ASA from the outside interface, this command lets you connect to the inside interface using Telnet, or you can ping the inside interface when entering from the outside interface.

But, that's not really the whole story; this command is also important when the firewall is the initiator of traffic that needs to cross interfaces (say, to get encapsulated through a VPN tunnel) too.

---

Say I've got an inside interface of 198.51.100.1 and an outside interface of 203.0.113.1. It's got a VPN tunnel with a local network of 198.51.100.0/24 and a remote network of 192.0.2.0/24.

I've got a syslog server on the other side of the tunnel, to which I want the ASA to send its logs. I configure it like this:

logging enable
logging host outside 192.0.2.15
logging trap debugging

And, that's a train wreck. My syslog packets are sending with a source of the outside interface's address, trying to use my next hop on the 203.0.113.0/24 network to make it over to my private IP space on the other side of the tunnel. But they're not in the tunnel, they're in plaintext trying to route over the public internet and promptly getting dropped by the first router that sees that my remote private range 192.0.2.0/24 isn't a valid route on the internet.

The issue there is that when the source interface on the syslog packets is assigned as outside, that interface's address is used to send the packets. The destination of the packets is still 192.0.2.15 (which is within the VPN tunnel's remote network), but they're sourced from 203.0.113.1 - which doesn't match the VPN tunnel's crypto ACL; it's not in the IPSec local network.

However, when configured like this:

logging enable
logging host inside 192.0.2.15
logging trap debugging
management-access inside

The management-access command allows for the traffic sent to that interface, as well as traffic sent from that interface, to immediately traverse a different interface instead of ingressing/egressing from the inside interface directly. The source address is set correctly, the crypto ACL is matched, and the traffic makes its way over the VPN tunnel as intended.