A Forum reader asked this question:
“I’m working with a school district that is installing some Linux-based (SUSE) computers in the labs. They currently have BorderManager 3.8, are using CLNTRUST.exe in Windows launched via a login script. This is so users of that lab can access the Internet from those
We downloaded CLNTRUST.tar for Linux, installed it, and configured the login script to launch clntrust locally. It does start, but the results window remains open. We can’t close it until we a) press Ctrl-C to stop the script which ends clntrust, or b) exit clntrust from the panel bar.
We also do not see that clntrust is actually allowing Internet access without logging into the Bordermanager at the web interface.
How can we get the results window to close and have clntrust remain open? Is there any good source for documentation on clntrust for Linux?”
And here’s the reply from BorderManager expert Craig Johnson …
The way it is supposed to work is that when your browser requests a URL from the proxy, the proxy needs to associate the browser IP address to an NDS name (when authentication is enabled). There are two methods for doing this: CLNTRUST (known as single-signon
or SSO), and SSL (the login box in the browser).
The server first waits for a configurable time to get a response back from CLNTRUST, and if needed, then switches to SSL login prompt.
When CLNTRUST is to be used, the proxy sends a request on UDP port 3024 to the browser’s IP address, and it awaits a responds from Client32 via CLNTRUST. Thus you have at least these requirements, which may help in troubleshooting your issue:
1. CLNTRUST must be running.
2. Client32 (or the Novell Linux Client) must be running.
3. The user must be logged into the same NDS tree as the BorderManager server.
4. The browsing host must be able to see the UDP 3024 requests coming to it – this means you cannot block that port with a local firewall, and you can’t have dynamic NAT shielding the requesting host from the BorderManager server.
5. Finally, sometimes the clients try to contact the BorderManager server on the public IP address, but they are filtered. It may help to open TCP port 524 to the public IP from the private side, or at least test with the filters down. This may be the reason some sites need to set a very long timeout for CLNTRUST before SSL kicks in. (The default is a 3-second wait, and I usually up that to 5 seconds. Some people up it to 30 seconds, which seems excessive to me).
Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.