It makes sense if UDP is blocked, but in this case OP is clearly using UDP for OpenVPN.
I don't have access to that VPS anymore, but I was already using Wireguard but had to use OpenVPN here, so I can't tell you if this is still a widespread problem or a historical curiosity.
Also sometimes, especially cross-organization, the chance that OpenVPN is already in use is much higher (if they're not doing Open/StrongSWAN anyway).
Depending on the ISP setup, sometimes WG can be less reliable due to MTU and/or UDP filtering, I remember an ISP from years ago where WG don't work only on certain hours, while OpenVPN running on the same server still work.
Idk about wg, but ovpn ticks all these boxes.
Mobile users simply scan a QR code and are good to go.
And then there are many different solutions built on top of Wireguard, like Tailscale, which simplify some other aspects of setting up tunnels.
Wireguard is good for places like Europe and North America. But if in Mainland China, Russia, Iran and countries like that, you need use OpenVPN.
Not sure why Wireguard would be less useful in the mentioned countries, but I guess it is because of blocking of UDP traffic? And as far as I know, China and Russia does not block UDP traffic.
I would expect my laptop to use my local DNS server if the VPN is up. My local DNS server is the one I have on my home network. The rest of my traffic, I would expect to go through the VPN tunnel.
Problem of course is that VPNs used to be expert-level stuff. This kind of "avoid government blocks" use of VPN wasn't even common when I started fiddling with OpenVPN around 2001/2002.
No, a correct configured VPN-tunnel is tunneling all data from one point to another (zero exceptions) if vpn is de-connected no data should be transferred (aka interface down).
If you want something else work with per-application proxy's.
>Problem of course is that VPNs used to be expert-level stuff.
And it still should be that way, VPN's where made so you can securely work inside your enterprise/home network while sitting anywhere in the world, all services are provided from local servers and if external, go through the enterprise-firewall (traffic-audit, IDS, and maybe other VPN-tunnels to other external locations subnet's etc).
I use wireguard to access my home network while I’m not at home for instance. I have homelab stuff at *.lan.mydomain.example, and in my ideal world, my iPhone would only connect on-demand when I try to connect to something in that domain. (Currently you can only configure connect-on-demand per IP prefix in the iOS wireguard app, even though iOS NetworkExtension.framework allows domain-based configuration… I should send the author a patch some day…)
Point is, I don’t think of VPNs as something that prevents anyone from seeing my traffic. I use it to get access to stuff that is normally behind a firewall, and a split-tunnel VPN that only sends the minimum amount of traffic over the tunnel is what I want.
This idea of VPNs as privacy tools is the much newer use case that wasn’t really the point when they were originally conceived.
>VPN's where made so you can securely work inside your enterprise network
Discord.com is not your enterprise network.
even if you want local control of the dns server, i would still set up the dns server to retreive its data via the ssh tunnel (via standard port forwarding) as well.
If it can be done at a home network level, you bet it can be done at ISP/government level.
The only safe/working option is to tunnel everything down a VPN somewhere outside of the problem region, and go out from there. The VPN connection implicitly provides a cryptographic verification that the connection isn't being intercepted or redirected (when done right).
DNS isn't authenticated.
It's not about whether the VPN provider can be trusted.
Quoting key points from TFA:
- (DNS leak happens)
- The DNS changes are not automatically applied by the OpenVPN client on Linux.
- You need to configure up and down scripts for managing the DNS updates.
- The recommended script is update-resolv-conf, which modifies DNS settings when the VPN connects and restores them upon disconnection.
- That script consists of a bunch of arcane bash commands that I don't understand.
Iow, OpenVPN decided to not mess with system scripting.
For Linux, the OpenVPN client can receive DNS host information from the server, but the client expects an external command to act on this information. No such commands are configured by default. They must be specified with the up and down options. There are a few alternatives for what scripts to use, but none are officially recognised by OpenVPN, so in order for any of them to work, script-security must be set to 2. The down-root plugin can be used instead of the down option if running as an unprivileged user.
Otoh, it could at least signal that somehow in the ui/cli. Does it not? I’m pretty sure there’s no dns leaks on my kubuntu boxes with ovpn profiles, but can’t test right now. If so, it’s probably an even narrower Arch + network manager problem.
They have two options: a) use the mouse-friendly way in NetworkManager to configure their VPN client (yes, it handles VPN DNS too; if you have systemd-resolved, it can also do split-horizon DNS over specific links) or b) funble around with tools and scripts they have no idea how they work, complain how complicated it is, and either get lucky so it works somehow or break their system entirely.
With a current desktop linux system, they should take the option a). They can use command line if they insist, nmcli is also here.
OP could have solved their problem by rtfming... It is literally the first paragraph on DNS. We're talking about "turn it off and on again" style issues.
Before you reach for GPT, check the man pages and check the Arch wiki, you'll save a lot of time and get more information.
EDIT to clarify because i feel many might not be aware how easy it is: 1) enable port forwarding in your sshd config (implies you can't just do this on a server which you don't admin and which has this disabled) 2) point bitvise's socks5 proxy server feature at the ssh server 3) point anything that needs to be tunneled at the bitvise client's port (default 1080) e.g. firefox. 4) voila, packets leave and return via the ssh server's public IP.
there you go with an easy socks5 proxy.
1) enable port forwarding in your sshd config (implies you can't just do this on a server which you don't admin and which has this disabled)
2) point bitvise's socks5 proxy server feature at the ssh server
3) point anything that needs to be tunneled at the bitvise client's port (default 1080) e.g. firefox > about:preferences > Network Settings (at bottom) > Manual proxy configuration > SOCKS v5 (enter details and your password if you set it up in bitvise) > also check "Proxy DNS when using SOCKS v5" at bottom
4) voila, packets leave and return via the ssh server's public IP.
5) For stubborn apps, check their config files, or use tsocks
I'm wondering though. If the block is on DNS level, isn't it easier and cheaper to use dns-over-https or dot instead?
A VPN (in this context) is hardly a VPN if it doesn't traffic dns requests, and it's probably the false advertising by the "you need a vpn to securely access the internet" companies that misinformed OP what type of VPN they were setting up.
The title should be more like "can't trust not reading the manual these days", or "can't trust sane defaults"
