What is a Cut-Through Proxy on the ASA?

Quick Definition: A cut-through proxy is a rule applied to an ASA that enables the ASA to, on behalf of another device, stop traffic as it's coming in, authenticate its originator at Level 1, and allow all future packets from the same user to cut through at Level 3.

A cut-through proxy allows you to stop users before they hit your servers that sit behind an Adaptive Security Appliance, and verify who they are.

A Quick Overview of Cut-Through Proxies [VIDEO]

In this video, Keith Barker covers cut-through proxy on an ASA. Just because your server's online doesn't mean it needs to be public — configure a cut-through proxy on your ASA and your firewall will authenticate users before they can even reach your server.

What Happens Before a Cut-Through Proxy Comes Along?

Usually what precedes a cut-through proxy is a network environment that has web servers sitting behind an ASA, but authentication is happening on the "inside".

Imagine for a moment that you're working in an IT shop for a mid-sized organization. Your boss has a new requirement for you. She comes in, sits down and tells you, "We've had two great weeks. Two weeks ago, you set up the firewall and our ASA. And then last week I asked you to get our web server out onto the internet. And you've been able to do both. Based on what you told me, you set up network address translation, you created an access list that allows Port 80, and everyone's able to reach the web server. You did just what we wanted."

But then she goes on, "Unfortunately, we don't want it to be a public web server. We don't want anyone who happens to have the url to get access to everything we've got on that server. We only want it to be available to a few, certain users. Can you help?"

You have a few options in your toolbelt. One option is to control access at the server itself. You could set up the server so that when people connect, they perform user authentication there, at the server. If the user doesn't authenticate, close the connection. That's one approach, but it has problems.

What Problems Does a Cut-Through Proxy Solve?

Before you set up a cut-through proxy on your ASA, you run the risk of your resources and services being unprotected — or having people bypass your firewall with nothing more than a destination url.

Take the example above. If you set up your authentication on the server itself, those users are already bypassing your firewall. Not only is it not exactly that server's job to handle all those requests, the ASA's job is to stop rogue packets. You don't just want to let them past by default. Why not stop traffic at the firewall and ask them to authenticate there instead? That's exactly what a cut-through proxy is all about.

We can train an ASA that when inbound traffic is coming to a certain server, the ASA should, on behalf of the server, stop that traffic, ask the user who they are, and if they're a valid user, allow that traffic to continue down to the server.

Why is It Called a Cut-Through Proxy?

A cut-through proxy rule tells the ASA that packets after the first can "cut through" the reference model's authentication, and the ASA does that work on behalf of a server.

First, we should imagine the path that the packets will take in our hypothetical set-up. Imagine a user named Bob. Bob is out on the internet, sitting at 21.1.2.3, and he's seeking to access our web server that sits behind an Adaptive Security Appliance. When the packets first show up to the ASA, the ASA interrogates the packets to find out where they're coming from.

That can, in effect, be thought of as going all the way up to the Application Layer of the OSI Reference Model, or in this case the TCP/IP protocol suite, and taking time to authenticate that user. Once that user is authenticated, the packet can proceed back down the OSI Reference Model and be shipped out.

So it's on the first packet that the ASA confirms Bob's identity and location. On subsequent packets sent from Bob, we don't have to stress the ASA – the packets take a different route.

The ASA knows that Bob's address appears to be 21.1.2.3 – from the global internet. And it'll remember that address and that Bob is authenticated. The ASA doesn't have to go ahead and authenticate every packet that follows, the ASA can make forwarding decisions at Layer 3. Because the ASA already knows who BOB is.

So the first packet goes all the way up the Application Layer logically, and then the subsequent packets can cut through that process. Hence the "cut through". And "proxy" comes from the fact that our ASA is proxying security for the server that sits behind the ASA.

When Do You Need a Cut-Through Proxy?

In the event that we want to authenticate a user as they're trying to go through the network. In our above example, that's users on the outside trying to go to the internal web server. Anytime you want to control who can get to your services and you need to verify who they are before the ASA forwards it to the server, a cut-through proxy is the perfect application.

