Recently had a customer contact me for help: He couldn’t access his ASDM on his ASA 5505 when connected to his remote-access VPN, but he was pretty sure he’d configured it correctly by permitting http access from the ip range assigned to VPN clients. But alas, no joy.
He had neglected to take one crucial step–by default remote-access VPN clients won’t be allowed to connect to SSH or ASDM even if their assigned IP address is in an “allowed” network. Fortunately, like everything goofy you’ll find under the hood of your Cisco device, there is an easy fix.
After connecting to his VPN, and remote-desktopping into an admin-PC, I initiated an SSH connection to the ASA, and from configuration mode, entered the following command:
labASA# conf t
labASA(config)# management-access inside
labASA(config)# end
labASA#
I then attempted to access the ASDM directly from my laptop over the VPN connection–no dice. Next, I verified the customer’s configuration for ASDM access and found the issue: A very common mistake made by novice ASA-ranch-hands trying give ASDM access to VPN users. The remote access VPN at this site is in IP range 10.1.35.0/24–note the interface named in the following config snippet… As alwas the IP ranges and hostnames have been changed to protect the guilty-parties.
labASA# show run http
http server enable
http 10.1.35.0 255.255.255.0 outside
http 10.1.15.0 255.255.255.0 inside
http 192.168.1.0 255.255.255.0 management
labASA#
Everybody makes this mistake the first time if they use the routing table to tell them how to write the rule. Normally, that would be smart… But in this case you need to turn your thinking inside out because the traffic is coming in through a vpn tunnel. Consider the ASA’s routing table…
labASA# show routeCodes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static routeGateway of last resort is 1.1.73.241 to network 0.0.0.0
C 172.16.21.0 255.255.255.0 is directly connected, guest
S 10.1.35.2 255.255.255.255 [1/0] via 1.1.73.241, outside
C 10.1.15.0 255.255.255.0 is directly connected, inside
C 1.1.73.240 255.255.255.240 is directly connected, outside
S 192.168.2.0 255.255.255.0 [1/0] via 15.15.15.15, outside
S* 0.0.0.0 0.0.0.0 [1/0] via 1.1.73.241, outside
labASA#
Traffic from the VPN passes through the external interface encapsulated–the source address for that traffic will never read 10.1.35.2 when it passes through the outside interface because its still encrypted inside the tunnel. Instead, this traffic will reach the ASA from the inside interface after being decrypted and will be accepted–if there is a correct corresponding rule in the http configuration.
To fix it, this is what I did:
labASA# conf t
labASA(config)# no http 10.1.35.0 255.255.255.0 outside
labASA(config)# http 10.1.35.0 255.255.255.0 inside
labASA(config)# end
labASA#
At this point, I was able to access the ASDM ovver the VPN tunnel. A quick exam of the SSH config showed the same miscue, and I made a similar change to allow access to SSH for VPN users. With the customer’s problems solved, I contacted him to verify none of my changes had had an unexpected adverse affect on his operation. When he said “what changes?” I knew it was okay to save my work.
labASA# wr mem
Building configuration...
Cryptochecksum: 007f7f9f 058665b8 d3a809cc ea03a49c8522 bytes copied in 3.600 secs (2840 bytes/sec)
[OK]
labASA#