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?
Cisco ASA Management Access – Understanding the Cisco ASA ‘Management-Access’ Command
cisco-asaios
Best Answer
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
andssh
commands (telnet
too, but leave it off!):Note that this configuration does not include a
management-access
command, yet works just fine. Moreso, only onemanagement-access
interface is allowed to exist, yet multiple interfaces can easily be specified in yourhttp
andssh
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:
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:
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:
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.