Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Can't trust any VPN these days

blog.orhun.dev

Post reply on HN
Print view View original

31–40 of 85 posts

Re: Can't trust any VPN these days

#31

Post by alias_neo »

WmWsjA6B29B4nfk wrote: post #16

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).

Re: Can't trust any VPN these days

#32

Post by nofunsir »

ndheebebe wrote: post #30
nofunsir wrote: post #9

Earlier quoted context omitted.

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.…

So I open say Firefox and it routes it all through that. No gotchas?

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

Re: Can't trust any VPN these days

#33

Post by mmsc »

WmWsjA6B29B4nfk wrote: post #28
mmsc wrote: post #18

Earlier quoted context omitted.

It would be intercepted at the ISP level and the false results would still be received. There are lots of DNS intercepting tools ISPs buy these days. DNS isn't authenticated.

I understood they have been simply accessing their ISPs DNS through the tunnel.

No:

>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.

Re: Can't trust any VPN these days

#35

Post by alias_neo »

axegon_ wrote: post #29
anakaine wrote: post #8

Earlier quoted context omitted.

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 do…

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".

Re: Can't trust any VPN these days

#36

Post by wruza »

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.

Re: Can't trust any VPN these days

#37

Post by mmsc »

BSDobelix wrote: post #21
arcade79 wrote: post #10

The tragedy here is that expectations differ. 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 20…

>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 mad…

>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

Discord.com is not your enterprise network.

Re: Can't trust any VPN these days

#39

Post by mr_mitm »

Jnr wrote: post #22

Maybe a bit off-topic, but genuine curiosity - why would anyone go for OpenVPN these days, when there is Wireguard available? It makes sense if UDP is blocked, but in this case OP is clearly using UDP for OpenVPN.

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.

Re: Can't trust any VPN these days

#40

Post by ninkendo »

BSDobelix wrote: post #21
arcade79 wrote: post #10

The tragedy here is that expectations differ. 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 20…

>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 mad…

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.

Post reply on HN