In feisty the script of madscientist worked ok. Now I have a eee-pc with debian lenny (with lxde) and an user with the sudo power. Iceweseal, sunjava6, ... I think that I follow the how-to to perfectly as before, however I do not able to dowload the .juniper_network folder. I have tarred my .juniper folder from feisty and put in the debian system and when run junipernc.sh (the first time ask me the sudo password, I fill the fields with my user, host...password, a new .vpn.crt is generated, the file .vpn.cfg is correct according to the new location and then appears this message:
Searching for ncsvc in current working directory
Searching for ncsvc in /home/ejjp/.juniper_networks/network_connect done.
ncsvc> Failed to setuid to root. Error 1: Operation not permitted
java: ncui.cpp:262: void NCUI::run(): Assertion `m_conn->isConnected()' failed.
/usr/bin/junipernc.sh: line 265: 3064 Abortado "$java" -jar "$_ncpath/NC.jar" -h "$HOST" -u "$USER" -p "$password" -f "$CERT" -r "$REALM"
Also, when I have logged in the vpn juniper web page and push the start button, the terminal NCinstall.sh does not appear as in feisty. Any idea?
I was able to get the applet to run after I switched to 32bit Java using Madscientist's script however I am getting the "Invalid Credentials" error. I am assuming this is an issue with the VPN Service Realm that was specified. I just used the default in the Junipernc script. I asked my IT department what the VPN Service Realm was and they had not heard that name so I searched the source of my login page and again (as suggested on this thread), no luck. What is the VPN Service Realm? Are there typical values that I can try or would it be specific to each institution/company? Where else might I be able to find it?
Thanks everyone for all the helpful work thus far!
Hi all. Sorry I've been out of touch: work was (still is) crazed. Unfortunately I'm still using my old system which is a 32bit system, running Ubuntu 8.04 (old nvidia card so I can't upgrade ATM), so I don't have a lot of advice for folks trying to work out problems with newer systems.
cpepera; I'm not sure exactly what you looked for when you searched the source of the login page. You should look for an "input" field something like this: <input type="hidden" name="realm" value="RSA"> The string after the value is the one you want.
Did you not find anything like this in the page source?
Also, what version of NC are you using? I think there are newer versions than the one I'm using, which appear to have changed.
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Madscientist, I could not find any line in the login page like you described. I login to get to a web interface from which I can select from a variety of different VPN access modes one of which is NC -- not sure if this is different than most users. I checked the source at the access mode web interface and also at the page displayed when NC is being launched but I could not find any indication of the realm.
Interestingly I can launch the applet no problem on my desktop at work (Ubuntu 8.10) through the web interface. All I had to do was create a root password. The rpm line in my xlaunchNC script is commented out (by default, not by me).
But, of course I don't need to use NC at workCode:# check if modprobe can locate the tun module. #Adding dry run option we dont want to insmod, just check if tun is available rm -rf $1/missing.rpt /sbin/modprobe -n tun 1> $1/missing.info if [ "$?" -ne "0" ] then echo "Modprobe for Tun driver failed." > $1/missing.rpt # rpm -q tun 1> $1/missing.rpt fi
edit: I should say that I run 8.10 32bit at work and 9.4 64bit at home.
Last edited by cpepera; July 20th, 2009 at 10:01 PM. Reason: add more information
Ok, I was able to use Network Connect via madscientist's script (thanks!) after I figured out the realm. I can login specifying a number of realms so it wasn't explicit in the login page source. I also had to switch to 32bit java but now NC is running on 64bit 9.04. Still need to work out some some firewall issues. I lost my internet connection and couldn't ping the nameservers on my work's network if I didn't disable firestarter, but I'll need to learn some more about networking first.
Thanks again. This thread is great, what a relief!
First, I want to thank madscientist, who has shown great patience throughout the many pages of this topic (all of which I've at least skimmed ).
I want to add to the list of symptoms and remedies that there seems to be a conflict caused by Firefox 3.5 on Ubuntu 9.04/Jaunty Jackalope. Specifically, changing the Privacy setting to anything other than the default "Remember history" prevents Network Connect from loading. It throws the following Java error.
It took me a very long time to figure this one out. Why would disabling third-party cookies create what looks like a Java path issue? It wasn't until post #255, where kloper suggested Opera (which worked), that I began to investigate Firefox itself.Code:load: class SecureNCLauncher.class not found. java.lang.ClassNotFoundException: SecureNCLauncher.class at sun.plugin2.applet.Applet2ClassLoader.findClass(Applet2ClassLoader.java:151) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Plugin2ClassLoader.java:429) at sun.plugin2.applet.Plugin2Manager.createApplet(Plugin2Manager.java:2866) at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Plugin2Manager.java:1395) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.IOException: open HTTP connection failed:https://vpn-ssl.bloodstockwww.com/dana-cached/nc/SecureNCLauncher/class.class at sun.plugin2.applet.Applet2ClassLoader.getBytes(Applet2ClassLoader.java:459) at sun.plugin2.applet.Applet2ClassLoader.access$000(Applet2ClassLoader.java:46) at sun.plugin2.applet.Applet2ClassLoader$1.run(Applet2ClassLoader.java:126) at java.security.AccessController.doPrivileged(Native Method) at sun.plugin2.applet.Applet2ClassLoader.findClass(Applet2ClassLoader.java:123) ... 6 more Exception: java.lang.ClassNotFoundException: SecureNCLauncher.class
I had already tried reverting to Firefox 3, but used the same FF3.5-upgraded profile (specifically, prefs.js). I did discover that the break isn't permanent: setting the Privacy back to the default will restore NC access. I also don't see this on Windows XP, FWIW.
I thought I'd add some notes I gathered while playing around with the NC client in Linux.
To use the network connect client on Linux without having to install or use Java (which is a silly requirement, if you ask me), you need the ncsvc binary and the IVE's public certificate in DER format:
- Install network connect either by executing it in the IVE interface with a browser, or fetch the RPM from the IVE admin interface (Maintentance -> System -> Installers -> Network Connect for Linux.
- RPM: Extract the RPM (don't install it unless you really want to) to get the ncsvc binary.
- Web: The ncsvc binary is found in ~/.juniper_networks/network_connect/
To set up the certificate file, the client executes the ncLinuxApp.jar/getx509certificate.sh script, which does some pretty silly things to fetch the certificate from the IVE server. A more concise way of getting the certificate would be:
The binary can now be executed. It is setuid root (another somewhat silly solution), so a normal user can run it directly without sudo or any passwords.Code:echo | \ openssl s_client -connect ive.example.com:443 2>&1 | \ sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | \ openssl x509 -outform der -out ive.crt
The full list of ncsvc parameters is below. Different versions of the binary report different usage/args, and there are some differences in Juniper's documentation. These are the currently supported parameters for the 6.3 version (found in the binary -- several of them are not shown in the command help/usage):
The ncsvc binary logs to ~/.juniper_networks/network_connect/. To change this, the binary can be edited to use /opt/jnc/ or /var/log/.Code:-h|--host <arg> - Hostname of IVE -u|--username <arg> - Username -p|--password <arg> - Password -r|--realm <arg> - Realm -f|--certificate <arg> - Certificate in DER format -m|--md5hash <arg> - Hash of what? Not used? -P|--Port <arg> - IVE service port. Not generally used? -L|--log-level <arg> - Log level -v|--version - Print version info -x|--??? - unknown. In the code, but not documented. -K|--Kill - Kill ncsvc -y|--proxy <arg> - Proxy address -z|--proxy-port <arg> - Proxy port -s|--proxy-user <arg> - Proxy username -a|--proxy-pass <arg> - Proxy password -d|--proxy-domain <arg> - Proxy domain -g|--upload-log - Upload client logs
It would be great to have the Network Connect client work with Ubuntu/Gnome's NetworkManager. It should be fairly simple to modify the vpnc plugin for NetworkManager to work with ncsvc. This would be a major advantage over the Java GUI.
Another option would be to reverse engineer the communication used by ncsvc. It shouldn't be too difficult to do. On Windows, the SSL communication can be intercepted using KAPIMON's ssclear.cmd plugin. (Pretty much the only other alternative, HTTP Analyzer, doesn't work since it cannot open hidden processes.)
After authenticating and negotiating the tunnel parameters over HTTPS, an IPSec ESP tunnel is set up. By default it falls back to use NCP if the ESP packets time out. The NC protocol is most likely ESP/IPSec encapsulated in HTTPS.
A few things I haven't figured out:
- Can the NC client use other factors than username+password for auth? For example a client certificate or SecurID/PIN. When I try it, the ncsvc binary exits due to an unexpected authentication step (the SecurID/PIN prompt). I haven't tried to use a client certificate, and don't really know how to try it either.
- The NC client is rather brutal with /etc/resolv.conf. It doesn't seem to support resolvconf for proper management, so split tunneling can suffer.
- Getting connection statistics from the ncsvc daemon seems to require some form of authentication. The GUI app does this, but it should be possible to do from the command line as well if the right protocol is used.
Lastly, I tried getting a root shell on the IVE by trying various tricks at the LILO 22 boot prompt (using a serial console). No matter what I tried (init=/bin/sh, various kernel parameters, other kernel images), it booted as normal.
Do any of you have access to an out-of-warranty Juniper SA of any model? It would be really interesting to remove the disk and put it into another computer to see what it contains. That should also reveal the encryption key used for the upgrade images.