←back to thread

Block Ads in Apps on Android

(unlikekinds.com)
182 points whalabi | 5 comments | 20 Feb 19 14:27 UTC | HN request time: 1.243s | source
Show context
Fnoord ◴[20 Feb 19 15:35 UTC] 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 ◴[20 Feb 19 15:53 UTC] 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 #
1. Fnoord ◴[20 Feb 19 15:59 UTC] No.19208897[source]▶
On the 2 SIM cards I have (Vodafone NL and KPN NL) they don't throttle, as that's illegal, but the plans have data limits (after the limit they just disable 4G for you) and perhaps they do some QoS though. Public WiFi I mainly use Dutch railways (NS) in trains which uses T-Mobile NL. You (or well, anyone, AFAIK) cannot use that to watch on-demand movies though. But I just have that kind of material synced up locally. Same with audio (albeit through Spotify Premium). So with most of my video and audio synced up locally (and the same's true with regards to recent Nextcloud pictures) I end up with mainly traditional websites or apps or an OS/application update or so.

That being said, have you attempted to discuss the issue with them? Have you considered a non-default UDP port? Also, did you compare the usage with OpenVPN? I ran OpenVPN before, the roaming, network speed, and latency is quite terrible.

replies(2): >>19210360 #>>19210967 #
2. jeroenhd ◴[20 Feb 19 18:17 UTC] No.19210360[source]▶
In my experience, there are actually networks that throttle certain kinds of traffic. For example, on the WiFi on Blauwnet trains I can connect to my OpenVPN server but WireGuard just doesn't seem to make it through. I assume this is because of a combination of unknown ports + UDP + uncommon protocols.

I think the trick to bypass this kind of nonsense is to use port 443/1194/53 so QoS + firewall rules will still allow the VPN to pass through.

Haven't tested it yet, but in my experience non-default ports only make the problem worse. Most filtering/QoS services are pretty dumb and will just match source and destination ports; most firewalls will just plain ignore everything targeted at port 443 because the moment you start messing with HTTPS, you're in for a world of pain. Because WireGuard uses UDP, it's possible to listen on port 443 even if you're already hosting an HTTPS website. Sadly, you won't be able to use QUIC or HTTP3 if you do, but I don't think that's much of an issue these days.

replies(1): >>19210496 #
3. Fnoord ◴[20 Feb 19 18:26 UTC] No.19210496[source]▶
> Sadly, you won't be able to use QUIC or HTTP3 if you do, but I don't think that's much of an issue these days.

Should still be possible. Xs4all had port 80 set up so that if you'd SSH to it, you'd get connected to their shell while with a browser (the normal modus operandi) you'd end up on their website. It worked very well in some of the more oppressive regimes where traffic to port 22 was blocked.

I also don't serve HTTP(S) content on my home connection. I only host WireGuard, that's part of the point.

replies(1): >>19211281 #
4. alias_neo ◴[20 Feb 19 19:12 UTC] No.19210967[source]▶
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 haven't contacted EE about it or tested other VPNs yet. I want to run WireGuard for various reasons so switching to OpenVPN might confirm they issue but not solve my problems (I don't run the VPN for the reasons in the OP)

5. alias_neo ◴[20 Feb 19 19:43 UTC] No.19211281{3}[source]▶
Indeed this, I only host WireGuard and now you mention it, it'd only take me a second to switch the WireGuard port to 443 or something to test the port theory.