The following sections contain some problem situations that you may run into and suggestions on how to resolve them. You should also see Chapter 9 for more troubleshooting hints. The troubleshooting headings are numbered for easy reference.
When trying to log in as a specific user, the following error might appear:
This Gateway Does Not Support X
The X represents an authentication scheme (SecurID, RADIUS, and so on). This error message occurs for one of two reasons:
Your gateway object is not defined with this authentication scheme enabled.
If an LDAP user is trying to authenticate, the LDAP account unit does not have this authentication scheme configured as supported. Correct this problem, reinstall the security policy, and try again.
If you are using Session Authentication with a protocol that opens lots of connections (like HTTP), you will see this error in your logs. In these cases, it is advisable to use Client Authentication with fully automatic authentication instead of using Session Authentication by itself.
This message occurs in one of two situations:
The appropriate Security Server is not enabled in $FWDIR/conf/fwauthd.conf.
There is more than one object with the firewall's IP address.
Fix these situations, reload the policy, restart FireWall-1, and try again.
This message means that communication between the firewall and the Session Authentication agent is cleartext. The same thing goes for User Authentication for Telnet, FTP, HTTP, and rlogin and Client Authentication?the password is not encrypted. If you are concerned with passwords being sniffed over the wire, use an OTP scheme like S/Key or SecurID. This way, even if the password is captured over the wire, it will not be useful.
You can also enable encrypted Session Authentication. In fact, you can force it by enabling the "Accept only if connection is encrypted" option in the Session Authentication Action Properties screen (see Figure 8.35 earlier in the chapter).
FireWall-1 does not support this because User Authentication can be used for any service for which Content Security is available.
If FireWall-1 is used for User Authentication and the firewall is not set as the proxy in the client browser, you will be asked to authenticate at each new Web site to access because the Web browser will not use the previous authentication information entered as each new site is accessed. In these situations, you should use Client Authentication with partially automatic authentication or use Session Authentication.
This error appears when a user attempts to authenticate and there is no Client Authentication rule that matches. The source IP address, user's group, and the user's allowed sources must match the rule. The user should not have a "blank" in the allowed source or destination section.
A policy install flushes certain tables, of which the client_auth table is one. Although this is not generally recommended for security reasons, you can open $FWDIR/lib/table.def on the management console and modify the following entry:
client_auth = dynamic sync expires AUTH_TIMEOUT kbuf 3 \ expcall KFUNC_CLIENT_AUTH_EXPIRE;
keep needs to be added to this line after sync. It should read:
client_auth = dynamic sync keep expires AUTH_TIMEOUT kbuf 3 \ expcall KFUNC_CLIENT_AUTH_EXPIRE;
The keep prevents the client_auth table from being flushed on a policy install. You must reinstall the security policy in order for this change to take effect. The only way to flush this table is to bounce FireWall-1 (cprestart).
The HTTP Security Server needs to be instructed to use the HTTP host header instead of the IP address. To do that, perform the following commands in dbedit or make the appropriate change in the GUIdbedit tool:
dbedit> modify properties firewall_properties http_use_host_h_as_dst true dbedit> update properties firewall_properties
See FAQ 4.2 in Chapter 4 for instructions on how to modify objects_5_0.C.
The likely reason for this problem is that one of the rules is less restrictive than the User Authentication rule actually matched. Long logging on all rules should allow you to discover which rule is the cause. Make this rule less restrictive, and/or reorder the rules to resolve this problem.
This message is a result of trying to filter traffic going to a proxy server. You need to set the HTTP Next Proxy server and port as described in FAQ 8.6. You can go to only one proxy server per firewall because it is impossible to set more than one server in the Use Next Proxy setting.
Sometimes while trying to Telnet to the firewall with User Authentication, you get the Check Point Telnet banner, you authenticate successfully, but then you lose the connection. If you are attempting to allow users to Telnet to the firewall for the purpose of proxy authentication, make sure prompt_for_destination is set to true in objects_5_0.C. If you want to allow people to Telnet to the firewall to log on to the firewall itself, you need to make sure that the Telnet daemon is running on the firewall box. Check /etc/inetd.conf to see if the Telnet daemon was commented out by FireWall-1 upon installation. If it was, uncomment it, and send the inetd process a hangup (HUP) signal.
It is not recommended that you allow users to Telnet to your firewall directly. For enhanced security, use an encrypted login mechanism like SSH.
Check Point's HTTP Security Server disallows some HTTP behaviors. As a result, some sites do not function when accessed through the HTTP Security Server. FAQ 9.9 gives some suggested settings for objects_5_0.C to eliminate these errors.
In this situation, SecurID authentication is set up, but after one successful authentication attempt, all future attempts fails. You might see the error message "[LOG_ERR] ACEAGENT: The message entry does not exist for message ID: 100x" when this occurs.
The ACE agent inside of FireWall-1 embeds a hash of its IP address in the authentication request packet before passing it to the ACE/Server. The ACE/Server will run a hash on the expected source IP of the ACE agent and compare it to the received hash. The ACE/Server uses the defined primary host agent IP to derive this hash. If the two hashes do not match, the authentication request is denied.
This method is problematic when an ACE agent is multihomed. The ACE agent may derive a hash from one of its other IP addresses. When this behavior occurs, it is necessary to create an sdopts.rec file in the /var/ace directory. The sdopts.rec file forces the ACE agent to use a specific IP address to derive its hash. Follow these steps.
Create the sdopts.rec file in the /var/ace directory.
Using vi, edit the sdopts.rec file and insert the following line:
Restart FireWall-1 using cprestart.