O comando management-access é um pouco impróprio - não determina qual interface pode receber tráfego de gerenciamento.
O tráfego de gerenciamento (que as interfaces ouvem e quais endereços são permitidos) é controlado pelos comandos http e ssh ( telnet também, mas deixe-o desligado!):
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 que esta configuração não inclui um comando management-access , mas funciona muito bem. Mais ainda, é permitida a existência de apenas uma interface management-access , mas várias interfaces podem ser facilmente especificadas nos comandos http e ssh para permitir que o tráfego venha em qualquer número de interfaces desejadas.
Então, qual é o comando management-access ?
Bem, Cisco diz que é apenas para quando você precisa gerenciar o dispositivo do outro lado de um túnel VPN:
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.
Mas essa não é toda a história; Esse comando também é importante quando o firewall é o iniciador do tráfego que precisa atravessar interfaces (digamos, para ficar encapsulado por meio de um túnel VPN) também.
Digamos que eu tenha uma interface interna de 198.51.100.1 e uma interface externa de 203.0.113.1. Ele tem um túnel VPN com uma rede local de 198.51.100.0/24 e uma rede remota de 192.0.2.0/24.
Eu tenho um servidor syslog no outro lado do túnel, para o qual eu quero que o ASA envie seus logs. Eu configuro assim:
logging enable
logging host outside 192.0.2.15
logging trap debugging
E isso é um acidente de trem. Meus pacotes syslog estão enviando com uma fonte do endereço da interface externa, tentando usar meu próximo salto na rede 203.0.113.0/24 para passar para o meu espaço IP privado no outro lado do túnel. Mas eles não estão no túnel, eles estão em texto sem formatação tentando rotear pela Internet pública e sendo rapidamente descartados pelo primeiro roteador que vê que minha faixa privada remota 192.0.2.0/24 não é uma rota válida na internet .
O problema é que quando a interface de origem nos pacotes syslog é atribuída como externa, o endereço dessa interface é usado para enviar os pacotes. O destino dos pacotes ainda é 192.0.2.15 (que está dentro da rede remota do túnel da VPN), mas eles são provenientes de 203.0.113.1 - que não coincide com a criptografia ACL do túnel VPN; não está na rede local IPSec.
No entanto, quando configurado assim:
logging enable
logging host inside 192.0.2.15
logging trap debugging
management-access inside
O comando management-access permite o tráfego enviado para aquela interface, assim como o tráfego enviado da interface, para atravessar imediatamente uma interface diferente, em vez de ingressar / sair diretamente da interface interna. O endereço de origem está definido corretamente, a ACL criptografada é correspondida e o tráfego faz o seu caminho através do túnel VPN como pretendido.