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 enablehttp 10.0.0.0 255.0.0.0 insidessh version 2ssh 10.0.0.0 255.0.0.0 insideNote 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, 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.
Cisco Firewall:: Can't Ping ASA 5510 Inside Interface Apr 13, 2013. I ran into a very strange icmp ping issue. The network has been working fine other than the issue listed below, L2L VPN works fine and all three data centers can access each other via L2L VPN.I have three ASA5510. Cisco ASA 5505 – Dual Internet Connections with a Base Licence By Kerry in Blog; August 1, 2017. There’s no need for the ISPs to talk to each other via those interfaces, so we should be all good to go. This shows that all traffic will be going out via the outside interface which is the ethernet connection bound to VLAN 2.
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 enablelogging host outside 192.0.2.15logging trap debuggingAnd, 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 enablelogging host inside 192.0.2.15logging trap debuggingmanagement-access insideThe 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.