If you change any of the parameters on this page, before you leave the page, you must click Enter to save your changes. After you have made all the changes in your editing session, you must stop and restart the web server for the changes to take effect. See the procedure "To Stop and Restart the Web Server on the i-Planet Server" in Chapter 3, Other Administrative Tasks.
This is the client program that works together with the reverse proxy server on the i-Planet gateway to allow secure access from the Internet to TCP/IP application on your intranet. You can specify which predefined application rules will be enabled as well create rules for your own TCP/IP applications that you want to access through the Netlet.
Clicking the Netlet link displays the Netlet Administration page, shown in Figure 2-11.
The predefined Netlet rules work in conjunction with NetFile. For them to be active, you must enable them on this page and on the NetFile Configuration page.
The Netlet Administration page shows the predefined applications and provides a the place and the means for writing user-defined Netlet rules (up to a limit of 30).
The predefined function and rules are:
Port Warning--Enables or disables support for a warning window that displays from the NetFile page of the i-Planet Desktop application when a connection to a Netlet port is being attempted. The Netlet Connection Attempt window also shows the number of the port. The end user can then decide to:
Click OK to continue
Cancel to stop the connection
Choose not to see this warning again, which disables the port warning for the current session only.
Predefined Netlet Rules--Enables or disables support for the applications listed.
The destination system is given at runtime through the NetFile application. You must also enable the Netlet functions on the NetFile Configuration page. The defined applications are:
Telnet--allows end users to use Telnet to have access to systems on the intranet. Addresses for Telnet are established dynamically, if you are using NetFile. The Telnet client is the one that is configured in the client browser.
GO-Joe (remote X-Windows)--allows end users to use GO-Joe for remote X-Window control for the Solaris operating environment. GO-Joe is a thin client X server that uses a three-star, distributed client-server architecture (X server, X client, and display applet). The GO-Joe server must be installed on the destination machine. Information on the requirements for installing GO-Joe is in the section "GO-Joe " in Appendix C, Third-Party Software.
NT-Applications (Citrix)--allows end users to use Citrix-based applications over the Internet. Citrix reserves port 1494. Citrix has Java and non-Java clients that support TCP/IP. i-Planet is customized to start the Citrix client (Java applet) and a Citrix-based proxy when you configure it appropriately.
If your end users will be connecting to any a Microsoft Windows-based machine using NetFile, you must first install the Samba software that is on the i-Planet CD-ROM, "Contains 3rd Party Software Packages Only," on the i-Planet server.
pcANYWHERE (a Windows 95, 98, and NT remote-control product)--Allows users to have remote PC Microsoft Windows control. Information on installing and configuring pcANYWHERE is in the section "pcANYWHERE" in Appendix C, Third-Party Software. The pcANYWHERE client (Java applet) software is installed with i-Planet. A demonstration copy of the pcANYWHERE server software is on the i-Planet CD-ROM, "Contains 3rd Party Software Packages Only." If you enable this option, you must buy a copy of the server software and install it on the computer that your end users want to control remotely.
The i-Planet product also supports the software CarbonCopy, LapLink, RapidRemote, ReachOut, RemotelyPossible (all Microsoft Windows 95, 98, and NT remote-control products). If you want to use them, you must buy these products separately.
Table 2-5 shows the ports that are reserved for the predefined Netlet rules. Do not use these reserved ports in writing your own Netlet rules.
Table 2-5 Reserved Listen Ports for Predefined Netlet rules
loopback is required because of the Java security model. Applets are only allowed to make connections back to the server from which they were loaded. In order to make the included client applets work with the Netlet, they must appear to be downloaded from server localhost. This is accomplished by telling the Netlet to fetch the desired applet. Traffic requests on the loopback port are requests to the Netlet to go back to the i-Planet server and download the object whose path is given in the URL.
User-Defined Netlet rules--You define the user-defined Netlet rules in the lower half of the Netlet Administration page, shown in Figure 2-11. The end user cannot dynamically specify a destination server at run time. The destination server is fixed. You must define the whole path for them.
You are limited to 30 user-defined rules.
The syntax for defining these applications is: name^client-listen-port^destination-host^destination port, in which:
The symbol "^" is the field separator in this syntax.
name--some identifier for this entry. It is only used to track the application.
client-listen--the port for which the Netlet listens on the end user's client machine.There can be only one entry or rule for each client-listen port
destination-host--the name or IP address of the destination host to which traffic will be directed.
destination-port--the port on the destination host to which all traffic will be directed.
You cannot assign a port number greater than 64000 when you are defining your own Netlet rules.
For example, the following procedure shows how to write a Netlet rule that will allow telnet traffic to a specific system.
Write a Netlet rule for special handling of Telnet in one of the fields for writing user-defined Netlet rules, as follows:
telnetspecial^23^machine-on-the intranet^23 |
Click the Enter button at the bottom of the page to save this Netlet rule.
This Netlet allows Telnet traffic from any remote machine and directs it to machine-on-the-intranet. Any normal Telnet traffic on port 23 (the destination Telnet port) to the machine on which the netlet is running will be redirected to machine-on-the-intranet. You can specify different names or port numbers, depending on your requirements. You must not have any other handler for port 23 for this to work (that is, no Telnet service/daemon specified).
As root on the i-Planet server, stop and restart the web server so that the Netlet rule you just defined will take effect.
See the procedure "To Stop and Restart the Web Server on the i-Planet Server" in Chapter 3, Other Administrative Tasks.
If you monitor incoming or outgoing traffic through your firewall, you will see that all Netlet traffic on the outside actually passes on your SSL port (likely 443). The TCP protocols used by the Netlet rules are tunnelled through your SSL port.