Tuesday, January 22, 2013

Juniper Network Connect VPN client

In addition to using the Cisco VPN client at work we also need to make use of the Juniper Network Connect (JNC) VPN client at times. After struggling to get it working and reading a lot of blog posts, including this one which is important for getting hold of JNC via a browser, I discovered the MadScientist's blog post. Fortunately I discovered that I don't really need his msjnc perl script even though it has helped me a lot. It is however required for proper initialisation/setup of JNC. This post will explain what I have learnt and hopefully it will also help someone else (if not, then I have at least documented it for myself).

After following the blog post I was still unable to get it working, because:

  1. My computer is behind a proxy through which I am supposed to access the VPN. Unfortunately the blog post does not go into any details regarding proxies.
  2. When setting up a profile using the  msjnc front-end it tries to download an X.509 certificate using the ~/.juniper_networks/getx509certificate.sh script which tries to execute

    openssl s_client -connect $1:443 < /dev/null 1>out.txt 2>err.txt

    This failed for me, because I am behind a proxy and openssl does not support proxies. The workaround for this was to connect directly to the Internet (using a different network) and then configure a new profile from scratch. Once the certificate is downloaded it can be reused - even when behind a proxy as will be seen later. The certificate is downloaded to ~/.juniper_networks/.cert.<vpn.host>
  3. I believe there are a few bugs in the msjnc front-end when configuring the VPN proxy server hostname:port pair. Whenever I entered something like 10.0.0.10:8080 it complained that it was not valid. This results in incorrect settings in the ~/.msjnc-profiles.cfg file. I should probably fork the GibHub project and send a patch instead of just complaining :-)

After fidgeting a lot I noticed the command that msjnc tries to execute in the ~/.msjnc.log file. I copied+pasted this into a terminal and voila!

When connected directly to the Internet the following command works for me:

~/.juniper_networks/network_connect/ncsvc -h <vpn.host> -u <vpn.username> -r <realm> -P 443 -U https://<vpn.host> -f ~/.juniper_networks/.cert.<vpn.host>

where:

  • vpn.host is the hostname or IP of the VPN server
  • vpn.username is your username as provided by your "network administrator"
  • realm is the realm of the VPN you are connecting to (see the introductory comments of the msjnc script on how to determine your realm)

When behind a proxy the following command works for me:

~/.juniper_networks/network_connect/ncsvc -h <vpn.host> -u <vpn.username> -r <realm> -P 443 -U https://<vpn.host> -y <proxy.host> -z <proxy.port> -d <proxy.domain> -s <proxy.username> -a <proxy.password> -f ~/.juniper_networks/.cert.<vpn.host>

where:

  • the above arguments are still valid; and
  • proxy.host is your proxy hostname or IP
  • proxy.port is your proxy port
  • proxy.domain is the Active Directory DOMAIN (I think), such as WORKGROUP
  • proxy.username is your proxy username
  • proxy.password is your proxy password

What I like about this solution is that once it is setup you do not need to jump through all the Java hoops or even visit your VPN's web site. You can just run the command, type in your password when prompted and then you are connected to the Juniper VPN. You also don't need the msjnc script any more, but I'll keep it around just in case.

5 comments:

  1. I must say, I have configured OpenVPN as a server and connected to it from both Windows and Linux, and it is much simpler to use than any of the other VPN solutions that I have come across (didn't we use Cisco VPN at Rorotika?). I guess Cisco VPN (or JNC VPN) makes sense if you have already invested in the hardware as part of your network infrastructure.

    ReplyDelete
  2.  I agree, OpenVPN is probably the easiest among all of them, but the client uses Cisco VPN for their DEV/QA environments and the Juniper VPN for their PROD environment. I therefore do not have any say about the matter. The VPNs also authenticate using certificates instead of IPSec / group passwords. Most open-source solutions only support IPSec.

    ReplyDelete
  3. Ah, ok. Well, with OpenVPN you can also make use of certificates to authenticate users. It provides utilities to generate / revoke certificates. Thus, your certificate is your way to get connected to the VPN, instead of using a username / password (although you can additionally specify a password for a certificate as well). It's just strange to me that companies shy away from OpenVPN. But I guess its because they buy hardware with a certain VPN-solution pre-installed.

    ReplyDelete
  4. Yes, that is also the case here. And I have learnt that "certain companies" avoid open-source software as much as possible, because "it is difficult to get support for it". They prefer to pay for hardware/software so that, when it breaks, they can point fingers.

    ReplyDelete
  5. Good post. sharing valuable information about K-Secure VPN Server guide
     

    ReplyDelete