Usually, we configure AAA for management access to the Cisco ASA, e.g., authenticating SSH access. However, something else that AAA on the Cisco ASA can be used for is to authenticate/authorize traffic that is passing through the Cisco ASA. For example, you may want internal users to authenticate before being allowed to access the Internet. Another example is that you want Internet users to authenticate before being allowed to access a particular web server. We can achieve this on the Cisco ASA by configuring cut-through proxy.

For cut-through proxy authentication on the Cisco ASA, we can use either the local database or remote servers such as RADIUS and TACACS+. However, if you will also be enabling authorization, then you can only use RADIUS or TACACS+ servers.

With respect to authentication, there are some protocols for which the ASA can perform authentication inline. These protocols include HTTP, HTTPS, Telnet and FTP on their default ports. Let me explain what inline authentication means by using an example:

  • You want users accessing a web server to be authenticated before access.
  • When a user opens an HTTP connection to that web server, the ASA will intercept the traffic and prompt the user for authentication.
  • If the user’s credentials are correct, the traffic is then redirected to the web server. (If the web server also requires authentication, the user will have to authenticate to that web server separately).

From the example above, we see that inline authentication means that the ASA will intercept the traffic and perform authentication. However, for all other protocols (e.g., ICMP), the user must first authenticate (manually) to the ASA before traffic that requires authentication is allowed. There are two ways this manual authentication can be configured:

  1. Virtual HTTP or virtual Telnet: User will first open a Telnet or HTTP connection to the virtual IP to authenticate. After successful authentication, the user’s traffic that requires authentication is allowed to pass freely.
  2. Configure a listener on the Cisco ASA so that users can authenticate directly to the Cisco ASA at the address: http(s)://interface_ip[:port ]/netaccess/connstatus.html

Let’s use the following lab setup to help our understanding of the cut-through proxy feature on the Cisco ASA:

In the above diagram, we want inside users to authenticate against the local database of the Cisco ASA when accessing the web server at 192.0.2.2 using HTTP.

Since HTTP is one of the protocols that support inline authentication, then the configuration for this is not really complex. All we need to do is match the traffic for which the user should first be authenticated in an access list and then configure this access list under the aaa authentication match command.

Note: You can also use the aaa authentication include command, where you match the traffic to be authenticated in that command itself. However, this is less flexible than using the aaa authentication match command.

To make things a bit clearer, we will also configure some prompts on the Cisco ASA so that we can differentiate between the cut-through proxy authentication and any authentication occurring at the destination server. Therefore, the configuration on the ASA is as follows:

access-list CUT_THROUGH permit tcp any host 192.0.2.2 eq www
aaa authentication match CUT_THROUGH inside LOCAL
username cisco password cisco123
!
auth-prompt prompt Cut-through Authentication
auth-prompt accept Cut-through: Authentication successful
auth-prompt reject Cut-through: Authentication rejected

The relevant configuration on the Cisco router that is acting as our web server is as follows:

ip http server
ip http authentication local
!
username ciscohttp privilege 15 secret cisco123
username ciscotelnet privilege 15 secret cisco123
!
ip route 0.0.0.0 0.0.0.0 192.0.2.1
!
line vty 0 4
 login local

To test our configuration, I will open an HTTP connection to the web server, i.e., http://192.0.2.2. The ASA should see this traffic, intercept it, and prompt the user to authenticate.

Notice that the authentication prompt says “Cut-through Authentication,” meaning that this is the authentication being done on the Cisco ASA like we configured using the auth-prompt command. If the user successfully authenticates, then they are redirected to the web server, which in our case also requires authentication:

If that authentication is also successful, the user is presented with the required web page:

Cool! So our configuration works. We can view a list of authenticated users on the Cisco ASA by using the show uauth command:

As you can see from the output above, there are two timeout values that we can configure for authenticated users—absolute and inactivity. Absolute timeout specifies how long the user will remain authenticated, after which the user will be required to authenticate again—whether traffic is flowing or not. The default is 5 minutes. Inactivity timeout specifies how long the user’s session is allowed to remain idle before being required to authenticate again. The inactivity timeout is turned off by default.

Another useful command is the clear uauth [] command, which clears the entire list of authenticated users or that of a particular user. This means the user(s) will have reauthenticate.

Before we end this article, let’s also see how inline authentication works for Telnet. I will add Telnet to our “CUT_THROUGH” access-list so that Telnet traffic is matched for authentication:

access-list CUT_THROUGH permit tcp any host 192.0.2.2 eq 23

Now let’s telnet from the PC to 192.0.2.2 and see what happens:

As you can see in the output above, authentication to the Cisco ASA first takes place. In this case, we see the “auth-prompt accept” message that we confirmed (second highlighted section). Upon successful cut-through proxy authentication, the user is then redirected to the destination server to authenticate to that server.

Summary

Let’s wrap up this article at this point. In this article, we have been introduced to the cut-through proxy feature on the Cisco ASA which allows the ASA to require authentication before certain traffic can flow through it. So far, we have only considered protocols (such as HTTP and Telnet) that support inline authentication.

In the next article, we will continue by looking at methods of authentication for protocols that do not support inline authentication. I hope you have found this article insightful and I look forward to writing the next one.

Reference and Further Reading