This section works through some frequently asked questions and answers.
1 | Can I implement cut-through proxy authentication behind a PAT device? |
Answer: | After successful user authentication, authentication information is cached on the PIX firewall based on the source IP address. Hence, so long as the authentication information does not timeout, the subsequent authentication will not be prompted for the username/password. If all devices are behind a PAT device, the source IP address for all devices will be the same, but source ports will be different. As the cut-through proxy cache is based on source IP address, not the source port, if one of the devices authenticates, the rest of the devices will not be authenticated, as the source IPs for all devices are the same. To work around this problem, you may set the uauth absolute timeout to zero, which effectively will disable the caching of user credentials. Therefore, users will be prompted for authentication even if they are using the same source IP address. However, disabling the uauth cache can create a problem for users browsing the web. If the traffic to be authenticated is only by Telnet and FTP, setting the uauth timeout to zero solves the problem, and all users can be authenticated for each connection, including those users sharing the same source IP. |
2 | When configuring http console authentication on the PIX to go to TACACS+ or RADIUS, is there a way to keep it from sending more than one authentication request when a user logs into PDM(PIX Device Manager)/ASDM (ASA Device Manager)? Sending more than one authentication request causes user authentication problems with a One Time Password database such as SDI. |
Answer: | PIX firewall does not support one-time passwords for http console authentication. Each HTTP connection to the PIX is authenticated with the AAA server. When PDM starts up, it makes multiple connections to the PIX to get the configuration and other information. |
3 | Can the same address be used for both virtual Telnet and HTTP server? |
Answer: | No, you cannot use the same address for both virtual Telnet and virtual HTTP. |
4 | Should I Telnet directly to the virtual Telnet server IP and get authenticated, or should I Telnet to something beyond PIX, so that PIX will redirect to the virtual Telnet IP address? |
Answer: | With virtual Telnet, you should always Telnet to the virtual Telnet IP. That is the only way it works. Redirection is not involved with virtual Telnet. You redirect only with virtual HTTP. |
5 | Do next pin and new pin modes work only with Telnet on a PIX firewall? |
Answer: | No. They also work with virtual HTTP. But, you need to be sure to configure virtual Telnet in addition to virtual HTTP. |
| |
6 | What is the configuration recommendation for the HTTP next token? |
Answer: | Following are some configuration recommendations for http next token: - Do not configure both virtual HTTP and virtual Telnet at the same time. Configure and test each one separately. First enable virtual HTTP and test basic authentication using a browser (not next token mode). If virtual HTTP is working, configure and test virtual Telnet using a Telnet clientclear uauththen simply Telnet to the virtual address and authenticate. Once they are both working, then test next token / new pin using a browser. - Choose a unique address for each virtual server. Each address should be routable from the clients to the PIX and should not be in use by any devices on the network. Do not choose the same address for virtual HTTP and virtual Telnet; two separate addresses are required. |
7 | When was the fallback method to use the LOCAL user database introduced? |
Answer: | The fallback method to use the LOCAL database in case the AAA server is unavailable was introduced in PIX Firewall Version 6.3.4. |
8 | Is accounting supported for GRE traffic? |
Answer: | Yes, from Version 6.3.4 GRE accounting is supported. |
9 | Is cut-thru proxy supported based on source port? Or is it based on source IP only? |
Answer: | It is based on source IP only. |
10 | Can I customize the prompt to show to users for Cut-Through Proxy Authentication? Can I also provide feedback on the successful or failed authentication? |
| |
Answer: | You can customize the prompt the user sees when trying to make connections across the PIX Firewall. Customizations of prompt options are as follows: You can change the prompt that the user first sees with cut-through proxy by using the auth-prompt command as follows: auth-prompt prompt PIX515B With this command, users going through the PIX see the prompt PIX515B. If you want to provide feedback on a successful or failed authentication, you can use the following commands: auth-prompt accept "GOOD_AUTHENTICATION" auth-prompt reject "BAD_AUTHENTICATION" Then users see the messages shown in Example 10-36 concerning authentication status on a failed/successful login. Example 10-36. Message That Appears to Client with Successful/Failure of User Authentication PIX515B Username: junk Password: "BAD_AUTHENTICATION" PIX515B Username: cse Password: "GOOD_AUTHENTICATION" | |
11 | Can I configure Per-User Idle and Absolute Timeouts for Cut-through Proxy Authentication? |
Answer: | The PIX timeout uauth command controls how often re-authentication is required. If TACACS+ authentication/authorization is on, this is controlled on a peruser basis. |
To configure timeout and idle timeout on the ACS Server using TACACS+, follow these steps:
You must have the authorization turned on for timeout and idle timeout to work properly.