I would say that the title is misleading. The author set up their own VPN, but didn't delve into what the config options they used actually do until they ran into problems. Everything else follows from that.
Clicking the link, it bought this was going to be about the issue identified in Mullvad discussed here; https://news.ycombinator.com/item?id=41856883 but this isn't even a bug or about trust.
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"
While there is some useful info in the post, the title is hugely misleading. The author tried one (single) VPN solution which they set up themselves, without full understanding of the things or even reading documentation upfront (although "it's right there under the DNS section").
It feels more like "I was unable to correctly setup VPN even using the very detailed instructions, but I can't blame myself, can I?"
Has nothing to do with VPN or OpenVPN (almost). “You can’t trust” “Linux” in this case. Its network stack is still not mouse-friendly in general and requires some thought.
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.
This is something I always wondered about: why so many linux users always take the hard way?
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.
It's been a while but e.g. with OpenVZ containers you couldn't do anything in the kernel, i.e. Wireguard.
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).
Is there a oneliner for setting it up on a ubuntu box akin to https://github.com/angristan/openvpn-install ? How does it work with iphone, android, windows? Can a regular person set up a client by receiving a single profile file?
Unrelated to OP's story, but besides tunneling traffic over TCP or even an HTTP proxy (which OpenVPN supports OOTB): plain Wireguard doesn't support 2FA, which is a requirement in some places. Unless there is an open source 2FA VPN solution built on Wireguard that I haven't heard about yet, in which case I'm interested.
OpenVPN is can hid your IP if set up correctly. Wireguard can in a way. But on the server your IP can be identified in some manner, maybe even after you sigh-out.
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.
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.
>I would expect my laptop to use my local DNS server if the VPN is up
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).
firefox has the ability for you to choose to separate dns requests from a SOCKSv5 proxy server, or make them go through the server.
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.
Great write up! Do you have any plans to create your own Arch Linux installer that bundles all your steps together so other users in your situation might be able to have a simpler time getting all the mechanics operating if they're Linux users but not as skilled as you?
bog-standard ssh server + bitvise local client = VPN
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
What if the the author simply used 1.1.1.1 / 8.8.8.8 / any other public DNS outside of their country for all traffic? It's an easier solution (yeah, with some drawbacks)
That doesn't work unfortunately. I specifically DNAT addresses like those to my own local DNS on my home network to prevent apps with hard-coded DNS from hitting them.
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).
or bog-standard ssh server + bitvise local client.
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.
If it's just DNS, yes. But more and more countries start using SNI filtering for blocking, which can be bypassed by locally running obfuscation tool, but at some point one can get annoyed enough and just use a VPN entirely.
I have honestly never trusted VPN providers in any shape or form. I had a university professor back in the early 2010's who said something very accurate: "Proprietary services providing anonymity provide everything but anonymity". I'm far more comfortable running a vps somewhere when I need to. And even then, VPN is kind of an exception since I hate fiddling with the setup(as easy as it may be). For most of my usage, an SSH tunnel as a socks proxy does it all and when I'm done, kill the vps and move on.
The article doesnt quite match the headline in the way your reply suggests. Trust, in this instance, is more about accidental leakage and installers not tailoring the OS to have Up and Down watchers to apply DNS changes.
It's not about whether the VPN provider can be trusted.
Setting up a VPN using my FritzBox at home together with the Android app wg-tunnel was dead simple. I was really surprised how easy it was. A few clicks in the routers web interface and then scanning the QR code it gave me was all I needed. wg-tunnel has a whitelist of wifis where I don't need a VPN and turns on automatically on all other wifis. A VPS is not necessary in this (and OP's) usecase.
Etheryte|1 year ago
vardump|1 year ago
DNS leaks are easy to miss.
letters90|1 year ago
mmsc|1 year ago
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"
yaris|1 year ago
Hikikomori|1 year ago
wruza|1 year ago
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.
vetinari|1 year ago
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.
botto|1 year ago
unknown|1 year ago
[deleted]
Jnr|1 year ago
It makes sense if UDP is blocked, but in this case OP is clearly using UDP for OpenVPN.
wink|1 year ago
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).
wruza|1 year ago
Idk about wg, but ovpn ticks all these boxes.
mr_mitm|1 year ago
jmclnx|1 year ago
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.
unknown|1 year ago
[deleted]
arcade79|1 year ago
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.
BSDobelix|1 year ago
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).
nofunsir|1 year ago
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.
udev4096|1 year ago
thelastparadise|1 year ago
anakaine|1 year ago
nofunsir|1 year ago
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
nofunsir|1 year ago
6) make a chain of ssh port forwarding.
7) make a script that randomizes the ssh port forwarding chain.
WmWsjA6B29B4nfk|1 year ago
alias_neo|1 year ago
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).
mmsc|1 year ago
DNS isn't authenticated.
ndheebebe|1 year ago
jbverschoor|1 year ago
nofunsir|1 year ago
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.
unknown|1 year ago
[deleted]
sbt567|1 year ago
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?
martheen|1 year ago
axegon_|1 year ago
anakaine|1 year ago
It's not about whether the VPN provider can be trusted.
mr_mitm|1 year ago
Hikikomori|1 year ago
jrvieira|1 year ago
endymi0n|1 year ago
unknown|1 year ago
[deleted]
ritcgab|1 year ago