←back to thread

182 points whalabi | 2 comments | | HN request time: 0s | source
Show context
Fnoord ◴[] No.19208623[source]
I'm using Pi-Hole on an Ubiquiti router together with WireGuard and DNSSEC. My Synology NAS is backup (with regards to the DNS-based Pi-Hole blocking) taking the adblocking load off the router (there's no redundancy for WireGuard endpoint though). I don't (need) to use a RPi anymore. It works extremely well for me, and all my clients also get to connect to Nextcloud running on the Synology.

My setup does far more than just blocking ads, and works transparent as long as the client is connected through WireGuard (which works seamlessly over LTE and public WiFi).

That being said, I really like how Blokada and DNS66 are available in F-Droid [1] [2], and require minimal technical knowledge to set up. The more [ad blocking], the merrier.

As a backup measure I use Firefox with uBlock. The only machine I don't use uBlock is on Kali because I want to see the website exactly as it is being served.

[1] https://f-droid.org/packages/org.blokada.alarm/

[2] https://f-droid.org/en/packages/org.jak_linux.dns66/

replies(5): >>19208826 #>>19209399 #>>19209864 #>>19210109 #>>19214442 #
alias_neo ◴[] No.19208826[source]
It's interesting you've found the WireGuard experience to be "seamless".

I have a WireGuard VPN at home and experimented with always-on, on my Android phone. Unfortunately, my provider (EE, UK) throttles UDP traffic something rotten, and my normally great experience with 50/50Mb+ is severly limited to between 0 and 10 Mb making my phone almost unusable by normal standards.

Does your LTE provider not throttle this way, or have you found a way around this?

replies(4): >>19208897 #>>19209097 #>>19209166 #>>19209223 #
dspillett ◴[] No.19209223[source]
> Unfortunately, my provider (EE, UK) throttles UDP traffic something rotten

Interesting. I've not noticed performance issues beyond those expected due to signal quality when using work's VPN over a tethered phone using EE. That VPN is using OpenVPN with a UDP transport. Then again it doesn't get used for anything with high throughput so perhaps they only throttle when it looks like bulk transfers are happening or the effect of the throttle just isn't apparent for my interactive use-cases.

> or have you found a way around this?

If they are throttling UDP for your use case then you could try a TCP based VPN (OpenVPN supports this), though there are potential issues with layering TCP inside TCP particularly on high-latency connections so this is not usually recommended. Might be worth a try to compare/contrast though.

I have a play with mine both ways when I finally get round to adding it to my current phone (mainly to use the network level ad-blocker running at home) and see if I can see a measurable difference with each variant.

replies(1): >>19211004 #
alias_neo ◴[] No.19211004{3}[source]
I don't run my VPN for ad-blocking (my phone is rooted), I use it for more traditional access reasons.

To copy and paste another reply I just made:

"I ran some tests with the guys in WireGuard IRC which seemed to confirm that the issue is specifically EE limiting UDP whether by QoS or otherwise."

I'll give OpenVPN a go over TCP once I have a chance to set it up and I might even consider contacting EE for info.

I would mind the fact that it limits my throughout to, at best 12Mb down, but when on WG it typically approaches 0 making my device unusable and I've already ruled out the rest of my network.

replies(1): >>19217310 #
1. dspillett ◴[] No.19217310{4}[source]
Another possibility is that they are using naive port-based filters in their traffic shaping rules, and it thinks that any encrypted-looking packets not destined to one of a white-listed set of ports is torrent or other P2P traffic.

If you run the server side of the VPN as well as the client, you can test that possibility by trying other known ports (1194 that OpenVPN usually lives on, 433 if that isn't already directed elsewhere on the target address, ...).

replies(1): >>19261554 #
2. alias_neo ◴[] No.19261554[source]
I tested running on other known ports such as 443 and hit the same rate limit. I suspect they have some network-wide cap on UDP transfers.