Compatibility with Other Features

The authentication proxy works transparently with the Cisco IOS Firewall intrusion detection system and Cisco IOS IPSec encryption features. This section looks at issues related to authentication proxy and features, such as NAT, CBAC, VPN client software, AAA, and one-time password (OTP) features.

CBAC Compatibility

Authentication proxy does not create ACEs to support returning data traffic or data channel traffic, so you must either create static ACLs to allow the return traffic or configure the CBAC inspection rules in the firewall configuration. Remember, static ACLs increase the network vulnerability because they’re permanent “holes” in the firewall, whereas a CBAC “hole” only exists as long as it’s needed.

Configuring CBAC with any authentication proxy implementation is the most reliable and secure method to ensure return traffic for authorized user connections through the firewall.

Network Address Translation (NAT) Compatibility

Authentication proxy can be successfully implemented on a network using network address translation (NAT) if the CBAC features are configured. Figure 8-4 shows a firewall router performing NAT translation on traffic heading out into the Internet.

Figure 8-4: Firewall router performing NAT translations

With the NAT service, the client local IP address is translated to a “real” global address for any packets traveling out into the Internet. This translation is stored in a NAT translation table on the router, so returning traffic can be retranslated back to the appropriate local address. For example, traffic from host 192.168.1.2 might travel out through the Internet using 172.16.1.1:2070.

But, earlier, when 192.168.1.2 used authentication proxy, a set of temporary ACEs were established using 192.168.1.2 as the authenticated address, not 172.16.1.1. Depending on where those ACEs were applied, our user might not have ACEs to allow the traffic to pass through the router.

Assuming authentication proxy is applied inbound on the LAN interface (e0) only, temporary ACEs are created inbound on that interface to allow that user the use of whatever protocols and features were defined in the downloadable profile. Because NAT will occur outbound after the traffic has passed through the LAN interface, everything should be okay so far. The NAT translations on returning traffic shouldn’t be an issue because the returning traffic is unfiltered outbound on the LAN interface. Even if the traffic was filtered, the addresses have been retranslated back to the local addresses before heading out into the LAN.

But, what if the ACEs were applied to the Serial 0 interface? Now the traffic reaching the interface doesn’t match the original dynamic ACEs created by the authentication proxy. Configuring CBAC when using authentication proxy with NAT services will take care of the problem by using the translated addresses to create matching ACEs. CBAC makes sure the NAT translated address for the session is associated with the original host address.

When in doubt, use CBAC with NAT and the authentication proxy feature.

VPN Client Compatibility

Authentication proxy can add an extra layer of security and access control for VPN client sessions. A VPN client initiating an HTTP connection through the firewall router is treated like any other user. The authentication proxy checks for a prior client authentication. If a valid authentication is found, authorized traffic is permitted. If not, the HTTP request triggers the authentication proxy and the user is prompted for a user name and password.

Once the VPN user authenticates successfully, the authentication proxy retrieves the user profile from the AAA server. The source address in the user profile entries is then replaced with the IP address of the authenticated VPN client from the decrypted packet.

Compatibility with AAA Accounting Features

Authentication proxy supports the AAA Accounting feature by being able to generate “start” and “stop” accounting records with enough detail to be used successfully for billing and security auditing purposes. This also allows the network administrator to monitor the actions hosts that have used the authentication proxy service.

If the accounting Start option has been enabled, a start record will be generated every time an authentication proxy cache entry and associated dynamic access control list entry are created. Any subsequent traffic from the authenticated host will be recorded when the ACEs created by the authentication proxy receive the packets. The accounting feature saves data about this event in a data structure stored with the data of other users on a defined server.

When the authentication proxy cache expires and is deleted along with the related ACEs, any additional data, such as elapsed time, is added to the accounting information and a stop record is sent to the server.

Operation with One-Time Passwords (OTS)

Authentication proxy supports the use of one-time passwords (OTPs) because AAA supports them. Remember, OTPs typically require an additional authentication server and will require additional configuration of the AAA server. When using an OTP, the user enters the user name and OTP in the HTML login page as usual.

One minor difference is this: the user must enter the correct token password within the first three attempts. If a user has made three consecutive incorrect entries, they must enter two valid token passwords in succession before authentication is granted by the AAA server.