The end of the PPTP VPN


In September 2013 IT Services launched a new VPN service, based around Junos Pulse. This replaced the older PPTP based service, but the two ran in parallel for 9 months to give people a chance to transition.

On 30th June 2014 08:45, the PPTP VPN was switched off, ending 12 years of PPTP VPN use at the University of Bristol.

The story starts not with a VPN, but with wireless networking…

In 2001, Bristol dipped its toe into wireless networking, and started work on the “Nomadic Network”

Wireless technology was still young, and wireless encryption wasn’t widely supported on client devices. So Nomadic used an open, unencrypted SSID with restricted routing. The only thing you could get to was a bank of PPTP VPN concentrators, referred to as “roamnodes”

These roamnodes were cheap commodity x86 boxes with no disk.  They booted a custom linux live CD which held its config on a floppy disk.  This made upgrades/rollback really easy (pull out the CD, put the new one in, reverse process to revert)

The idea was that you connected to the wireless (or plugged your laptop in to one of the public network sockets, and connected to the access network via PPPoE), then span up a VPN connection to get on the university network.

That all sounds a bit clunky these days, but back then it was sophisticated enough that several other universities around the UK picked up the system – and we won the UCISA Award for Excellence in 2003. (Which caused a certain amount of amusement in the office at the time. They managed to misspell “Excellence” on the oversized novelty presentation cheque!)

As a VPN was an integral part of the Nomadic Network, it was convenient to use the same technology to provide off-site access to UoB restricted resources (as anyone using the wireless already had the client configured)

By 2005 wireless technology had moved on and work started to replace the Nomadic Network with a wireless system which eventually evolved into the eduroam service we have today.

Although the wireless no-longer had need of a VPN component, the VPN was retained and rebuilt as a stand alone service. The service had a refresh in 2007 to upgrade it to CentOS 5 – and it’s been running the same OS, on the same hardware ever since.

That hardware is long since out of extended hardware maintenance (and both of the remaining nodes have known hardware issues) client support for PPTP is now patchy and difficult to debug, it’s not compatible with a lot of home broadband routers, some major ISPs actively block PPTP and finally, the encryption used in our implementation had some weaknesses which we’d really rather it hadn’t! (although we have no evidence that those weaknesses were ever exploited)

So that’s why we’ve replaced it!

In some ways, I’m sorry to see it go as it’s one of the services I was initially employed to support. In many other ways though, it’s done its job and been surpassed by other technology. Maintenance and support of the service had become problematic. It’s time to move on.

For a service with approximately 500 users a month, it needed a surprising number of resources to keep it going.

Now that it’s gone we can shut down 2 physical PPTP head nodes, 5 unmanaged virtual linux servers which provide supporting services (authentication, dhcp, dns, web redirects etc) and 2 hypervisors which are also out of hardware maintenance.

The new Junos Pulse VPN is a single appliance. Much more efficient on rack space, power and cooling!

Juniper VPN – official Linux instructions

After much effort, we now have a packaged version of the Juniper VPN Linux client available! We also have a helper script which allows you to easily connect from your Linux desktop. It’s available for rpm and deb based distros, and as a tgz if you’re using a different package manager.

The instructions have been published here:

The old PPTP based VPN will be switched off on the 30th June 2014 and anyone using linux to VPN in will need to migrate to the new service before then.


More Juniper VPN Client…

As mentioned at the bottom of my previous post, it is possible to connect to the Juniper VPN without using the java gui, you just need the right command line arguments.

Well, I’ve worked out what those are.

./ncsvc -h -f ./uobnet.crt -r UoB-Users -u ab12345

(replacing ab12345 with your UoB username obviously)

The list of 32bit dependencies is significantly smaller (as it doesn’t involve Java!) and on Ubuntu the client seems to be satisfied with:

sudo apt-get install libc6-i386 lib32z1 lib32nss-mdns

As before, the above has had very little testing at all.  Any reports of what it does on non-ubuntu systems would be very welcome indeed!

Making the Juniper VPN Client work…

As well as the 32bit rpm version of the Linux client, Juniper have a browser based Java applet for all OSes – which also works on Linux.

It’s not as pretty as the windows/mac client, but it can be made to work – and if you rummage around in it enough it contains a non-java executable at its core which may be useful as the basis of a homebrew non-java application.

This blog post describes a way to get connected to the new UoB vpn using a linux client.  It’s not tested enough, or foolproof enough to qualify as “official” documentation.  It’s more a record of “what I did to make it work”.

We’ve still got a fair way to go before we can publish any of this fully alongside the other instructions.

So try it, if it works for you great! Let us know in the comments!  If I’ve got something wrong, or you’ve worked around one of the problems I hit, let us know in the comments!

If it doesn’t work for you we’d like to hear about that too, but asking for help via the bris-linux mailing list or the IRC channel is probably going to be more productive than asking in the comments.

Ubuntu 12.04 and 12.10 (64bit)
The GUI for the vpn client is a 32bit Java application.  Ubuntu doesn’t appear to install java at all as part of the base install.  So if you’re starting from a point where you have no java support at all, it’s fairly straight forward:

 sudo apt-get install icedtea-7-plugin openjdk-7-jre:i386

The icedtea-7-plugin package will pull in the 64bit version of Java as a dependency, and the 64bit version is chosen by preference.  You can change this by running:

sudo update-alternatives --config java

And select the 32bit version from the list.

