You are here

OpenVPN service

Project ID: 
Current stage: 

Description: We've had an OpenVPN not-quite-service for ages. It's time we put in the remaining work to bring it in as a full service.

Deliverables: OpenVPN service; setup instructions for self-managed users.


Customer: Potentially, all Informatics users

Case statement: Although IS run a (IPsec and PPTP) VPN endpoint, it terminates outside Informatics and is reported to be quite often unreliable. We've had an OpenVPN not-a-service running for quite a while now, and it has neither of the above disadvantages. Having proved the technology, we should put in the remaining work to bring it up to service standard.


Status: asked that this be moved from pending to proposal.

Timescales: The first couple of milestones should be achievable pretty easily. What comes after that depends on the decision regarding password authentication.





Resources: The service endpoints are running on the "network services" machines, currently ancerl in AT and hickox in the Forum. Load is sufficiently low that there's no point in dedicated hardware, and those machines are already site routers in any case.


  1. Set up a test endpoint, so as not to disrupt the existing not-a-service. Estimate no more than 1/2 day to parameterise the existing configuration files and fire up the endpoint.

  2. Look at authentication mechanisms. Estimate a couple of days or so.
    • X.509 is known to work with our kx509 infrastructure on Linux. Check out KfW and kx509 for Windows, as this would tie in with AFS too. Think about Macs. Users probably have to install something anyway, so a little more won't hurt...
    • Password in the not-a-service this is the user's DICE password validated against the PAM stack on the endpoint. Philosophically, is this a Good Thing? Practically, could we go with it for now, and drop in another PAM module (e.g. something RADIUS-based) later?

  3. Update sample configuration files and associated documentation.

Dependencies: OpenVPN has two authentication mechanisms available: X.509, dependent on our kx509 service; and password, which we may decide would be better not authenticating against kerberos, in which case something like RADIUS would be needed.

Risks: Nothing depends on this making it to a full service.



Proposed date Achieved date Name Description
2009-03-31 2009-03-31 TestServer Set up a test server, so as not to disrupt the not-a-service
2009-04-14 2009-05-19 EvalPasswd Evaluate password authentication mechanisms
2009-06-02 2009-08-10 Document Update user documentation
2009-09-01 2009-09-01 UserTesting Give a bit of time for pilot users of the not-a-service version to try it out and provide some feedback.
2010-05-14 2009-10-03 EnhanceDocs Enhance the docs enough (self-managed Linux, mainly) that it can become a full service.