Cut-Through Authentication proxy on the ASA is an excellent way to track and authorize users when they access resources on the network that you may not want them to access to originally. I have used it to track user activities, authorize users to different network devices from time to time that they really should not be accessing whenever they feel, and to provide a user a way to override the firewall policies that have been defined for a given subnet. In other words, it is a very useful function and I believe it’s function is vital for users as well as the network administrator. Just so you know, this feature is just like the Auth-Proxy or Network Admission technologies on an IOS router.
Here is the topology we will be working with. I have setup a PC so we can simulate a typical user experience.
Guidelines
Any user on the 192.0.2.0/24 subnet (Inside) will have to authenticate through to the ASA when accessing the IOS Firewall Router.
This user authentication through the ASA will be of the most secure form.
The ASA will use local authentication for the users for the time being
Setup Cut-Through Proxy
So the first step would be to define IP addressing and initialize interfaces as well as routing. The HTTP services have been enabled on the IOS router as well as local authentication/authorization of users to this service. We will focus our efforts on the ASA for our cut through authentication.
So step one is going to make sure we have connectivity to the devices first. So let us make sure we can ping 198.18.0.2 from our PC (PC is 192.0.2.100 in my environment)
C:\ >ping 198.18.0.2
Pinging 198.18.0.2 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 198.18.0.2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Ok, already not a good start. From the ASA I can ping the PC as well as the IOS router. The default gateway of each of these devices points to the ASA. Hmmm. Don’t forget about icmp inspection or allowing icmp echo-replies back through the firewall on the outside interface. Here we will inspect icmp.
ciscoasa(config)# fixup protocol icmp
INFO: converting ‘fixup protocol icmp ‘ to MPF commands
Ok, now lets try our ping again
C:\ >ping 198.18.0.2
Pinging 198.18.0.2 with 32 bytes of data:
Reply from 198.18.0.2: bytes=32 time<1ms TTL=63
Reply from 198.18.0.2: bytes=32 time<1ms TTL=63
Reply from 198.18.0.2: bytes=32 time<1ms TTL=63
Reply from 198.18.0.2: bytes=32 time<1ms TTL=63
Ping statistics for 198.18.0.2:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
oximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Ok, that looks better. The other test I like to do is access the http server on the IOS Router to make sure that we are able to get the default web page from the router so we know that this worked before we started our configuration. This will make it so there is one less thing to check if it doesn’t work. So let’s define an access-list to classify the interesting traffic for cut-through proxy:
ciscoasa(config)# access-list ctap permit ip any host 198.18.0.2
And let’s configure our local username and password as our guidelines say to use the local database:
ciscoasa(config)# username cisco password cisco
Now we will enable cut-through proxy with our interesting traffic and local database authentication :
ciscoasa(config)# aaa authentication match ctap inside LOCAL
So what should we see at this point is a web authentication box popup that is asking us for credentials. This is the cut through authentication service requesting user credentials before allowing the connection onto the IOS router. So we will enter our credentials of cisco/cisco. Then click on “OK” for the web authentication and we should be allowed to the IOS Router now.
Let’s verify the user on the ASA
ciscoasa(config)# sh uauth
Current Most Seen
Authenticated Users 1 1
Authen In Progress 1 1
user ‘cisco’ at 192.0.2.100, authenticated
absolute timeout: 0:05:00
inactivity timeout: 0:00:00
With the ASA we have another option in which the user authentication experience occurs. Instead of the popup, we can have a webpage display the authentication prompt. It is a little more user friendly this way and is more like the auth-proxy http web page from an IOS router, only better. To do this we enter the following command.
ciscoasa(config)# aaa authentication listener http inside redirect
Using the above option, we could also redirect the authentication to another port if needed using the argument “port ‘#’” in the command shown above.
So in our guidelines we actually wanted the most secure mode of communications. Well, using http in this fashion is not secure at all. So we will want to change our configuration so that we request the user credentials using https.
To do this, we will install 2 commands.
ciscoasa(config)# aaa authentication listener https inside redirect
ciscoasa(config)# aaa authentication secure-http-client
Now depending on how the ASA is configured for PKI support, you will either come to a page with a certificate warning or you will go right the authentication page. This is now a secure login screen for the user.
This concludes our quick introduction into Cut-Through Authentication on the ASA. There are several more features than can become involved such as including an ACS server for authentication/authorization, virtual telnet/http, and even downloadable access-lists that can override an interface access-list. Join me in feature posts where we will discuss these enhancements. I hope this is useful to you and thank you for visiting this post.
