It’s a simple Java GUI app for testing out one’s REST services. You can choose your: URL, HTTP method, add any custom headers, add a body for PUT/POST, set auth info, SSL info, and do simple scripting.
This is an incredibly useful tool, AND a far cry better than doing it all on the command line with curl.
There’s one standard document on HOWTO get Network Connect working on Ubuntu Linux. It’s mad scientist’s doc: http://mad-scientist.us/juniper.html . However, there are a few things not covered. I’ll assume that you’ve followed mad scientist’s excellent guide before going any further.
Issue #1: 64-bit Ubuntu
By default, when you install java on your 64-bit system, you get a 64-bit java. No surprise there, right? Well, Juniper’s tools don’t play nice with 64-bit java. If you attempt to start the junipernc script you’ll promptly see the “VPN has failed!” error message.
Also if you look closely in your Terminal you’ll see the text error:
Failed to load the ncui library.
This is the clue that we are dealing with the 64-bit issue.
The work around for this is to install a 32-bit java on your system. Type the following into your Terminal:
sudo apt-get install ia32-sun-java6-bin
After typing your password, a 32-bit copy of java will be installed at: /usr/lib/jvm/ia32-java-6-sun .
Now, you need to convince Juniper Network Connect to use the 32-bit java. If you don’t use java for much besides your new VPN, you may just want to make the 32-bit java your default. This can be done by typing the following into your Terminal:
If you DO use java and just want to tell the VPN to use the 32-bit java, you should modify the junipernc by adding the following line right after the block of lines that start with “#”:
Now, when you run junipernc, it will use 32-bit java and you should no longer have the failure due to ncui.
Issue #2: Determining Your Realm
The scripting for Network Connect asks a few questions that may not make sense to a typical user. Even a networking savvy programmer may not be certain what values to use for the “Realm” or “PIN + SecureID Code”.
Finding your realm is fairly straight forward if you don’t mind diving into some HTML. Point your web browser to your company’s VPN website: https://vpn.mycompany.com or https://connect.mycompany.com . View the source of that page and look for a line like:
The value of REALMNAME is what you’ll need to enter when prompted. Your IT department may or may not know what this is if you ask them.
If you don’t know your “PIN + SecureID Code”, it’s simply the password you type along with your username on the VPN website to gain access. As mad scientist says, some companies use “SecurID so [they] enter a personal PIN plus the value provided by the SecurID fob,” which explains why he coded that as the prompt for the password input.
If you need help, there’s a long running thread over at the ubuntu forums where this continues to be discussed a lot: http://ubuntuforums.org/showthread.php?t=232607 . I gathered my info from both mad scientist’s page above and the thread itself.
One further note, I’ve tested this on Ubuntu 9.04 64-bit as well as 8.10 32-bit. Hope this is helpful to all you who need Juniper VPN access on 64-bit Ubuntu Linux.
So there I was, poking around in some java / j2ee code, trying to learn how it all works. I did some testing on a Linux server and realized, something is broken. It seemed something was corrupting ALL the Jar files in WEB-INF/lib/.
A co-worker guessed that the token filtering Ant was doing might be the culprit. He was right. It seems Ant has issues with detecting whether files are binary or not, given that it uses a Reader class which runs the files through a character decoder. This is specifically a problem on Unix systems since they commonly use UTF8 character set, and in that case Ant hasn’t a clue if its looking at UTF8 text or binary data.
So, I used a trick suggested in the Ant docs:
Another trick is to change the LANG environment variable from something like “us.utf8” to “us”.
On the Linux box, this meant we had a default character set of en_US.UTF-8 and it needed to be en_US. In this case we already had a bash shell script that runs ant, so adding a line export LANG=en_US to that script before Ant ran solved the problem.