4 ms·

Why openvpn and not wireguard?

by onyva 6y ago

deleted 6y ago
[deleted]
jwsi 6y ago
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 6y ago
  Is t the same for resources used on the client side, on mobile in particular?
  - jwsi 6y ago
    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).

Why openvpn and not wireguard?

by onyva 6y ago

Why openvpn and not wireguard?

deleted 6y ago

[deleted]

jwsi 6y ago

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 6y ago
Is t the same for resources used on the client side, on mobile in particular?
- jwsi 6y ago
  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).