cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
390
Views
0
Helpful
11
Replies
Beginner

ASDM for Remote Access VPN Users

Hi All,

I have configured Remote Access VPN to allow network administrators login remotely to manage the ASA 5506-X firewall and other devices on the network.

These administrators can login remotely via VPN and can access servers and other devices on the LAN but they can't launch the ASA ASDM.

 

: Hardware:   ASA5506, 4096 MB RAM, CPU Atom C2000 series 1250 MHz, 1 CPU (4 cores)

:ASA Version 9.8(2) 

 

Any ideas why ASDM won't launch when someone connects via Remote Access VPN?

Everyone's tags (1)
11 REPLIES 11
VIP Advocate RJI VIP Advocate
VIP Advocate

Re: ASDM for Remote Access VPN Users

Hi,

You probably need to configure "management-access", see this guide here for configuring management access over a VPN tunnel.

 

HTH

Cisco Employee

Re: ASDM for Remote Access VPN Users

hello,

 

I would suggest you to check the Ip pool for anyconnect.

 

Sh run http

sh run man

and check if access is allowed.

 

Regards

Shikha Grover 

 

*****Please mark helpful answers*****

Beginner

Re: ASDM for Remote Access VPN Users

Hi Shikha,

 

Please see below.

 

10.36.32.0/24 is the IP subnet for Inside interface and 192.168.255.0/24 is the IP address pool for VPN clients.

 

ip local pool RemoteAccess 192.168.255.2-192.168.255.254 mask 255.255.255.0

 

management-access inside

 

http server enable
http 10.36.32.0 255.255.255.0 inside_1
http 10.36.32.0 255.255.255.0 inside_2
http 10.36.32.0 255.255.255.0 inside_3
http 10.36.32.0 255.255.255.0 inside_4
http 10.36.32.0 255.255.255.0 inside_5
http 10.36.32.0 255.255.255.0 inside_6
http 10.36.32.0 255.255.255.0 inside_7
http 192.168.255.0 255.255.255.0 inside_2
http 192.168.255.0 255.255.255.0 inside_1
http 192.168.255.0 255.255.255.0 inside_3
http 192.168.255.0 255.255.255.0 inside_4
http 192.168.255.0 255.255.255.0 inside_5
http 192.168.255.0 255.255.255.0 inside_6
http 192.168.255.0 255.255.255.0 inside_7

 

CA-FW-01(config)# sh run telnet
telnet 10.36.32.0 255.255.255.0 inside_1
telnet 192.168.255.0 255.255.255.0 inside_1
telnet 10.36.32.0 255.255.255.0 inside_2
telnet 192.168.255.0 255.255.255.0 inside_2
telnet 10.36.32.0 255.255.255.0 inside_3
telnet 192.168.255.0 255.255.255.0 inside_3
telnet 192.168.255.0 255.255.255.0 inside_4
telnet 10.36.32.0 255.255.255.0 inside_4
telnet 192.168.255.0 255.255.255.0 inside_5
telnet 10.36.32.0 255.255.255.0 inside_5
telnet 192.168.255.0 255.255.255.0 inside_6
telnet 10.36.32.0 255.255.255.0 inside_6
telnet 192.168.255.0 255.255.255.0 inside_7
telnet 10.36.32.0 255.255.255.0 inside_7
telnet timeout 25
CA-FW-01(config)#

 

One thing I observed is that while connected via VPN, I can PING every host on the Inside interface of the ASA, I can browse web interfaces for Access Points, Printers and other hosts that have web server embeded in them both on port 80 and 443, I can telnet to hosts and devices on the Inside interface, etc., but I can not connect the the ASA via ASDM or telnet.

 

There is definitely something blocking connection to the inside interface from VPN clients despite that the Inside interface has been designated as the management-access interface. Please note that I can connect to the ASA via telnet or the ASDM when I am locally on the LAN behind the ASA. Furthermore, if I connect to the VPN and then RDP to a Windows PC at the office that is located on the LAN (ASA Inside interface), I can launch the ASDM, telnet to the ASA, etc.

 

Some logs in case it helps....

 

