The intention of this command is to permit users to manage the remote pix over a VPN tunnel by its inside IP address. So if you have a site to site VPN tunnel already established, enabling this command allows you to ping the inside ip address of the Pix as an example. You can also PDM, use SNMP, or use SSH to this inside interface over the tunnel. Prior to 6.3 this was not possible. Typically, the remote Pix has a dynamic address on the outside interface, making it hard to manage. This command helps with the overall management.
If the remote Pix has a static IP address on the outside interface, then you can use the outside commands for PDM, SSH, telnet as you mention above.
I added the command but when I telnet to the inside IP address while connected from the outside using the VPN client, it responds that the PIX has actively refused the connection.
If I try PDM, I get a DNS error. Everything else is accessible with no DNS errors. PDM works fine from inside.
By the way, telnet is only allowed from the inside in my configuration. Would that be the problem?
I have a "no NAT" nat 0 access list for my VPN tunnel but that's it. Do I need to setup an additional permit access-list? Do I need to enable telnet from the outside? I thought that I could do anything via the VPN tunnel as if I was on the same network as inside.
However, correct me if I am wrong but wasn't the whole purpose of the management-access command to allow telnet, PDM, SNMP, etc. from a VPN tunnel to the inside interface without having to configure each method individually via the outside interface? The documentation is very scarce on this new command. Would someone from Cisco please add more information on this command as well as configuration examples?
By the way, I just checked the syslog. It has the following:
Local4.Error 192.168.1.1 %PIX-3-710003: TCP access denied by ACL from 10.1.1.10/1629 to inside:192.168.1.1/telnet
Local4.Error 192.168.1.1 %PIX-3-710003: TCP access denied by ACL from 10.1.1.10/1625 to inside:192.168.1.1/https
I don't have any access-list that would deny that... unless of course, it's that bottom "invisible" access-list that says anything not permitted above, deny it.
I would conclude that one would need to add a permit access-list in conjunction with the management-access entry to make it work since after all, traffic comes from a lower security interface even though it's through the VPN tunnel.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
[toc:faq]Introduction:This document describes details on how NAT-T
works.Background:ESP encrypts all critical information, encapsulating
the entire inner TCP/UDP datagram within an ESP header. ESP is an IP
protocol in the same sense that TCP and UDP are I...