
However, when configured like this: logging enable 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. 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. 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. 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. I configure it like this: logging enableĪnd, that's a train wreck. I've got a syslog server on the other side of the tunnel, to which I want the ASA to send its logs. 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. Say I've got an inside interface of 198.51.100.1 and an outside interface of 203.0.113.1. 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.īut, 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. 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 (An圜onnect 2.x client, SVC 1.x) or across a site-to-site IPSec tunnel. Well, Cisco says that it's just for when you need to manage the device from the far side of a VPN tunnel: So, what's the management-access command really do?

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. Note that this configuration does not include a management-access command, yet works just fine. 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


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