In the last article, we began looking at the cut-through proxy feature on the Cisco ASA. In that article, we discussed the fact that the Cisco ASA supports inline authentication for some protocols, such as HTTP and Telnet. We then configured a lab to see how inline authentication works.

In this article, we will go on to look at ways through which the Cisco ASA can authenticate protocols for which inline authentication is not available. Our lab setup remains the same from the previous article, as shown below:

Virtual HTTP/Telnet

The first option we will consider is using the virtual HTTP or Telnet server. Users will first need to authenticate directly to the virtual server, after which traffic that requires authentication will be allowed to pass through.

When we enable authentication for HTTP traffic flowing through the ASA (as we did in the last article), basic HTTP authentication is used by default and the same username/password used to authenticate to the Cisco ASA is also sent to the destination server. This may cause an issue if the user credentials on the Cisco ASA are not the same as those used to authenticate on the destination server. However, when we enable the virtual HTTP server, the ASA does not forward the username/password to the destination server and, if that user is required to authenticate to the destination server, a separate authentication process will occur.

Note: In our last article, the Cisco ASA actually forwarded the username/password we used for cut-through authentication to the web server but the web server rejected the authentication because there was no “cisco” user on that server (we configured “ciscohttp” and “ciscotelnet”). This happened in the background and what we saw was that the web server requested its own authentication. You can also use a packet capture tool (e.g., Wireshark) to capture and view packets between the Cisco ASA and the web server. If you look into the authentication information in the HTTP packets, you will see two different ones—one for “cisco/cisco123” and another for “ciscohttp/cisco123.” Another way to test this is to configure the “cisco” username with password “cisco123” on the web server and test your authentication again. You will notice that you only get the cut-through authentication prompt and then you are presented with the web page of the web server.

Back to our lab: Let’s configure the Cisco ASA to require authentication for ICMP traffic going to the web server. To do this, we can enable either the virtual Telnet or HTTP server; let’s go with the virtual Telnet server, which I will enable on a free IP address routed to the ASA. In our case, I will use

We will add the following configuration on the Cisco ASA (refer to last article for previous configuration on the ASA):

virtual telnet
access-list CUT_THROUGH permit icmp any host
access-list CUT_THROUGH permit tcp any host eq 23

Notice in the configuration above that the “CUT_THROUGH” access list also includes an entry for the Telnet traffic to the virtual server. Without this entry, the ASA will not prompt the user to authenticate.

To test this configuration, I will try to ping from the PC to the server (before authenticating).

The ping failed. If you enabled logging on the ASA while the ping was going on, you will see a message similar to this:

%ASA-6-109001: Auth start for user '???' from to
%ASA-3-109023: User from to on interface inside using icmp must authenticate before using this service

The ASA is telling us that we need to authenticate before that traffic is allowed; so let’s authenticate and then try that ping again:

Cool! If the user wants to logout, he/she can telnet to the virtual server again and enter his/her credentials:

aaa authentication listener

The second option we can use for protocols that the ASA does not support inline authentication for is to configure the ASA to listen for authentication requests on a particular interface and port. This is achieved using the aaa authentication listener http[s] interface_name [port port_num] [redirect] command. If this command is configured without the “redirect” keyword, normal HTTP traffic through the Cisco ASA will still be authenticated using basic HTTP authentication while for other protocols, users will need to authenticate directly to the ASA by navigating to http(s)://interface_ip[:port ]/netaccess/connstatus.html.

On the other hand, if the “redirect” keyword is used, then normal HTTP traffic through the Cisco ASA will also be redirected to the Cisco ASA’s internal web page for authentication.

Let’s look at examples using both the “redirect” option and without that option. We will start our configuration on the ASA without the “redirect” keyword:

no virtual telnet
aaa authentication listener http inside
! Remove previous access control entry for virtual Telnet server
no access-list CUT_THROUGH permit tcp any host eq 23
access-list CUT_THROUGH permit tcp any host eq www

Without the “redirect” option, normal HTTP traffic flowing through the ASA will use basic HTTP authentication, as shown below:

To see how other protocols will be authenticated, I will clear this authenticated session using the clear uauth command. Then, I will open a web page to The first page I am presented with is shown below:

If I click the “Log In Now” button, I will be required to authenticate against the Cisco ASA i.e. cut-through proxy authentication:

Upon successful login, the traffic that requires authentication is now allowed to pass through unhindered:

Let’s now try our configuration with the “redirect” option:

clear uauth
aaa authentication listener http inside redirect

The only difference now is that when a normal HTTP session is going through the Cisco ASA, the user will be redirected to the internal web page of the ASA for authentication:

If the authentication is successful, the user is then redirected to the initial destination server he/she was trying to access. If that destination server requires authentication, the user will also need to present authentication credentials.

Note: Unlike basic HTTP authentication, the Cisco ASA does not forward the user’s authentication details to the destination server when the aaa authentication listener is used.


In this article, we have looked at two options through which the Cisco ASA can authenticate users for protocols which inline authentication is not supported. The first method we considered was enabling the virtual server (HTTP/Telnet) while the second option uses the aaa authentication listener command for authentication to be done at an internal web page of the Cisco ASA.

In the next article in this mini-series, we will discuss cut-through proxy authorization for users. I hope you have found this article insightful.

Reference and Further Reading