At this point, you’ve got 32bit java installed and selected as your default version of java.  You also have the icedtea java plugin for 64bit web browsers installed.

Now point your web browser at and sign in using your UoB username and password.  When the page loads, you should see a line which says “Network Connect” – click the Start button.

You’ll probably get a popup warning saying that you need to make sure you’ve got all the required 32bit libraries installed.  You have (we’ve just done that!) so click “Yes”  – you’ll also get a couple of popups asking if you’re sure you trust the certificate the application was signed with

The first time you run Network Connect it will pop up a terminal window and ask you to put in your (local) sudo password.  This is because the underlying vpn widget needs to run as root, and this popup will setuid the binary so you don’t need to sudo every time you connect.


With a bit of luck and a following wind, you’ll get an ugly box pop up which says you’re connected!

I haven’t tested any of these, but as far as I can tell, doing this would probably work:

sudo yum install java-1.7.0-openjdk.i386 icedtea-web.i386

Then follow the rest of the Ubuntu instructions

I don’t want Java in my Browser!
Neither do I to be honest. I have the plugin disabled most of the time and enable it only when I want to connect to the VPN.

The version of the client which Juniper distribute as an rpm appears to be a packaged version of the java client which you can load from the browser as described above.

As yet, I’ve not had a chance to do any testing of the rpm version.  Details of that will follow in later posts…

I don’t want Java at all!
As far as I can tell, Java is only required for the GUI. It’s a wrapper around a 32bit binary executable which could be called from the command line (or wrapped in a non-java GUI or script I suppose)

I haven’t managed to find the right magic incantation to get it to actually build a VPN tunnel yet, but this is where I’ve got to so far:

  1. Download the java applet by going to If it asks you to log in, do so using your UoB username and password
  2. Unpack the archive with
    unzip ncLinuxApp.jar
  3. That should give you a folder full of files, which we need to go into:
    cd ncLinuxApp
  4. There’s a helper script we need to run first, which grabs the SSL certificate in use by the VPN connection.  Run it like this:
    bash ./ uobnet.crt
  5. The binary which actually builds the tunnel is “ncsvc” which is a 32bit executable.  It appears to require 3 packages on Ubuntu:
    sudo apt-get install libc6-i386 lib32z1 lib32nss-mdns

However, at that point I’m stuck.  It looks very much like you should be able to build a tunnel by making ncsvc setuid and then calling it with the appropriate parameters:

sudo chown root ncsvc
sudo chmod +s ncsvc

Unfortunately I can’t make it work

I’ve made it work!  See this followup blog post for details.

I don’t like closed source binaries either..
As Ian has mentioned previously, We’ve not managed to get the network-manager-vpnc client to connect at all.  We’ll probably come back to that after prodding at rpms, but in the mean time, if you manage to make it work please let us know!

Further Reading
Most of the above is information culled from the following links.  They may be helpful if you fancy having a prod at this yourself.

Some of those links contain perl script wrappers for ncsvc, but as I’ve not had a chance to read every line of that code to make sure it’s not malicious in any way I really can’t recommend you use them!

Linux and the UoB VPN

The University of Bristol has had a VPN service for at least 11 years now, and although the hardware has had a few upgrades in that time the service is essentially running in the same form, using the same old technology.

Time has moved on, and the old VPN service needs replacing so that we can bring its support level up to where we want it.

We’ve procured a VPN appliance from Juniper, and this meets the needs of the majority of Windows, OSX, iPhone and Android users (and meets those needs much better than the old service ever has done.)

Unfortunately there are a few “wrinkles” in Juniper’s Linux client support.

Juniper Client
Juniper do distribute a Linux client.  It’s packaged as an RPM suitable for RedHat Enterprise (or derivatives such as CentOS or Scientific Linux) and is 32bit only. Which is fine, if that’s what you’re using!

If you’re using a Debian derived distribution (Debian, Ubuntu, Mint etc) or a 64bit OS, then it’s not so great.

Various workarounds which will get that 32bit RPM installed on a 64bit Ubuntu (or whatever) seem to be available according to google, but we’ve not had the resources available through the summer to test or document them. Work is now tenatively beginning…

Network Manager

Most linux distributions come with Network Manager these days, and on most of those distributions you can get the “network-manager-vpnc” plugin, which claims to be “compatible with various Cisco, Juniper, Netscreen, and Sonicwall IPSec-based VPN gateways”.

This would seem to be the ideal solution (as it’s built in, doesn’t have any 32 bit dependencies etc) unfortunately we haven’t managed to make it work yet. Discussions with Juniper suggest that this may be caused by a bug in the way they talk to our AD, with a possible fix coming out later in the year, but this is yet to be proven.

That’s not great either, so we need some coping strategies…

Plans B, C, etc…
In the short term, we’re going to keep the old VPN service around so that linux clients still have a way to connect in remotely until we can come up with something better.

We would welcome you to try getting the 32-bit client installed on the distribution of your choice. If anyone makes any progress with that before we’ve had a chance to, please let us know!  Any testing we do will initially result in more blog posts here, and eventually some proper documentation (and hopefully some wrapper scripts/installers if we can get that working)

In the longer-term, we’d obviously like Juniper to release 64bit binary packages (and .debs!) We’re in contact with Juniper about their roadmap and release cycle and will be re-evaluating all of the above options as & when more information becomes available…

** STOP PRESS ** We have managed to make a 64bit Ubuntu machine successfully connect to the VPN. Details will be in a follow-up post.