Using a Netlet Proxy

Netlet packets are decrypted at the Gateway and sent to the destination servers. However, the Gateway needs to access all Netlet destination hosts through the firewall between the demilitarized zone (DMZ) and the intranet. This setup requires opening a large number of ports in the firewall. The Netlet proxy can be used to minimize the number of open ports in the firewall.

The Netlet proxy enhances the security between the Gateway and the intranet by extending the secure tunnel from the client, through the Gateway to the Netlet proxy that resides in the intranet. With the proxy, Netlet packets are decrypted by the proxy and then sent to the destination.

The advantages of using Netlet proxy are:

• Adds an additional layer of security.

• Minimizes the use of extra IP addresses and ports from the Gateway through an internal firewall in a significantly sized deployment environment.

• Restricts the number of open ports between the Gateway and the Portal Server to 1. This port number can be configured during installation.

• Extends the secure channel between the client and the Gateway, up to the Portal Server as shown in the "With a Netlet Proxy Configured" section of Using a Netlet Proxy. The Netlet proxy offers improved security benefits through data encryption but may increase the use of system resources. See the Sun Java System Installation Guide for information on installing the Netlet proxy.

You can perform the following tasks:

• Install the Netlet proxy on the Portal Server node or on a separate node.

• Install multiple Netlet proxies and configure them for a single Gateway using the administration console. This is useful in load balancing.

• Configure multiple instances of the Netlet proxy on a single machine.

• Point multiple instances of the Gateway to a single installation of the Netlet proxy.

• Tunnel Netlet through a web proxy.

Shows three sample implementations of the Gateway and the Portal Server with and without a Netlet proxy installed. The components include a client, two firewalls, the Gateway that resides between the two firewalls, Portal Server, and Netlet destination servers.

The first scenario shows the Gateway and Portal Server without a Netlet proxy installed. The data encryption extends only from the client to the Gateway. A port is opened in the second firewall for each Netlet connection request.

The second scenario shows the Gateway and Portal Server with a Netlet proxy installed on Portal Server. The data encryption extends from the client all the way to the Portal Server. Since all Netlet connections are routed through a Netlet proxy, only one port needs to be opened in the second firewall for Netlet requests.

The third scenario shows the Gateway and the Portal Server with a Netlet proxy installed on a separate node. Installing a Netlet proxy on a separate node reduces the load on the Portal Server node. Again, only two ports need to be opened in the second firewall. One port services requests to the Portal Server, and the other port routes Netlet requests to the Netlet proxy server.

Figure 2–1 Implementation of Netlet Proxy

Enabling a Netlet Proxy

You enable a Netlet proxy through the Gateway service using the Portal Server administration console.

Restarting a Netlet Proxy

You can configure a Netlet proxy to restart whenever the proxy is killed accidentally. You can schedule a watchdog process to monitor a Netlet proxy and restart it if it goes down.

You can also restart a Netlet proxy manually. See To Restart a Netlet Proxy for steps.

To Configure a Netlet Proxy Watchdog

You can configure the time interval at which the watchdog monitors the status of a Netlet proxy. This time interval is set to 60 seconds by default. To change this interval, add the following line to the crontab file:

0-59 * * * * netlet-install-dir/bin/checkgw /var/opt/SUNWportal/.gw 5 > /dev/null 2>&1

To start or to stop the watchdog, run the command;./psadmin sra-watchdog -u amadmin -f <password-file> -t <type> on|off.