Juniper VPN, 64-bit Linux .. an unsolved mystery?
The OpenConnect project, which was initially created to support Cisco’s AnyConnect has brought in support for Juniper VPN’s. While I haven’t tried it myself (no access to a Juniper VPN any longer) it could be a huge time saver.
Thank you Eccentric.Ash for bringing this to my attention in the comments. The approach in the linked forum post is much much easier to implement. And a special shout out to dvo over at ubuntuforums.org for sharing this solution.
Useful script: I received an email from a nice fellow, also named Scott, who produced some code to automate this process a bit. With his permission I am sharing the link to his Google Code project here: juniper-vpn.
I’ve been running the 32-bit version Linux Mint 7 for the past month. To date it’s been the most straight forward “everything just works” Linux distribution that I’ve used. And it wasn’t ugly either. But, not quite everything “just works” the way it should. Pulseaudio and the ALSA sound driver for snd-hda-intel just didn’t work very well.
B+ for Linux Mint and A+ for Juniper. Good job folks!
Er, not so fast. 32-bit Linux is getting kind of dated. My machine is a Core2 Duo, 64-bit, so it’s kinda silly not to take advantage of that. And to top it off, Unbuntu 9.10 Beta was just released.
I installed it. It went quite well. I installed it right over the Windows XP partition I had been saving for absolutely no sensible reason. Later Windows!
Then I tried to log into the VPN.
So I put on my hacker hat and started digging. Starting, of course, with a Google search that turned me onto a nice solution that some other gentleman had worked out. Unfortunately it wasn’t quite enough. We use a two-phase auth scheme and this only supports a one phase. We need a username, password, and RSA token. This script assumes you only use a PIN+RSA token as a single password. The fortunate part is that his script really identified all of the key pieces so I could eventually solve the puzzle. But it wasn’t as obvious as it should have been.
Runs the VPN client software, communicating with the Java app via IPC. It’s … fascinating.
In a 32-bit Linux system this works wonderfully well. It’ll also auto update which is very cool.
In a 64-bit Linux system not so much. It pretty much just chokes when the dynamic linker tries to pull in a file called libncui.so, which happens to be a 32-bit ELF binary.
But the show doesn’t end here. The application is still present in $HOME/.juniper_networks/network_connect.
By now you are either very bored or you are thinking, well hey, why not just run the application and give the DSID! If so, then you are pretty much on the same page as I was at the time. But get this. There is *no* way, to my knowledge, to give that stinking DSID to that stinking ncsvc application without jumping through the same IPC hoops as the Java app. Well, I’m not about to try and debug *that*. No thank you!
Notice, there is a -p for password? That’s great, but we need two passwords in a two phase auth scheme. There isn’t a -pp or a –second-password or any other such switch. There just isn’t any bloody way to suff that 2nd password down its throat.
Some shell scripts that prove mostly useless and a couple of logs containing anything but useful information.
The files that look interesting are ncsvc (obviously), NC.jar, ncdiag, and libncui.so.
Major let down. MAJOR let down. I spent a good while trying to get that parameter accepted. My perseverance finally paid off when a quick strings * revealed the true source of that usage string that NC.jar spewed forth. It was in libncui.so. Now what kind of shared object file has a usage string inside?
Build an executable from libncui.so and call it ncui.
The cursor just blinked at me.
There wasn’t an error message.
Yes! Glorious success! It worked! A quick run of netstat -nr revealed that all of the VPN specific routes were present, I could resolve names, and I could ping the resolved IP addresses. I could access services. Everything looked just a little brighter.
In total I probably spent about 12 hours of my weekend painfully going through all of the motions to finally get to a working VPN client. Next I’ll spend a few hours writing up some dandy ruby code that logs me into the VPN from the command line. No more web browser. Not necessary.
If prompted for a password just press ENTER.
I have been struggling with this for a while now (Ubuntu 10.04 LTS, AMD 64), even with a setup that is less complicated as yours ( a single password).
Your solution works perfectly !
I’ve been toying with this for what seems like forever. This seems to work perfectly in archlinux 64-bit.
Yess! This is the best thing ever! One remark though: enter the cookie with ‘DSID=’ in front of it. Took me a few extra minutes before I had that figured out.
Great post! It was really helpful for me! THANKS A LOT!
Good remark from Marco D, about DSID!
Scott, your method worked perfectly for me until my company decided to upgrade to “Junos Pulse Secure Access Service”. That upgrade broke the workaround that you had suggested above.
After about a week of trying in vain, I came across the below post on Ubuntu Forums that is a simple fix for the problem. I hope this helps others who are in the same boat as me.
I’ll link it in the TOP of the article. It’s so much simpler! I do tend to do things the hard way.
Thank you sooooo much for posting the link here!
David, thanks for solving this more easily. I’ve posted a direct link to your post at ubuntuforums.org at the top of this article. It’ll save a lot of people a lot of time.
Excellent solution! Congratulations, really works. Thanks a lot.
I’m on Fedora 16, 64x and have the same problem,I found this problem is java64 attempting to load a 32b DLL. of course this fails..
Been struggling with this for like ages before I found your excellent instructions.
Thanks for your post, it was really useful. I can now connect to our VPN. This post was clear and concise and finally, I can connect without having to downgrade my entire system to 32-bit.
Thank you very much. It works on ubuntu 13.04 amd64. It made my day!
Absolutely awesome work! Thanks a lot!
That was pretty neat! I tried the same based on your instructions and they work fine. However I am experiencing network interface issues after killing the ncui process.
I need to either restart the machine or manually turn the interface down and up again on encountering this issue. I don’t want the users to face this interface issue after killing the VPN connection. Any suggestions or recommendations for resolving this issue?
The only thing I can think of is that the routing tables got screwed up after closing the VPN connection. You might just have to do something like restart the networking service.
Every time a have to get the cookie DSID ?
Is there another way?? because if every time i should do this is easier log in normally.
I am using fedora 20 64 bit and it is not working. it is not the same way like u can do it on ubuntu. can any one please help me.
Remember, the role must NOT be configured to use Junos Pulse, only Network Connect.
3.	Download java from http://java.com/en/download/manual.jsp and extract into your Download folder for both 32 and 64 bit environments. The download file names are identical. Either rename the tar file or place in a separate directory under the download folder. The next step uses different directories when downloading files. The tar files were downloaded and extracted to their respective download folders.
4.	Move extracted contents to the directories created in step 1.
For every new or other existing user account on a Linux machine the following steps must be taken assuming the initial user account went through the prior 13 steps.
7.	Try to login to your SSL VPN page.
Praise the lord! this worked like a charm for me! No more hoop jumping through Windows VMs and DSID stuff!
Although — I used the method in this tutorial for months and it worked like a charm (saved my bacon in fact).