The following problems occur on both the Linux Access Gateway and the NetWare® Access Gateway.
Section 40.1.1, The Access Gateway Hangs When the Audit Server Comes Back Online
Section 40.1.4, Rewriting Fails on a Page with Numerous HREFs
Section 40.1.6, Links Are Broken Because the Rewriter Sends the Request to the Wrong Proxy Service
Section 40.1.7, Protected Resources Referencing Non-Existent Policies
Section 40.1.8, Mismatched SSL Certificates in a Cluster of Access Gateways
Section 40.1.9, Protected Resource Configuration Changes Are Not Applied
Section 40.1.10, Recovering from a Hardware Failure on an Access Gateway Machine
For policy errors, see Section 39.0, Troubleshooting Access Manager Policies.
For XML validation errors, see Section 43.0, Troubleshooting XML Validation Errors.
When the platform agent loses its connection to the audit server, it enters caching mode. The default size of the audit cache file is unlimited. This means that if the connection is broken for long and traffic is high, the cache file can become quite large. When the connection to the audit server is re-established, the platform agent becomes very busy while it tries to upload the cached events to the audit server and still process new events. When coming out of caching mode, the platform agent appears unresponsive because it is so busy and because it holds application threads that are logging new events for a long period of time. If it holds too many threads, the whole system can appear to hang. You can minimize the effects of this scenario by configuring the following two parameters in the logevent file.
When you set a finite cache file size, it limits the number of events that must be uploaded to the audit server when caching mode is terminated and keeps the platform agent responsive to new audit events that are registered.
For more information about the logevent file and these parameters, see Logevent.
Image display problems can arise when an unprotected page references multiple protected resources. The best practices for HTML is to avoid situations where an unprotected page contains references to multiple, automatically loaded protected resources. For example, the unprotected page index.html might contain references to two GIF image files. Both GIF files are protected resources. The browser automatically attempts to load the GIF files during the initial load of index.html. Because of multiple requests happening at the same time, one or more of the GIFs might be denied access. To avoid this, you should add the page and the index.html page as a protected resource. Doing this avoids the possibility of missing GIFs.
If the hardware of your Access Gateway fails and the Access Gateway is not a member of a cluster, you might receive the following message when you reinstall it:
Start unsuccessful. Reason: Unable to read keystore : /opt/novell/devman/jcc/certs/esp/signing.keystore.
If you receive this message, use the following process to solve the problem:
Add the failed Access Gateway to a cluster.
Ignore the pending status of this command.
Reinstall the Access Gateway with a new IP address.
Add the new Access Gateway to the cluster and make it the primary cluster server.
Delete the failed Access Gateway from the cluster and from the Administration Console.
(Optional) If you want the Access Gateway to use the old IP address:
Reinstall the Access Gateway by using the old IP address.
Add it to the cluster.
Make it the primary cluster server.
Delete the Access Gateway that is using the new IP address from the cluster and from the Administration Console.
Although the rewriting failure occurs when downloading large amounts of data from a protected Web server, it is not the size or the timeout of the page that is the issue. It is the number of links to be rewritten. The Access Gateway has a data size limit to the number of references that the rewriter can rewrite on a page.
The solution is to reduce the number of HREFs on the page that need to be rewritten. If the problem is occurring because the rewriter is rewriting HTTP to HTTPS, you can solve this problem by disabling multi-homing for the Web server and by rewriting the Web page to use relative links. This reduces the number of links that need to be rewritten.
HTTP 1.1 has the ability to deal with compressed data in either a Deflate or GZIP format. This reduces the size of data being sent across the wire. Because HTML pages are just text, they typically compress very well.
To use GZIP, you enable your Web servers to send GZIP-compressed data. Be aware that some Web servers do not respond with compressed (GZIP) data when the Access Gateway sends the Via header to the Web server. Check you Web server documentation.
When the Web server sends compressed data and the rewriter needs to process the data, the data is decompressed, rewritten, and then recompressed. When Form Fill needs to process the data, the date is decompressed and then processed. If the Access Gateway does not need to perform any rewriting of the data or if Form Fill does not need to process the data, the compressed data is sent unchanged from the Web server to the browser. This is the default behavior.
If you are having problems with the recompressed data on the browser, see the following:
To determine if the compression algorithm employed by the NetWare Access Gateway has a problem, you can turn it off. With recompression turned off, pages which had problems loading might now load properly. To turn off the compression algorithm, add the following command to the load proxy line of the appstart.ncf file and then restart the system:
load proxy -gzip 0
This causes the NetWare Access Gateway to accept compressed data from the Web server and to send uncompressed data to the browser.
To return the NetWare Access Gateway to the default behavior, add the following command to the load proxy line of the appstart.ncf file and then restart the system:
load proxy -gzip 1
This command causes the NetWare Access Gateway to accept compressed data from the Web server and to send recompressed data to the browser.
To turn off the GZIP feature:
Add the following touch file
/var/novell/.noGzipSupport
Use the touch utility to create this blank file.
Restart the Linux Access Gateway.
In the presence of this touch file, Linux Access Gateway does not forward the ACCEPT-ENCODING header to the Web server. Without this header, the Web server does not send any data with GZIP or Deflate encoding to the Linux Access Gateway.
To allow the Linux Access Gateway to receive GZIP or Deflate encoded data, remove the touch file and restart the Linux Access Gateway.
When links on the Web server are rewritten to the wrong proxy service, the reverse proxy and Web servers might have the following configuration:
The initial request from the browser is to a path-based multi-homing proxy service.
The reverse proxy is configured to service one or more path-based proxy services.
The path-based proxy services are configured to and to .
The Web servers protected by these path-based proxy services have links to each other.
With this configuration, the rewriter cannot determine whether the link is to the current proxy service, one of the other path-based proxy services, or the parent proxy service. With the path removed, all the path-based proxy services have the same name. For example if one proxy service has the published name of mycompany.provo.novell.com/sales and a second path-based proxy service has a name of mycompany.provo.novell.com/app, the names are the same as the parent proxy service when the path is removed. The HTTP header does not help, because the proxy services are forwarding the same host name: mycompany.provo.novell.com.
There are a number of ways to solve this problem. One of the easiest ways is to set up DNS names for the Web servers, then configure the proxy services so that the option is set to and the DNS name of the Web server is specified in the field. This places the DNS name of the Web Server name in the HTTP Host header, allowing the rewriter to distinguish it from the other Web servers protected by the reverse proxy.
If your protected resources contain references to policies that do not exist, use the following procedures to remove them.
Click > > .
In the section, click .
This removes the link between the protected resource and the policy.
Verify that correct policies are enabled on the protected resources. Click > > > > .
Change to the .
(Optional) Click the link to modify existing assignments.
Click , then click the link.
Click > .
Sometimes a newly added server in a cluster does not receive the certificate that the rest of the cluster is using for SSL. To fix this problem:
Click > > > .
For the Server Certificate, click the icon, then select a different certificate, such as the test-connector certificate.
Click to ignore the warnings that the certificate CN does not match the reverse proxy.
This is what you want.
Click .
Click .
This needs to be the same reverse proxy that you selected in Step 1.
For the Server Certificate, click the Select Certificate icon, select the certificate whose CN matches the published DNS name of the parent proxy service, then click .
Click .
When you click OK, the correct certificate is added to the keystore.
Repeat Step 1 through Step 7 for each reverse proxy that uses a unique certificate. If all the reverse proxies use the same certificate, continue with Step 9.
On the Access Gateways page, click > .
The configuration changes are pushed to the Access Gateway, and the Access Gateway loads and uses the new certificate.
If you modify the configuration for a protected resource by modifying its , or its Authorization, Identity Injection, or Form Fill policies, you save these changes and apply them by clicking Update, then return to the resource and the changes have not been applied, the protected resource has a corrupted configuration. To repair the configuration:
Click > > .
In the list, select the resource with the problem, then click .
This repairs the configuration for the selected protected resource.
Reconfigure the protected resource with the changes that weren’t applied.
If an Access Gateway machine experiences a hardware failure, such as a failed hard disk, you can preserve its configuration and have it applied to the replacement machine. For information about this procedure, see Section 2.5, Restoring an Access Gateway.
The configuration store maintains two versions of the Access Gateway configuration and browser cache maintains one.
Current: The current configuration is the version of the configuration that the Access Gateway is currently using.
You can view this configuration in file format by clicking > > > > . Do not set a password to encrypt the file. The exported file contains the current configuration.
Working: The working configuration is the version that you have saved by clicking the button on the Server Configuration page, but you have not applied the changes by clicking the or the link on the Access Gateways page. This version is not viewable from the Administration Console.
Browser Cache: All configuration changes are saved to browser cache when you click the button on a configuration page. To view the configuration currently in browser cache, click > > , scroll to the section, then click . You can view the cached configuration of an individual Access Gateway, or if the Access Gateway is a member of a cluster, you can view the cached configuration of the cluster and each member. The + and - buttons allow you to expand and collapse individual configurations.