I’ve been testing VPN services and somehow every one with a client has written their own. Proton, Windscribe, IVPN, Mullvad, AirVPN, NordVPN, and the list goes on.

Don’t these services all do the same thing? Connect to a server to get a list of servers, then use WireGuard or OpenVPN to make a connection, and have some fancy stuff like split tunneling or a killswitch. It should just take configuration by adding profiles per service and it should be possible to use the same client.

What am I missing?

  • litchralee@sh.itjust.worksEnglish
    26·
    2 days ago

    There are business, technical, and UI/UX reasons for having a client. The business case is that it clearly demarcates the service they’re selling, because it must be installed and isn’t built-in (eg Firefox VPN). The act of having the user do something means that for a brief moment, they have to concentrate on the product. Consumers have this tendency to value things higher if they were involved in its success, such as when building flat-pack furniture.

    The technical side is that while a VPN is indeed just a tube that transports packets securely to the VPN servers, the fact is that there are so many ways for this to go wrong. For example, leaking DNS requests is a way to throw the confidentiality guarantee* of a VPN out the window. As can Happy Eyeballs, where the same HTTP request is sent by both Legacy IP and by IPv6; if both aren’t sent through the tunnel, confidentiality is lost.

    To deal with this, the client can implement mitigations, such as setting a different DNS nameserver, as well as the (IMO exceedingly inappropriate) measure of disability IPv6 outright. These are not functions which the built-in VPN client in the OS would necessarily do, although some OS network managers genuinely will do a good job. But even more important than applying mitigations is to check for leaks! The client app can run periodic tests to make sure DNS or IP packets are always going down the tunnel, such as by checking destinations that only exist through the tunnel. Failure to pass this test should throw up huge warnings that the user’s confidentiality may be imperiled. This is table stakes for a retail VPN service in 2026.

    Finally, UI/UX for a VPN requires that the whole thing be easy: users want to browse the web, download … uh… Linux ISOs, and go about their life with a VPN that Just Works ™. Most people do not want to copy a Wireguard config into the OS using a terminal. A VPN service should have broad appeal, since the fear mongering advertising suggests it’s a product that everyone online should use.

    At bottom, we can say that “retail VPNs” really do need a client app. But for technically minded folks, a Wireguard config would be enough, because the endpoints would also be configured to route solely down the tunnel. Or even use an isolated netif, in the case of Linux namespaces, which is IMO quite clever.