CA-FW-01(config)#
CA-FW-01(config)# sh loggin asdm | i 192.168.255
6|Jul 31 2019 22:52:04|302013: Built inbound TCP connection 484855 for outside:192.168.255.2/57729 (192.168.255.2/57729)(LOCAL\Kunle) to identity:10.36.32.253/23 (10.36.32.253/23) (Kunle)
6|Jul 31 2019 22:52:08|302013: Built inbound TCP connection 484856 for outside:192.168.255.2/57730 (192.168.255.2/57730)(LOCAL\Kunle) to identity:10.36.32.253/443 (10.36.32.253/443) (Kunle)
6|Jul 31 2019 22:52:08|302013: Built inbound TCP connection 484857 for outside:192.168.255.2/57731 (192.168.255.2/57731)(LOCAL\Kunle) to identity:10.36.32.253/443 (10.36.32.253/443) (Kunle)
6|Jul 31 2019 22:52:31|302015: Built inbound UDP connection 484859 for outside:192.168.255.2/64488 (192.168.255.2/64488)(LOCAL\Kunle) to inside_1:10.36.32.2/53 (10.36.32.2/53) (Kunle)
6|Jul 31 2019 22:52:31|302016: Teardown UDP connection 484859 for outside:192.168.255.2/64488(LOCAL\Kunle) to inside_1:10.36.32.2/53 duration 0:00:00 bytes 144 (Kunle)
6|Jul 31 2019 22:52:31|302015: Built inbound UDP connection 484861 for outside:192.168.255.2/59418 (192.168.255.2/59418)(LOCAL\Kunle) to inside_1:10.36.32.2/53 (10.36.32.2/53) (Kunle)
6|Jul 31 2019 22:52:31|302016: Teardown UDP connection 484861 for outside:192.168.255.2/59418(LOCAL\Kunle) to inside_1:10.36.32.2/53 duration 0:00:00 bytes 116 (Kunle)
6|Jul 31 2019 22:52:34|302014: Teardown TCP connection 484855 for outside:192.168.255.2/57729(LOCAL\Kunle) to identity:10.36.32.253/23 duration 0:00:30 bytes 0 SYN Timeout (Kunle)
6|Jul 31 2019 22:52:38|302014: Teardown TCP connection 484856 for outside:192.168.255.2/57730(LOCAL\Kunle) to identity:10.36.32.253/443 duration 0:00:30 bytes 0 SYN Timeout (Kunle)
6|Jul 31 2019 22:52:38|302014: Teardown TCP connection 484857 for outside:192.168.255.2/57731(LOCAL\Kunle) to identity:10.36.32.253/443 duration 0:00:30 bytes 0 SYN Timeout (Kunle)
6|Jul 31 2019 22:56:32|302015: Built inbound UDP connection 484867 for outside:192.168.255.2/62532 (192.168.255.2/62532)(LOCAL\Kunle) to inside_1:10.36.32.2/53 (10.36.32.2/53) (Kunle)
6|Jul 31 2019 22:56:32|302016: Teardown UDP connection 484867 for outside:192.168.255.2/62532(LOCAL\Kunle) to inside_1:10.36.32.2/53 duration 0:00:00 bytes 141 (Kunle)
6|Jul 31 2019 22:58:11|305009: Built static translation from outside:192.168.255.0 to inside_1:192.168.255.0
5|Jul 31 2019 22:58:11|111008: User 'enable_15' executed the 'nat inside_1 outside 1 source static NETWORK_OBJ_10.36.32.0_24 NETWORK_OBJ_10.36.32.0_24 destination static NETWORK_OBJ_192.168.255.0_24 NETWORK_OBJ_192.168.255.0_24 no-proxy-arp' command.
5|Jul 31 2019 22:58:11|111010: User 'enable_15', running 'N/A' from IP 10.36.32.172, executed 'nat inside_1 outside 1 source static NETWORK_OBJ_10.36.32.0_24 NETWORK_OBJ_10.36.32.0_24 destination static NETWORK_OBJ_192.168.255.0_24 NETWORK_OBJ_192.168.255.0_24 no-proxy-arp'
6|Jul 31 2019 22:58:11|305010: Teardown static translation from outside:192.168.255.0 to inside_1:192.168.255.0 duration 0:40:26
6|Jul 31 2019 22:58:26|302013: Built inbound TCP connection 484874 for outside:192.168.255.2/57735 (192.168.255.2/57735)(LOCAL\Kunle) to inside_1:10.36.32.253/443 (10.36.32.253/443) (Kunle)
6|Jul 31 2019 22:58:26|302013: Built inbound TCP connection 484875 for outside:192.168.255.2/57736 (192.168.255.2/57736)(LOCAL\Kunle) to inside_1:10.36.32.253/443 (10.36.32.253/443) (Kunle)
6|Jul 31 2019 22:58:49|302015: Built inbound UDP connection 484879 for outside:192.168.255.2/59733 (192.168.255.2/59733)(LOCAL\Kunle) to inside_1:10.36.32.2/53 (10.36.32.2/53) (Kunle)
6|Jul 31 2019 22:58:49|302016: Teardown UDP connection 484879 for outside:192.168.255.2/59733(LOCAL\Kunle) to inside_1:10.36.32.2/53 duration 0:00:00 bytes 144 (Kunle)
6|Jul 31 2019 22:58:49|302015: Built inbound UDP connection 484881 for outside:192.168.255.2/55399 (192.168.255.2/55399)(LOCAL\Kunle) to inside_1:10.36.32.2/53 (10.36.32.2/53) (Kunle)
6|Jul 31 2019 22:58:49|302016: Teardown UDP connection 484881 for outside:192.168.255.2/55399(LOCAL\Kunle) to inside_1:10.36.32.2/53 duration 0:00:00 bytes 116 (Kunle)
6|Jul 31 2019 22:58:56|302014: Teardown TCP connection 484874 for outside:192.168.255.2/57735(LOCAL\Kunle) to inside_1:10.36.32.253/443 duration 0:00:30 bytes 0 SYN Timeout (Kunle)
6|Jul 31 2019 22:58:56|302014: Teardown TCP connection 484875 for outside:192.168.255.2/57736(LOCAL\Kunle) to inside_1:10.36.32.253/443 duration 0:00:30 bytes 0 SYN Timeout (Kunle)
CA-FW-01(config)#
CA-FW-01(config)#

 

 

