Novell is now a part of Micro Focus

What's New in Support Pack 2 for BorderManager 3.5?

Articles and Tips: article

15 Nov 2000


Examines the new features that you can find in Support Pack 2 for BorderManager 3.5.

Novell recently released Support Pack 2 for BorderManager 3.5. The information you are reading about is found in TID #2957760. You can find this Technical Information Document on the Novell Support Connection Web site. Go to the Knowledge Base page at http://support.novell.com/search/kb_index.htm and type "2957760" in the "Enter a word, phrase, or Technical Information Document number" entry box, and click on Search Now. Then select the BorderManager 3.5 Support Pack 2 entry from the search results.

The Support Pack 2 Readme file contains updates for all services that are contained in the BorderManager 3.5 product, thereby providing updates and fixes that have been tested together. Support Pack 2 includes all fixes from previous support packs; therefore, you do not need to install earlier support packs before installing this support pack. It is not recommended to install individual files from the Support Pack.

New Product Features Found in Support Pack 2

Here is a brief overview of the new product features added to BorderManager in Support Pack 2.

CVP Support. BorderManager 3.5 Support Pack 2 supports virus scanning for both inbound and outbound e-mail messages by using a Symantec CVP server. All e-mail messages that are configured to go through our SMTP proxy can be examined for virus presence and removal by enabling CVP support in the proxy.

CVP support is built into CVPREDIR.NLM (the CVP redirector). When this NLM is loaded, it registers with the proxy to receive mail messages that need to be filtered for viruses. When the proxy receives mail to be sent out and if the CVP redirector has already registered with it, the proxy reroutes the mail to the CVP redirector for virus scanning. The CVP redirector in turn uses the CVP protocol to send the data to a configured Symantec CVP server.

If the Symantec CVP server detects a virus, it cleans it or sends an error code to the proxy. In addition, the Symantec server also sends an error mail message to the person that has been designated as the admin for the Symantec CVP server. On receiving an error about a virus that can't be cleaned, the proxy deletes the file and logs the occurrence in the log file.

You can configure multiple Symantec CVP servers so the CVP redirector can distribute the virus-scanning load across those CVP servers. The CVP redirector configuration is stored in the SYS:\ETC\CVPREDIR.CFG file. To specify a CVP server, use the keyword SERVER followed by the IP address of the server or the DNS name of the server. You can specify a maximum of 5 CVP servers.

Here is a sample CVPREDIR.CFG file:

[CVPSERVER]## Each line has the keyword SERVER followed by# the DNS name or IP address of the CVP server# and optionally the CVP port number (default port# is 18181)##SERVER 130.57.65.36 = d-065036.sjf.novell.com#SERVER 130.57.65.7 = d-065007.sjf.novell.comSERVER 130.57.65.36SERVER 130.57.65.7

CVPREDIR.NLM will not load under the following conditions:

  • If the proxy is not loaded.

  • If the domain names specified for the CVP servers in the CVPREDIR.CFG file cannot be resolved.

The CVPREDIR can be unloaded at any time. The proxy will then stop routing mail to the CVP redirector. If the proxy is unloaded, the CVPREDIR will also automatically unload.

Proxy Chaining. BorderManager 3.5 can sit behind another proxy server that requires authentication. BorderManager will cache all objects returned for requests containing authorization headers. For subsequent requests to the same cached object, the BorderManager proxy will request authorization from the upstream proxy and if it is authorized, it will send the object from its own cache. This will ensure that BorderManager will cache objects, and will also dispense them to only authorized users.

If the upstream proxy requires authentication, the site download feature also requires a user name and password to authorize BorderManager to the upstream proxy. This allows site download requests issued by the BorderManager to pass through the upstream proxy. This user name and password must be included in the SYS:\ETC\PROXY\PROXY.CFG file. Here is an example of a user name and password specification:

[Proxy-Authorization]User Name=testPassword=test1ProxyReauthorization=1;

Add the above three lines to the existing heading found in the SYS:\ETC\PROXY\PROXY.CFG file. If the ProxyReauthorization parameter is set to 1, each request is reauthorized from the upstream proxy. If multiple requests are waiting for the same object, each request will be authorized individually and so there is enhanced security at the cost of performance.

If the ProxyReauthorization parameter is set to 0, objects cached in the BorderManager cache can be accessed without reauthorization from the upstream proxy. However, this will not bypass any reauthorization requirements that need to obtain authorized data from the original servers. This enhances the performance of the BorderManager cache and speeds up the access to local users of BorderManager.

When you install BorderManager, you will lose all the currently cached objects because once BorderManager is installed, all objects require tagging to check for authorized access and the currently untagged cache objects are deleted. However, the cache will soon be replenished with the tagged objects.

Cookie-Based Authentication. BorderManager 3.5 Support Pack 2 includes a feature called cookie-based authentication, which you use in conjunction with BorderManager acceleration (also referred to as reverse proxy). This feature enables BorderManager to associate a unique cookie with each user so that requests can be tracked. The following steps describe how this process works.

  1. A user makes a GET HTTP request via the browser to the BorderManager reverse proxy.

  2. BorderManager authenticates the user by using the SSL authentication method. If the authentication is successful, it generates a cookie, stores it in its internal authentication table, and also issues a set cookie command to the browser. This causes the browser to send the cookie in the HTTP header for all subsequent requests.

  3. BorderManager now expects a cookie in every request from an authenticated user. BorderManager extracts the cookie from the received request, and checks to see if there is an authentication entry against the cookie. If it finds an authentication entry, the user is considered to be authenticated and the request is processed normally. If the cookie header is missing, BorderManager goes through the entire authentication process again, and creates a new cookie.

BorderManager sets "session cookies" on the browsers. These cookies don't live beyond the particular session of the browser. If the user exits the browser and reloads it again, he or she will need to reauthenticate to the proxy in order to access the Web site again.

Previously, the only user identity information that was present in an HTTP request was the source IP address. With this cookie-based authentication method, each user can have a unique session identity that is established each time he or she logs in. Even if many users share the same IP address--such as when going through a Network Address Translation (NAT) box or a UNIX box--the cookie identifies each user uniquely.

The following conditions must be met for cookie-based authentication to work properly:

  • If a single proxy server is accelerating multiple Web sites, the user will need to authenticate to each Web site that the proxy accelerates because the cookie is set against the domain name that the user is trying to access.

  • You should set the Accelerator Name as the real DNS name of the Web site that is being accelerated, then access the Web site using that name instead of the public IP address of the proxy.

  • Because of the inherent limitations of the applet, the cookie-based authentication does not work when the applet is sent to get the user and password information. Use the form method instead.

  • Cookie-based authentication is enabled by default and cannot be turned off.

  • Browsers must be enabled to accept cookies.

Enabling the New Product Features in Support Pack 2

To enable the new product features listed above, complete the following steps:

  1. If there is an upstream proxy, configure the BorderManager cache client to point to the upstream proxy. If that upstream proxy requires authorization, create a user identity for BorderManager itself and add its user name and password to the SYS:\ETC\PROXY\PROXY.CFG as indicated earlier.

  2. Restart the server running BorderManager 3.5 with Support Pack 2.

  3. Verify in the proxy status screen that the cache hit percentage rate keeps going up whenever you access the same site.

  4. If virus scanning of e-mail is required, list one or more Symantec CVP servers that you want to use for virus scanning in the SYS:\ETC\CVPREDIR.CFG file. Follow the example shown earlier. Then load CVPREDIR.NLM after the proxy is loaded.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates