
UH VPN – self-hosted VPN platform - jwsi
https://uh-vpn.com
======
onyva
Why openvpn and not wireguard?

~~~
jwsi
tldr; the main reason behind this was due to routing and authentication
flexibility.

Full explanation:

Most users of UH VPN utilise it for remote access to their corporate or home
networks. This often requires the use of concepts like split routing where
only certain subnets are routed over the VPN. OpenVPN achieves this much more
easily using it's "push" directives wheras a solution involving wireguard is
much more complex.

In addition to this, UH VPN is in part a VPN authentication system as a
service, as such it requires a VPN protocol capable of working with a custom
authentication system. OpenVPN does this very nicely using its "auth-user-
pass-verify" directive. This allows servers to make calls back to the UH VPN
API to check whether a user is indeed authorised to join a network as opposed
to just relying on the cryptographic validity of the connection request.

One final and often overlooked note is that when we started development of UH
VPN (the website, server software and client apps) wireguard was still very
much in its infancy and as such was not recommended for production use.
Therefore, we made a concious decision to use the openvpn3 codebase as our
base VPN protocol and build our feature set on top of this library. When
testing our applicaitons, the performance difference in most people's use
cases is near identical to that of a wireguard deployment. We have a strong
development team behind UH VPN and when wireguard offers a clear benefit for
our clients in terms of performance whilst maintining flexibility with respect
to routing and authentication we will add support for it alongside our openvpn
solution.

James.

~~~
onyva
Is t the same for resources used on the client side, on mobile in particular?

~~~
jwsi
Our mobile apps are lightweight in terms of resource utilisation. This is
largely due to two factors:

1) We utilise low level pause and resume network calls provided by the
operating system such that the VPN is only active when network data is being
sent or received. Therefore, when a device is on standby, the VPN is paused
preventing battery drain and resumed whenever the device polls for
notifications or is awoken.

2) Most OpenVPN implementations on iOS/Android (e.g. [https://github.com/ss-
abramchuk/OpenVPNAdapter](https://github.com/ss-abramchuk/OpenVPNAdapter))
utilise socket bridges, this has the effect of increasing the resource
utilisation massively for a given throughput as you have to copy data to and
from the network socket when sending or receiving data. Our VPN core writes
and reads directly from the underlying tunnel socket which reduces resource
utilisation heavily.

Both of these optimisations make our mobile applications very efficient. If
you try it out and run into issues, we also have a very active docs hub where
people ask questions and request features
([https://github.com/ultrahorizon/UH-VPN-
Docs](https://github.com/ultrahorizon/UH-VPN-Docs)).

