Troubleshooting Cut-Through Proxy Authorization using the RADIUS Protocol

Troubleshooting Cut-Through Proxy Authorization using the RADIUS Protocol
To determine the currently authenticated users, the host IP to which they are bound, and any cached IP and port authorization information, use the show uauth command as follows:

PIX# show uauth [username]



If you do not specify a username, all authenticated users' information will be displayed.

Example 10-25 shows the output of the show uauth command when no user is authenticated.

Example 10-25. Output of the show uauth Command With No Users Authentication
PIX(config)# show uauth
Current Most Seen
Authenticated Users 0 0
Authen In Progress 0 1

PIX(config)#





When a user is authenticated, user authentication and authorization information can be found with the show uauth command, as shown in Example 10-26.

Example 10-26. Output of the show uauth Command When Users Are Authenticated/Authorized
PIX# show uauth
Current Most Seen
Authenticated Users 1 1
Authen In Progress 2 3
user 'kodom' at 192.168.2.2, authorized to:
port 192.168.1.2/telnet
absolute timeout: 0:05:00
inactivity timeout: 0:00:00
PIX-A# Jul 25 2005 09:03:19 : %PIX-7-111009: User 'enable_3' executed cmd: show uauth

PIX#





Once you verify the user authentication, the next step is to verify whether the ACL tag is downloaded correctly to the PIX firewall. If PIX is configured with an ACL (not applied to any interface) and if the ACL tag is downloaded from the AAA server upon successful user authentication, the ACL should be applied for the authenticated users. This can be verified with the command shown in Example 10-27.

Example 10-27. show access-list Command Output After Successful Download of ACL Name/Number for Allowing Telnet
PIX# show access-list
access-list AAA-user-cse; 2 elements
access-list AAA-user-cse permit tcp any any eq telnet (hitcnt=1)
access-list AAA-user-cse deny ip any any (hitcnt=0)
PIX#





If the ACL content is downloaded from the RADIUS Server, the downloaded ACL looks like that shown in Example 10-28.

Example 10-28. Output of the show access-list Command When the Content of the ACL Is Downloaded to the PIX from the RADIUS Server
PIX# show access-list
access-list #ACSACL#-PIX-cse_access_list-3cff1bb3; 2 elements
access-list #ACSACL#-PIX-cse_access_list-3cff1bb3
permit tcp any any eq telnet (hitcnt=1)
access-list #ACSACL#-PIX-cse_access_list-3cff1bb3
deny ip any any (hitcnt=0)
111009: User 'enable_15' executed cmd: show access-list
PIX#





If the show uauth or show access-list command does not show you the output as expected, you can run the debug and analyze the log to see the reason for failure on the PIX firewall as on the Cisco Secure ACS Server.

Example 10-29 shows the syslog for user authentication for only Telnet access and denial of other traffic when ACL content is downloaded from the CS ACS to the PIX firewall.

Example 10-29. PIX Debugs for a Valid Authentication and Downloaded Access List
PIX# show log
. . . . . .
305011: Built dynamic TCP translation from inside:
192.168.1.2/11063 to outside:40.1.1.1/1049
109001: Auth start for user '???' from 192.168.1.2/11063
to 40.1.1.1/23
109011: Authen Session Start: user 'cse', sid 10
109005: Authentication succeeded for user 'cse'
from 192.168.1.2/11063
to 40.1.1.1/23 on interface inside

302013: Built outbound TCP connection 123 for outside:
40.1.1.1/23 (40.1.1.1/23) to inside:
192.168.1.2/11063 (20.1.1.1/1049) (cse)
. . . . . .
PIX#





Following are some of the causes for an authorization failure with the RADIUS protocol for a cut-through proxy connection:

Override keyword is missing from the access-group statement If you have an access-group applied on the interface, you need to ensure that you have the override optional argument configured in the access-group statement. Otherwise, traffic must be allowed by both interface ACL and per-user ACL configured on the PIX firewall. The syntax for the access-group statement is as follows:

access-group access-list {in | out} interface interface_name [per-user-override]

