You are here
OpenVPN FAQ
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.
- 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.
- 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.
- 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.
- This kind of thing can happen when the remote sites are using your IP address to authenticate. Our "EdLAN" 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 "AllNets" 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 considerably less robust and efficient, but in some cases such as this one it's necessary.
Alternatively, this may be a use-case where the University's central provision would suit you better, as it is set up so that all traffic does go through the VPN tunnel.
- 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.
- 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 endpoint is expecting, otherwise your connection will be denied.
- We deliberately don't add any routes for these to our base configurations. 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.
Alternatively, we do have some additional configurations (
...+10+efin...
) which have additional routes for a selection of RFC1918 subnets. It may be that one of those works for you, while not breaking some other use at your site. - Our configuration files now route IPv6 through the tunnel alongside IPv4. Most Informatics managed services are IPv6-enabled, and this is the best way to avoid unwanted delays and failures when connecting to these services. If you really don't want this behaviour, simply edit your configuration files and remove any "route-ipv6" lines from them.
We have also tested IPv6 endpoint addressses. These work well on their own, but our Linux kernels still don't have quite the right features to allow the IPv4 and IPv6 to operate alongside each other on the same endpoint server. Unless the features are backported we'll have to wait for SL8 or Ubuntu endpoint servers before trying again.
- This can happen under a couple of circumstances: you are using the Edinburgh wireless and one of the "EdLAN" or "AllNets" configurations; or your machine at home is set up to speak directly to your ISP's resolver and you are using one of the "AllNets" configurations. The problem is ultimately that the DNS 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 "InfNets" configuration from the wireless, or an "InfNets" or "EdLAN" 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.
- 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 theopenvpn
daemon giving the configuration file name as the only parameter. - If these are of the form:
Tunnelblick: Warning: DNS server address AAA.BBB.CCC.DDD is not a public DNS server known to Tunnelblick and is not being routed through the VPN
or
Tunnelblick: This computer's apparent public IP address (AAA.BBB.CCC.DDD) was unchanged after the connection was made
then it's safe to ignore them if you're using one of our configurations.
Tunnelblick emits these warnings because it can't tell whether it's a deliberate configuration choice (which it is in our case) or an error which might compromise a user's privacy.
It is possible to tell tunnelblick not to show these warnings, but we don't generally recommend doing so. It's a global setting, and it would mean that you wouldn't then be warned about potential issues when using non-Informatics configurations.