I had recently to support remotely a customer using a Juniper/Netscreen SSL gateway as a vpn solution. Normally you point your browser to a https:// website , sign in and then a java applet should start and modify your routing table automatically passing all the traffic through a tun device in ssl mode ..

I was surprised that the Juniper Network Connect applet detected my OS as being Linux (i feared that a M\$ machine was needed to connect ...) and it launched a xterm box asking my root password to setup the Network Connect client. It installed the java jar archives in a \~/.juniper_networks/network_connect folder but nothing happened after that ... I should receive a pop-up window starting the connection itself but nothing.

After analyzing the .sh scripts inside of the /.juniper_networks/network_connect/ folder and searching with strace, java -jar NC.jar , i saw a executable file : ncdiag. okay, surely a missing lib : ldd ./ncdiag pointed me directly to the missing libstdc++-libc6.2-2.so.3 .. so really easy to troubleshoot with `yum provides` .. (why do still a lot of packages rely on older libraries ? ...)

Then the java applet opened .. but i received a nice 'Unable to load library libncui.so' window .. ok, one step further, when launching java -jar NC.jar in a terminal, i was pointed to something useful : 'DSSSL_load_so failed'

Hmm, DSSSL ? sounds like openssl right ? but it was installed ... i had something similar recently when a package relied on the -devel package and not on the normal one ... so i tried just to symlink /lib/libssl.so.6 to /lib/libssl.so (instead of installing the openssl-devel package) and NC was now happy .. Silly isn't it ? Unfortunately i've no means to modify their broken NC client .. but at least there is now a workaround, and that's the only reason why i blog it here .. so that other users don't have to search again .. myself included ;-)