There is a mismatched ACL Name/Number between the PIX and CS ACS If you have configured the access-list on the PIX firewall, or the ACL name is defined on the AAA server, ensure that the names match each other. The name is case sensitive. Otherwise, the proper ACL will not be applied for the user traffic, which might result in unexpected behavior.

Accounting for Cut-Through Proxy
You can use the following syntax to configure accounting for cut-through proxy connection:

[no] aaa accounting {include | exclude} service interface-name local-ip local-mask
foreign-ip foreign-mask server-tag



For example, to turn on accounting for all inbound traffic, you may execute the following command:

PIX(config)# aaa accounting include any outside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
AuthInbound



However, it is recommended to use the following syntax to configure cut-through proxy accounting:

PIX(config)# [no] aaa accounting match acl-name interface-name server-tag



The following command shows how to turn on accounting for all inbound traffic using ACL.

PIX(config)# access-list 150 permit ip any any
PIX(config)# aaa accounting match 150 outside AuthRadius



If the accounting does not work as expected, you need to analyze the log on both the PIX firewall and on the AAA server. You need to first examine the debug output of the following command to see if the PIX is generating the accounting packets correctly or not:

PIX# debug aaa accounting



Additionally, to see the interaction of accounting records from the PIX firewall to AAA server, you can use either of the following commands depending on the type of protocols you are using:

PIX# debug radius
PIX# debug tacacs



If the accounting appears to be working correctly on the PIX firewall, you can analyze the log on the AAA server to see if the problem is with the AAA server. If Cisco Secure ACS is used for AAA, refer to "Troubleshooting Cisco Secure ACS on Windows" for additional details.

Extended Authentication (X-Auth) Issues for Remote Access VPN Connection
Extended Authentication (X-Auth) is an enhancement of IKE version 1 for a Remote Access VPN connection that allows performing both user and group authentication. When X-Auth is configured on the PIX firewall (FWSM does not support VPN), users are prompted to enter username and password, which is either locally stored in the PIX firewall or in any external database, such as Cisco Secure ACS, ACE Server, NT domain and so on. Extended authentication is performed after IKE phase 1 and before phase 2. In phase 1, group authentication takes place, then X-Auth is performed. Right after X-Auth, if authentication is successful, mode configuration takes place, where PIX Firewall pushes configuration parameters for VPN clients, such as DNS Server IP, WINS Server IP, and so on.

Beginning with PIX Firewall Version 5.2, X-Auth includes support for access-list which allows you to control what traffic needs to be encrypted and what traffic should be transmitted in clear text. The minimum VPN client version requirement is 2.5. This feature is called split-tunneling. If you have a requirement to allow the VPN client to connect to the internal network of the VPN Gateway using the secured tunnel, but want the rest of the traffic to go to the Internet in clear text from the VPN client, you need to configure split-tunneling.

Beginning with PIX Firewall Version 6.2, the download of access-control lists (ACLs) from an AAA server to the PIX firewall is supported. This enables the configuration of a per-user ACL on an AAA server to provide per-user ACL authorization. It is then downloadable through the AAA server to the PIX firewall. This feature is supported for RADIUS servers only, not with TACACS+ servers.

Configuration Steps
With PIX Firewall versions earlier than 7.0, to apply x-auth, use the following command:

[no] crypto map map-name client [token] authentication aaa-server-name [LOCAL]



With username, you can define local users on the PIX firewall. To use the local user database, use the key word LOCAL. Otherwise, define a AAA server and assign the same name defined in the preceding command.

Beginning with PIX Version 7.0, you can define attributes for users who are locally created on the PIX firewall.

Work through the steps that follow to configure the X-Auth for PIX Version 7.0 and above.


Step 1. Create the local user database and define the attributes for the user as shown in Example 10-30.


Example 10-30. Creating a Local User Database
PIX(config)# username laurie nopassword privilege 15
PIX(config)# username laurie attributes
! DefaultGroupPolicy will be applied to this user
PIX(config-username)# vpn-group-policy DefaultGroupPolicy
! Following are to set up the timeout values
PIX(config-username)# vpn-idle-timeout 10
PIX(config-username)# vpn-session-timeout 120
! This user will create IPSec tunnel
PIX(config-username)# vpn-tunnel-protocol IPsec
PIX(config-username)# exit
PIX(config)# exit
PIX#





