KB ID 0000984
It’s been ages since I has to do this, I usually just manage firewalls via SSH from outside. But I was out on a client site last week and needed to connect to to my ASA, so I simply connected in via AnyConnect;
Normally, you would see this if you forgot to add ‘management-access inside‘ to the firewall. I was sure I had done, so I connected to one of my servers and then SSH’d to the firewall to check, and that command was there?
The cause of the problem was a change made in version 8.4(3). I had to edit the NAT rule for the remote traffic. But I’ll cover ALL the bases in case you are missing anything else.
1. Connect to the the firewall via CLI, and check management-access is on, on the interface you are connecting to, mines the ‘inside’ interface yours might be management or some other name you have allocated to the interface in question.
User Access Verification Password: Type help or '?' for a list of available commands. PetesASA> enable Password: ******** PetesASA# show run management-access management-access inside PetesASA# If yours is different or missing; PetesASA# configure terminal PetesASA(config)# management-access inside
To do the same via ASDM.
2. Now I know, my remote VPN clients are getting a 10.253.254.x addresses, (show run ip local pool should tell you, unless you are using internal DHCP for the remote clients). After version 8.4(3) you need an extra command on the end of the NAT rule for that traffic. I’ll highlight the line below;
PetesASA# show run nat nat (inside,any) source static obj-10.254.254.0 obj-10.254.254.0 destination static obj-10.253.253.0 obj-10.253.253.0 ! object network obj_any nat (inside,outside) dynamic interface object network Media_PC nat (inside,outside) static interface service tcp 467 467 ! nat (outside,outside) after-auto source dynamic VPN_Pool interface PetesASA#
3. The line highlighted above, needs ‘route-lookup’ adding to the end of it.
PetesASA# configure terminal PetesASA(config)#nat (inside,any) source static obj-10.254.254.0 obj-10.254.254.0 destination static obj-10.253.253.0 obj-10.253.253.0 route-lookup
4. At this point your VPN client(s) should now be ale to ping the interface again.
5. As with any management traffic, also ensure that the subnet you are connecting from, has been allowed.
Check SSH PetesASA# show run ssh ssh 10.253.253.0 255.255.255.0 inside ssh 10.254.254.0 255.255.255.0 inside ssh 126.96.36.199 255.255.255.255 outside ssh timeout 45 ssh key-exchange group dh-group1-sha1 PetesASA# Check Telnet (If used) PetesASA# show run telnet telnet 10.253.253.0 255.255.255.0 inside telnet 10.254.254.0 255.255.255.0 inside telnet timeout 45 PetesASA# Check ASDM (If used) PetesASA# show run http http server enable http 10.253.253.0 255.255.255.0 inside http 10.254.254.0 255.255.255.0 inside http 188.8.131.52 255.255.255.255 outside PetesASA#
5. Save the changes.
PetesASA# write mem Building configuration... Cryptochecksum: 79745c0a 509726e5 b2c66028 021fdc7d 7424 bytes copied in 1.710 secs (7424 bytes/sec) [OK] PetesASA#