ASA Cut-Through Proxy: Part 1

In the previous post, I discussed the IOS Authentication Proxy and hw it is used for 'authorization' using downloadable access-lists. In this post, I would describe the Cut-through proxy feature of the ASA.

The Proxy Authentication feature of the ASA is tied to the AAA process.
Authentication proxy can be configured for any protocol but authentication is performed by the telnet, http, https and FTP protocols. If any other protocol is requires authentication, one of the other "authentication protocols" (ftp, http(s) or telnet) MUST also be configured to authenticate the user before access can be granted.
Once a protocol is configured for authentication under the AAA process, unauthenticated users are not given access to the protocol.

The Authentication and Authorization processes are separate on the ASA.
Users can be authenticated using the local database, tacas+ server and the RADIUS server. Users can only be authorized with Radius or Tacacs+ but not the local user database.

Unlike Auth-Proxy, the traffic required for authentication MUST be allowed in the access-lists otherwise Authentication/Authorization wouldnt be able to take place. Authorization can be used to allow further traffic.

Lets look at a simple example of proxy-authentication using the local database. Assuming we have the topology:

R1 ---- (inside)ASA(outside) ---- R2

Base configuration:

interface Ethernet0
nameif inside
security-level 100
ip address 10.10.10.1 255.255.255.0
!

interface Ethernet1
nameif outside
security-level 0
ip address 192.168.1.1 255.255.255.0
!

1. Specify traffic to be Authenticated using an access-list

access-list AUTH extended permit icmp any any
fixup protocol icmp

The fixup protocol is used to ensure icmp traffic is inspected. (It is a quick fix compared to using the MPF). Another option would be to allow icmp inbound on the outside interface.

2. Configure AAA server: We would just add a user since we are using the local database.
username Amplebrain password cisco


3. Configure AAA on the ASA

aaa authentication match AUTH inside LOCAL
auth-prompt prompt Authenticate Before Access
auth-prompt accept Access Granted
auth-prompt reject Access Denied

The line "aaa authentication match AUTH inside LOCAL" means that traffic matched by the AUTH access-list on the inside interface must be authenticated using the local database before they can be allowed to pass through.

4. Test

R1#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

We cant reach R2. This is because we are authenticating icmp protocol but icmp is NOT one of the authentication protocols. At least one authentication protocol configured for authentication for this to work.
The ASA uses the virtual command for this.


5. Configure Virtual Telnet address and add 2.2.2.2 to the AUTH traffic

virtual telnet 2.2.2.2
access-list AUTH extended permit tcp any host 2.2.2.2 eq telnet

The authenticating user must have a route to 2.2.2.2 for this to work properly.

6. Test Again: Authenticate with virtual telnet and then ping.


R1#telnet 2.2.2.2
Trying 2.2.2.2 ... Open

LOGIN Authentication

Authenticate Before Access
Username: Amplebrain

Password:
Access Granted

Authentication Successful


[Connection to 2.2.2.2 closed by foreign host]
R1#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max =
24/88/196 ms
R1#


On the ASA, we can show authenticated users

ASA(config)# sh uauth
Current Most Seen
Authenticated Users 1 1
Authen In Progress 0 1
user 'Amplebrain' at 10.10.10.3, authenticated
absolute timeout: 0:05:00
inactivity timeout: 0:00:00
ASA(config)#

The next post would describe proxy-authorization using the Radius Server.

Compliments of the season :-)

Amplebrain.