Cisco Employee

Re: ASDM for Remote Access VPN Users

Hey,

 

Try adding :-

http 192.168.255.0 255.255.255.0 inside 

Also, make sure the inside interface Ip address  or the inside interface network is added in the Split acl for VPN ( which might be there already since you are saying you are able to ping the inside hosts but please make sure of that)

 

Disconnect VPN and try to access the webgui via the browser again.

Regards

Shikha Grover 

PS: Please don't forget to rate and select as validated answer if this answered your question

 

 

 

Beginner

Re: ASDM for Remote Access VPN Users

Hi,

Thank you for your help.

The ASA didn't allow adding the statement "http 192.168.255.0 255.255.255.0 inside". It only allows adding specific Inside interfaces such as "inside_1", "inside_2", "inside_3" .... "inside_7".
Also, split-tunneling is configured already, still no luck.

Do I need to explicitly configure ACL to allow HTTPS traffic between the IP subnet (10.36.32.0/24) on the inside interface of the ASA and the subnet (192.168.255.0/24) for the the VPN client?

From the ASDM log below, you would see that attempt to access the management interface (ASA inside interface) via HTTPS gets timed out after 30 seconds:

6|Jul 31 2019 22:52:08|302013: Built inbound TCP connection 484856 for outside:192.168.255.2/57730 (192.168.255.2/57730)(LOCAL\Kunle) to identity:10.36.32.253/443 (10.36.32.253/443) (Kunle)
6|Jul 31 2019 22:52:38|302014: Teardown TCP connection 484856 for outside:192.168.255.2/57730(LOCAL\Kunle) to identity:10.36.32.253/443 duration 0:00:30 bytes 0 SYN Timeout (Kunle)

VPN client is 192.168.255.2
ASA inside interface is 10.36.32.253

Thanks.
Beginner

Re: ASDM for Remote Access VPN Users

Hi,
Access is allowed from the pool of VPN clients. Please see below:
http 192.168.255.0 255.255.255.0 inside_2
http 192.168.255.0 255.255.255.0 inside_1
http 192.168.255.0 255.255.255.0 inside_3
http 192.168.255.0 255.255.255.0 inside_4
http 192.168.255.0 255.255.255.0 inside_5
http 192.168.255.0 255.255.255.0 inside_6
http 192.168.255.0 255.255.255.0 inside_7

Management access is configured for the Inside interface of the ASA.
Hall of Fame Master

Re: ASDM for Remote Access VPN Users

Where did the reference to BVI come from? 

 

The log messages clearly show that the vpn pool is associated with the outside interface

Jul 31 2019 22:52:08|302013: Built inbound TCP connection 484856 for outside:192.168.255.2/57730

 

Try putting this into your config and let us know if the behavior changes

http 192.168.255.0 255.255.255.0 outside

 

HTH

 

Rick

Beginner

Re: ASDM for Remote Access VPN Users

Hi,
Done that already and didn't work. The management interface is the "inside" interface of the ASA.
Highlighted

Re: ASDM for Remote Access VPN Users

Hi,

 

Check that http server is enabled.

Check that VPN Pool is allowed for http access.

 

For example 192.168.100.0/24 is the VPN Pool then

http server enable

http 192.168.100.0 255.255.255.0 <Source Interface>

SD-WAN Specialist
Spooster IT Services
Beginner

Re: ASDM for Remote Access VPN Users

Hi,

Thanks for your response.
HTTP server is enabled and VPN pool is allowed to access the management interface which is the inside interface of the ASA. However, this did allow me to launch ASDM when connected to the ASA via VPN.
VIP Advocate

Re: ASDM for Remote Access VPN Users

Management access via VPN using the BVI interface is not possible currently with the ASA.

 

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCve82307

 

Symptom:
When a BVI interface nameif is used for management-access, pings to the BVI interface through the tunnel work but SSH/ASDM gets rejected. When a BVI member interface nameif is used for management-access, the ping times out due to the following reason: Drop-reason: (no-route) No route to host.

Conditions:
In the first scenario, SSH/ASDM to the ASA is not configured/allowed on the BVI interface because it isn't available in the options. In the second scenario, SSH/ASDM to the ASA is configured/allowed on the BVI member interface and works when sourcing the connection from a directly connected device to it.

Workaround:
Use a L3 interface for management-access through a S2S tunnel