You are here

OpenVPN FAQ

Printer-friendly versionPrinter-friendly version

This page contains some questions and answers specifically aimed at our local OpenVPN setup. The Official FAQ and documents linked from it contain more general information which may help resolve problems.

What does the Informatics OpenVPN offer that the University's central VPN service doesn't?

Using the Informatics OpenVPN means that you appear inside the Informatics network. This is in contrast with the central University VPN service, which will tunnel you to inside EdLAN but outside Informatics. This distinction may be important when accessing internal Informatics resources.

Why not have your endpoints masquerade as web servers?

This is something which can be useful to work around heavily filtered network connections, where very little other than web traffic is permitted. It would certainly be nice to offer such a service, but there are a couple of reasons why we don't (yet): the first is that current versions of OpenVPN are not quite flexible enough to allow them to manage two different types of connection at the same time; and the second is that tunnelling TCP protocols over a TCP-based transport can lead to performance issues which don't arise when tunnelling over a UDP-based transport, so it's better overall for us to support the latter. However, should later versions of OpenVPN allow us to implement something like this, we'll certainly consider doing so.

Can I connect to an endpoint more than once? When I connect a second tunnel it seems that my first tunnel is dropped.

You can only connect one tunnel at a time to our endpoints. This is actually the default behaviour, and we have left it as-is to protect our endpoints from misbehaving NAT gateways, which might otherwise use up all of an endpoint's client-IP addresses and so deny service to other users. We do have two endpoints, though, and you can bring up one tunnel to each independently.

I'm trying to access things like IEEExplore or the ACM digital library, but they're not letting me in. Why not?

This kind of thing can happen when the remote sites are using your IP address to authenticate. Our default "via" configurations will send most EdLAN traffic through the tunnel, but will leave everything else to go by its normal route. As a result, the remote site sees you as coming from your usual ISP address rather than the University. The solution, in this case, is to use one of the "all" configurations. If you use these, all traffic is sent through the tunnel, and the remote sites see you as coming from a University IP address. Normally we recommend that you don't do this, as it's less robust and efficient, but in some cases such as this one it's necessary.

I can't see any menu entries on my Windows box. Help?

Some browsers seem to like to append things to the names of the configuration files as you download them. Check that this hasn't happened. You may have to toggle some folder view options in order to see the full filenames.

I can't get my VPN tunnel to work at all

When you download the configuration files you must be careful that the contents are not changed in the process. In particular, any embedded certificates and keys must match exactly what the other end is expecting, otherwise your connection will be denied.

Why can't I get to any of the University's RFC1918 subnets?

We deliberately don't add any routes for these. They are defined as being for use within sites only. We have no way of knowing whether they are in use at your home site, or whether we would break your use of some other functionality by adding these. Therefore we don't. If you do need these routes to be in place, and you have determined that you can do so safely, then simply edit the configuration file(s) and add appropriate "route" statements alongside the existing ones.

What about IPv6?

We have been experimenting with IPv6 and OpenVPN. Our development and DR endpoints have the ability to tunnel IPv6 traffic alongside IPv4. However we don't yet have a range of "official" IPv6 subnets from IS to use for this purpose, and changing the addresses offered by the Forum and Appleton Tower endpoints while they have users connected would be disruptive.

We have also tested IPv6 endpoint addressses. These work well on their own, but our Linux kernels don't yet have quite the right features to allow the two to operate alongside each other on the same endpoint server. We are hoping that the (imminent) upgrade to SL7 will improve this.

My DNS has stopped working!

This can happen under a couple of circumstances: you are using the Edinburgh wireless and one of the "via" or "all" configurations; or your machine at home is set up to speak directly to your ISP's resolver and you are using one of the "all" configurations. The problem is ultimately that the resolver is refusing your requests as a security measure because they are coming by a path which it is not expecting.

If you are a Windows user, make sure you're using the correct platform-specific configuration files, as these have additional configuration options added to work around this problem. Otherwise, the most straightforward fix is to use an "only" configuration from the wireless, or an "only" or "via" configuration from home.

If none of these is possible then we may be able to suggest alternative options. However, none of these is likely to provide a simple automatic mechanism.

I've done that but my DNS still doesn't work?

Are you using NetworkManager on Linux? In testing we found that NetworkManager was not able to import our configuration files correctly, and in particular it ignored the routing details and set things up so that all traffic would go through the tunnel, regardless of which configuration was imported. Reports from users confirm that this is still the case with at least some versions. If this is the case it seems the best thing to do is to ignore NetworkManager altogether. From a root shell, cd to the directory containing your downloaded configurations, and run the openvpn daemon giving the configuration file name as the only parameter.
Last reviewed: 
06/05/2017

System Status

Home dirs (AFS)
Network
Mail
Other services
Scheduled downtime

Choose a topic