Running ASDM and WebVPN on the same interface

Introduction

So you are thinking of running ASDM and WebVPN on the same interface? This is quite a rare configuration for the simple reason that ASDM is a management tool and WebVPN is usually enabled on the outside interface and best practice would dictate using an internal or even dedicated management interface to allow ASDM\CLI connections to. However, in a lab environment, this isn’t such an issue. In fact, in my labs, the machine I manage the ASA from is also the machine I test VPN connectivity from so this is a requirement for me.

Running ASDM and WebVPN on same interface

You basically have two options. You can change the port that ASDM runs on, or change the port that WebVPN runs on. As stated, this is mostly seen in a non-production environment so it probably doesn’t matter too much which way you do it but if for any reason you had to use this configuration in production, you would probably want to change the ASDM port so your remote users don’t have to worry about changing ports.

Both options are very simple to implement. To change the ASDM port, you enter a modified version of the command you enter to enable ASDM:

This changes the ASDM port to 4343. As stated, missing out ‘4343’ still enables ASDM but on the default port of 443.

To change the WebVPN port only requires an extra line:

Of course, both services can be run on the same port if required, but you need to know the URL to access ASDM. (The WebVPN URL is the default and so will load with just the IP address\hostname). The ASDM URL at time of writing on software version 9.1(2) is:

https://ipaddress/admin/public/index.html

Once you have downloaded and installed the ASDM launcher, you again don’t need to worry about having different ports as the launcher itself connects to the correct URL automatically.

Summary

There may not be many situations in which you would consider running ASDM and WebVPN on the same interface but it’s good to know it can be done from both a port and URL point of view.

Till the next time.

ASDM inaccessible on Cisco ASA 9.1(1)

Introduction

I’ll keep this short but sweet and hopefully this will save somebody a lot of head scratching out there. I unwrapped a couple of brand new ASA5512X firewalls but found the ASDM inaccessible.

ASDM inaccessible

All the standard stuff was in there, entered in global configuration mode:

I had enabled the http server and told the ASA which host address to accept connections from. I had enabled local authentication and a user name. When I connected, I got a “This webpage is not available” message.

After some sniffing around, I found a line of config that is critical:

This is the default on the two ASA devices I received. A security device. That has DES encryption as the default setting. Not very good Cisco. Not only is it weak encryption, but it stops my Chrome connecting to ASDM. Funnily enough, IE8, which was another browser on the jump box I was using allows the connection but I missed this until after I fixed it due to being a convert to Chrome for quite some time. So one option is to use an older, less secure browser. Or…

Resolution

The right fix would be to change the default ssl encryption as below:

This now allows more recent (and secure) browsers to connect to ASDM. The command above is shown in the default config in version 9.1(1). In older versions, you would need to type:

I also believe the default in older versions would be to enable pretty much all levels of SSL encryption:

Summary

The key point to remember here is, when you use a new version of software that you have become familiar with, try and find out what the differences are! I’ve not checked at which point this change was made and whilst it’s not a show stopper it is annoying.

By the way, you may have noticed I set the encryption at AES128 and some of you may be aware that AES256 is an option. The reason I currently choose AES128 over the 192 or 256 bit versions is I’ve read about vulnerabilities (albeit non-critical) with those key lengths. I’d be interested in anybody else’s take on this.

Till the next time.