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.
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.
We probably have different ideas about what constitutes the hard way; but that's not the point in this thread.
Anyway, NetworkManager can be managed using cli for those that insist, so all that was needed was:
nmcli connection import type openvpn file <filename.ovpn>
Even Arch wiki says:
> By default networkmanager-openvpn plugin appends DNS servers provided by OpenVPN to /etc/resolv.conf.
(which is not really true. Yes, it does the right thing with DNS info, but the specific action depends on the resolver backend NetworkManager is configured to use; for systemd-resolved and dnsmasq it configures these services instead).
I saw the cli is the easy way because it lets you do more. The barrier to entry is higher, yes, but if you're willing to get through that, things become easier. And by easier I mean take less time and get better results as well as easier to find solutions[0].
> Arch wiki
It looks like their solution was following the config in 9.3. So this is why I made a snipe at reaching for GPT when the Wiki is there.
[0] The analogy I'll give is that often a novice works harder than an expert when doing the same task, even if the task is simple. This is often because the expert is doing very minute things that they might not even notice that they can leverage. I know coders rock climb, so I'll use that as an example: this may be something like a subtle finger placement or how center of gravity is placed. The practiced person has more strength, but they will literally use less energy to get up a wall than a novice (and then it can be easy to overestimate what a novice can do because they judge what energy they use)
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).
It depends on the OpenVZ kernel, some later version can use WG. But OpenVZ is dying anyway so if someone use a still supported container technology, WG is probably available.
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.
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?
Wireguard works on Windows, iOS, Android, MacOS, Linux. It is supported on multiple routers.
And it can be configured with a single file, which on mobile devices can be imported as a QR code.
And the "server" side is set up the same way as client side - with a single config file per tunnel. Wireguard is popular because it is simple to configure.
And then there are many different solutions built on top of Wireguard, like Tailscale, which simplify some other aspects of setting up tunnels.
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.
Wireguard should leak less since the interface is up even if the connection is not established, it will still try routing packets through the Wireguard interface.
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.
>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).
I share GP’s expectations too. For me, VPN’s are that thing you do to access things that are normally not available to the public internet, ie. your work email and stuff.
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.
Sorry but no you don't, since you call into your LAN-network of course you can see your local machines.
But if you sit in a LAN and you call outside there should be no traffic leaked to the local network your calling out from (for example airport/motel etc).
>Point is, I don’t think of VPNs as something that prevents anyone from seeing my traffic
Correct, every middleman (normally ISP) can see that you connect from your External-IP to the other External-IP over an encrypted tunnel (udp or tcp). The expression 'vpn' i nearly as muddled as cloud ;)
If you want to obfuscate your traffic you need something like tor/i2p, however it's also possible to tunnel your vpn-tunnel through tor-tunnel's (but i don't see much sense in that since exit-nodes are for sure under more observation and publicly known)
Tor and vpn traffic can be detected and blocked (for example Chinese firewall) and for that, shadowsocks can be a solution:
I specifically want my traffic to “leak” from my VPN when traveling away from home, because my home internet upload speed is slow and I don’t want it to bottleneck everything else on my device. I only want the tunnel to be used when I am talking to my LAN.
Similarly when I’m at home and using my work VPN, I want a split tunnel there too. I don’t want every bit of traffic going over the VPN tunnel, because my work network tends to have congestion, and if I’m streaming music or something to listen to, there’s no reason that should have to go throufh my work’s network.
Before saying “nuh uh!” every time someone disagrees with you, maybe stop and consider that people have different use cases from you?
No you don't, you need a normal (for example) ssh-tunnel, not a "VPN"...trust me ;)
>Before saying “nuh uh!” every time someone disagrees with you, maybe stop and consider that people have different use cases from you?
You want to actively weakening a system that was made for one thing only (a point to point encrypted tunnel with no exceptions of data flow), but hey go on and make your setup a cobbled mess, but don't cry about leaked information.
> No you don't, you need a normal (for example) ssh-tunnel, not a "VPN"...trust me ;)
Yes I do. (See how tiring this is getting?)
I don’t want an SSH tunnel when wireguard does the same thing but faster and with an iOS app that works correctly out of the box. I’m aware of SSH tunnels and that’s how I used to do things back in 2008 but times have changed and wireguard is infinitely better at that use case.
> You want to actively weakening a system that was made for one thing only (a point to point encrypted tunnel with no exceptions of data flow), but hey go on and make your setup a cobbled mess, but don't cry about leaked information.
Nobody’s talking about weakening anything here, you’re coming into a conversation where someone said “use cases differ”, and you’re trying to deny that reality… every time someone shows you a different use case you childishly shout “nuh uh” and act like such a use case is wrong because it invalidates your point.
A split tunnel VPN is a valid use case, period. It’s not the only use case. People who want full tunnel where all traffic goes through the tunnel, ALSO have a valid use case. But it doesn’t mean split tunnel is not a thing, and it doesn’t mean people who want split tunnels are wrong.
>Your exceptions are wrong, 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).
>VPN's where made so you can securely work inside your enterprise network
>If you're connecting to the internet, route to the internet. If you're connecting to "inside your enterprise network", route through the VPN.
Block-lists, traffic-audit/amount, not allowed ports, protocol/packet inspection, mail-scanning and archival (aka have a hint how in-house data leaves your corporation)...enterprise stuff, you can do that on the endpoint, inside your "server-farm", or both, most enterprises distrust endpoints (for good reason), and completely trust the internal infrastructure (for often not so good reasons).
I know we are in that HN bubble but ~97% of enterprise don't work in IT but need lots of it.
>If you're talking about forced https interception,
No i don't, but some company's absolutely want that (sometimes for good reasons)
But you can also argue that an endpoint-firewall is just allowed to connect to one external ip (VPN-gateway) is also not a bad thing.
If you ever work for something critical (Financial/Defend/Insurance) you see 1000 points for securing/restricting the traffic (especially port 80/443) of endpoints and one for the opposite (that grumpy dev/ceo who wants admin right on his laptop and wants to use it "privately" too...btw even worse with smartphones).
His exceptions aren't "wrong", they just differ from the proposed use case. I use a VPN connection just like that, to temporarily gain access to my private network when abroad. When connected all "regular" (port 53) DNS traffic goes through the VPN so as to have easy access to internal addresses (many of which have external addresses as well), when disconnected the private network is not available. While I use the same setup to avoid being "monetised" by "free" WiFi connections that is not its main purpose. If my intention was to be completely safe from the TLA I'd use a different setup which only presents the VPN interface for outside connections, i.e no VPN means no network connections.
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).
>Okay, at that point I was clueless. I tried changing the DNS settings of OpenVPN (i.e. dhcp-option DNS 1.1.1.1) but it didn't work. After a couple of iterations with ChatGPT, it finally led me to the correct path.
This line was no-op until the author started using the `up` script as they describe later.
> The OpenVPN server can push DHCP options such as DNS and WINS server addresses to clients (some caveats to be aware of). Windows clients can accept pushed DHCP options natively, while non-Windows clients can accept them by using a client-side up script which parses the foreign_option_n environmental variable list.
It's still not clear to me what the experience would have been if the author had only 1.1.1.1 set at the system level, not touching any OpenVPN options.
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.
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
Does Firefox route WebRTC through a socks proxy? Does it leak your locally configured IP when WebRTC is initiated?
Even if the specific case of Firefox can be configured correctly and you have the source to verify that's it only sending traffic over the socks proxy, manually configuring every app to use a socks proxy is brittle and error pone, and for some apps just won't work.
Much more straightforward to just have a system wide VPN as the only available route for outbound traffic so that all apps use it transparently.
Calm down. If you're down the road about privacy, and you didn't already know about the webRTC thing, I don't know what to tell you. Do you want me to hold your hand and pretend you're my grandma, or are you a smart HN commenter? Seven proxies won't hide your IP if it's leaked by design implementation, and you have it enabled in a layer above the session layer. Hence why I prefer to assume a system is compromised and ONLY trust the apps I have verified and validated... If I'm doing something that needs that. "Whole-system" vpns are naieve. You're just looking to blame people.
When you get down from your horse, go and learn the Greenhills kernel and why everything from the nsa to the f35 uses it.
jfc dude it was just pointed out that the ssh+socks thing you provided has issues and there are simpler solutions. Ofc it depends on your goals but yeah if you care about privacy its a terrible solution because its incredibly brittle and there are much easier ways like using that ssh connection to setup a wireguard tunnel with a one-liner or any number of other more comprehensive solutions. Don't take it so personally, if it works for you it works for you.
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.
On the contrary: an accidental leakage is one of the many reasons a VPN provider cannot be trusted. Say I want to hide myself temporarily - which is safer - a VPN provider, having no idea how they handle data, logs and whatnot, or a tiny vps somewhere for half an hour while you need it, get your job done and then nuke it out of existence. The latter would be infinitely harder to compromise if you know what you are doing as opposed to a service that is running 24/7 and having no idea how data is retained.
You're missing the point. OP _is_ running their own VPN, the title is misleading, and the article has nothing to do with VPN providers and trusting them.
To quote:
> I have my own VPN () - in other uncool words, I set up OpenVPN on a VPS ...
The title should be "I configured my home rolled (Open)VPN server incorrectly and it leaked DNS".
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.
He most likely wouldn't have this problem if he used a VPN product for clueless users. It has nothing to do with trust towards a class of technology and all to do with the fact that computers are hard.