What to Check Before Implementing a Cut-Through Proxy

Any time you're making changes to authentication methods, it's a good idea to verify that your basic web services are actually working in the first place. Making sure your environment is doing everything properly like this can save you a lot of time. If something goes wrong later, you don't want to run the risk of trying to debug your proxy protocol for hours when it was actually a cable that was never plugged in.

In our case, we'll want to start from the "outside" and attempt to navigate to the mapped address of the webserver we've set up as our target on the "inside". So open a web browser on an outside connection and navigate to the IP address of the inside web server – it should succeed.

How To Configure a Cut-Through Proxy on an ASA

Configuring a cut-through proxy on your ASA has to be done in ASDM. To do so, there are a few things to look at first.

Under the Configuration button in the top panel, and Device Management in the left sidebar, confirm that you've got AAA servers set up. Or if you're going to use a local database, make sure that there's at least one local user account.

Both of those are in the Device Management menu, under the Users/AAA heading, inside AAA Server Groups and User Accounts.

For the purposes of our explanation, we're assuming you're using a local database on your ASA. To write the requirement for the authentication, go to Configuration in the top panel and Firewall in the left sidebar. Then select the AAA Rules heading.

From there, simply press "Add…" to add a new authentication rule. In the window that will pop up here, select "outside" as the desired Interface. Make sure that the local database will authenticate (if this is how you're authenticating).

Confirm that the Source can be "any". And make sure that the Destination points to the IP address of the web server (for our explanation).

Lastly, you'll want to make sure that Service is set to "tcp/http" if you only want HTTP traffic to be authenticated.

Note: This is one of the great things about NAT in 8.3 and higher in the ASA</a>. Anytime we have access lists or AAA policy rules, we point to the real IP address, even though the global address is different. That way we can focus on the single item and not have to worry about the translations based on which interface it went out of.

By clicking "OK" on that window and "Apply" at the bottom of the main ASDM window, ASDM will display the Command Line Interface commands that were generated by the changes you've made.

First, let's look at the commands verbatim, and then let's translate them into English:

access-list outside_authentication line 1 extended permit tcp any object dmz-server eq http
aaa authentication match outside_authentication outside LOCAL

The first line translates to, "Traffic matches if it's TCP, from anywhere, to the dmz server and the destination port equals 80."

The second line is where the magic happens. It says, "AAA authentication is required if there's a match on this access list (referring to the first line), and traffic is coming in on the outside interface. In that case, use the local database."

Note: Remember, in ASA, the keyword "LOCAL" has to be in the UPPERCASE to refer to the running config for user account authentication.

You'll have to click on "Send" to complete the process, and doing so sends those two CLI commands that ASDM automatically generated for you to the ASA.

How To Verify a Cut-Through Proxy

Head back to the same browser window you used before and try to open the same IP address you visited previously. If everything has gone right, you should now see a prompt for credentials. Assuming you've set up your database access list correctly, you should know the username and password that will allow you access to the resource.

Another way to confirm is to go to the CLI. Make sure you do this after authenticating. You can instruct the CLI to show current users who are authenticated with the command "show uauth".

If you're still logged in, you should see the total number of users, their usernames, IP addresses they've originated from, their absolute timeout and their inactivity timeout.

Note: defaults are five minutes for absolute timeout and no inactivity timer set.

Let's Recap: Cut-Through Proxies on an ASA

A cut-through proxy grants the ability for the ASA to stop traffic as it's coming in, and on behalf of another device, authenticates the user all the way up at the Application Layer. Once we know who the user is, the ASA remembers the user and the source IP address for future packets and lets those packets cut through the entire process. That happens with basic forwarding at Layer 3. And this lasts until the user's authentication session ends.

You'll need a cut-through proxy any time you want to control who can get to your services and verify who they are before the ASA forwards the traffic to the server. You can do all this by configuring a cut-through proxy as a firewall rule under the AAA section in your ASDM.

Armed with this knowledge, you should be prepared to keep your networks safe and secure and your users happily accessing needed resources over the internet.