To remove all attributes for a specific user, use the following command:


PIX(config)# no username laurie attributes


To remove a specific user, use the following command:


PIX(config)# no username laurie


To clear the username database from the firewall, use the following command:


PIX(config)# clear config username
username cisco1 password jmINXNH6p1BxUppp encrypted privilege 15
PIX#




Step 2. Create a new tunnel group that supports IPsec remote access tunnels as shown in Example 10-31. Here you can specify whether you want to use the local user database or the external AAA server. Be sure that the external AAA server is configured before you attempt to define an AAA server.


Example 10-31. Creating a Tunnel Group of IPsec Remote Access
PIX(config)# tunnel-group tungrp1 type ipsec-ra
! Now enter the general-attributes mode to define the AAA server.
PIX(config)# tunnel-group tungrp1 general-attributes
! The following lines will turn on both authentication and authorization using
! local user database.
PIX(config-general)# authentication-server-group LOCAL
PIX(config-general)# authorization-server-group LOCAL
! Instead of using local user database, if you want to use RADIUS protocol, use
! the following commands to turn on authentication/authorization and accounting.
! Note that for authentication and authorization using RADIUS protocol is done
! in the same packet. So no need to have the authorization statement to turn on
! authorization. Authentication statement is sufficient.
PIX(config-general)# authentication-server-group AuthRadius
PIX(config-general)# accounting-server-group AuthRadius
PIX(config-general)# exit
! If you want to assign IPSec specific attribute you can execute the following
! command which will provide you with the IPSec related attributes.
PIX(config)# tunnel-group tungrp1 ipsec-attributes
PIX(config-ipsec)#





Now to remove all general attributes for this tunnel group:


PIX(config)# no tunnel-group tungrp1 general-attributes


To remove our tunnel-group specifically by name:


PIX(config)# clear config tunnel-group tungrp1


To clear the tunnel-group database:


PIX(config)# clear config tunnel-group



Step 3. For accounting to work correctly, configure the following two commands:


PIX(config)# sysopt connection permit-ipsec
PIX(config)# sysopt ipsec pl-compatible




Troubleshooting Techniques
Troubleshooting AAA for the Remote Access VPN is very similar to of the troubleshooting described in the sections entitled "Firewall Management with AAA Troubleshooting" and "Cut-Through Proxy with AAA Troubleshooting," with some exceptions. As the connection type is VPN using IPsec, in addition to AAA troubleshooting, you also need to troubleshoot the VPN problem. To debug Remote Access VPN, you may want to refer to Chapter 7, "Troubleshooting IPsec VPN on PIX Firewalls." Following are the two commands that you need to use to troubleshoot IPsec VPN issues:

PIX# debug crypto ipsec 5
PIX# debug crypto isakmp 5
PIX# debug crypto engine 5
PIX#



To troubleshoot AAA issues for the VPN connection, look at the log on VPN Client Log Window, debug on the PIX firewall, and the log on the AAA server.

To turn on logging to the debug level on the VPN client, go to Start > Programs > Cisco Systems VPN Client > VPN Client. Then click on Log Settings and set User Authentication log to High. It is recommended that you also set all other classes to high if the tunnel is failed and you are uncertain about the reason of failure. Refer to Chapter 7, "Troubleshooting IPsec VPN on PIX Firewalls."

To turn on debug level syslogging, refer to the "syslog" subsection of section entitled "Diagnostic Commands and Tools" in this chapter. Run the following command to get details about AAA problems:

PIX# debug aaa authentication
PIX# debug aaa authorization
PIX# debug aaa accounting
PIX# debug aaa vpn 5
PIX# debug radius



If you have authentication problems with the external RADIUS server, you might want to turn on local user database authentication to eliminate the possibility that the external AAA server is causing the problem.

If local user database authentication works well, you need to analyze the log on the AAA sever. For Cisco Secure ACS troubleshooting, you need to analyze the package.cab file, which is discussed in Chapter 13, "Troubleshooting
Cisco Secure ACS on Windows."