u/nerdy_oreo

This post contains content not supported on old Reddit. Click here to view the full post

This post contains content not supported on old Reddit. Click here to view the full post

Two Tailscale things worth discussing, one a genuine footgun I lost time to.

The footgun: exit-node clients ignore your tailnet DNS settings. I run an exit node so roaming devices get my full filtering + VPN stack from anywhere. What I didn't know: exit-node clients ignore the tailnet Global DNS and Override settings entirely (this is by design, confirmed in Tailscale issues #8237 and #5875). Client DNS gets delegated to the exit node's own host resolv.conf, not the admin-console DNS you configured. The iOS "Using Tailscale DNS" checkmark is cosmetic in this mode.

The result: my exit node's resolv.conf was pointed at the wrong place, so every roaming device resolved via my upstream VPN's DNS and fully bypassed my Pi-hole. Ads served everywhere, and the admin console said everything was fine. The fix was pointing the exit node host's resolv.conf directly at my Pi-hole, plus a policy-routing rule so the node's own tailnet-sourced traffic reached peers correctly. Only after both did filtering actually apply to roaming clients.

The design: chaining. My exit node isn't the internet egress itself. It sits in front of a self-hosted WireGuard gateway to a commercial VPN, so the path is device -> Tailscale exit node -> self-hosted WireGuard -> VPN. That gets me identical egress and filtering on cellular as I have at home, without putting the VPN app on every device.

Discussion: has the exit-node DNS delegation bitten anyone else, and how did you verify your roaming clients are actually using the resolver you think? And for the chainers, are you nesting an exit node into another tunnel like this, or keeping Tailscale purely for mesh and handling egress separately? Interested in where the chaining approach breaks down for people.

Built a WireGuard container as a network gateway to a commercial VPN, and two design decisions turned out to matter far more than the tunnel config itself. Curious how others resolved them.

1. Fail-open vs fail-closed. When the handshake goes stale, should the gateway fail closed (clients lose internet until the tunnel recovers) or fail open (clients drop to direct egress, stay online, lose the VPN)? I built a watchdog that checks handshake age every minute, fails over to a secondary endpoint first, and only if that also fails adds a direct default route as a last resort. So: fail-open, but with endpoint failover ahead of it. For my threat model that's correct, a dead connection at home causes more harm than brief unprotected egress. I know a chunk of this sub will disagree, and I want to hear the fail-closed argument made well.

2. Don't MASQUERADE your whole LAN into the tunnel. The trap I see constantly: a blanket masquerade with no split logic, which shoves inter-VLAN and local traffic through the VPN indiscriminately and wrecks latency and reachability. What actually worked:

• Destination-based local bypass so RFC1918 and CGNAT ranges route direct, never into wg0
• Static inter-VLAN routes kept in both the main and tunnel tables
• The VPN endpoint IPs themselves bypassed to eth0 to prevent a routing loop
• TCPMSS --set-mss 1380 on FORWARD to kill the PMTU black-hole symptoms
• Only one VLAN's client traffic actually policy-routed into the tunnel; everything else egresses direct

Questions: how are you handling tunnel-down behavior, and do you do endpoint failover or just accept the drop? And for the split-tunnel crowd, are you doing destination-based bypass like this or policy routing by source, and where has each bitten you?

I have Read the Rules. So, threat model first, per rule 6, and I want it torn apart rather than praised.

Adversary: commercial surveillance. Ad-tech, data brokers, and platform profiling whose business is aggregating behavioral and identity data across sources and selling it. Their advantage is correlation at scale and persistence over time, not a targeted attack on me.

Explicitly out of scope: nation-state adversaries, physical access or coercion, and anyone who already knows my real identity and is hunting me specifically. If a state actor targets me by name, nothing here saves me, and designing for that would be wasted effort against my actual risk.

Assets, in priority order:

1. My identity graph. The links that let a broker join my browsing, purchases, and accounts back to one real person.
2. My communications content and metadata.
3. My data at rest.

What a broker needs to win: a stable identifier (IP, email, device fingerprint, logged-in account) that persists across contexts so separate data points collapse into one profile. So my entire design is aimed at denying stable cross-context identifiers, not at "being encrypted."

Controls, each justified against that specific adversary:

• Rotating/shared network egress. A residential IP is a durable identifier a broker can pin activity to over months. Routing egress through a shared commercial VPN endpoint (account paid so it isn't tied to my identity) means my traffic shares an IP with thousands of others, breaking IP as a correlation key. This is aimed squarely at the "stable identifier" problem, not at hiding content, which is already TLS-encrypted.
• Self-hosted resolver with local filtering, DNS kept off the VPN's own resolver. DNS query streams are a behavioral fingerprint and a data source brokers buy. Running my own resolver over encrypted transport denies that stream to third parties. Critical detail: I keep DNS from being silently handed to the VPN provider's resolver, because that just swaps one data-collecting party for another. The point is that no single party sees my full query history.
• Anti-fingerprinting browser for sensitive sessions. Browser fingerprinting is the identifier that survives IP rotation and cookie clearing, so it is arguably the highest-value target against this adversary. A browser designed to present a common fingerprint attacks correlation at the layer the VPN can't touch.
• Account compartmentalization and aliasing. Email aliases and separated accounts prevent one address from acting as the join key that unifies profiles across services. This is the boring, unglamorous control I suspect matters most.
• Custom-domain mail, provider outside the US ad ecosystem. Removes my mail content and social graph from a provider whose model is monetizing it, and the custom domain means switching providers later doesn't reset my identifier.
• Hardware-key 2FA. Primarily an account-takeover control. I'll be honest that this is only loosely coupled to the broker threat model and is here for a different reason.

The questions I actually want pressure-tested:

1. Against correlation-at-scale specifically, I believe the ranking of impact is: fingerprinting resistance and account compartmentalization at the top, network egress rotation in the middle, and everything else marginal. My suspicion is the VPN is the flashiest and least impactful layer while the boring identity-hygiene work does the real correlation-breaking. Is that ranking wrong?
2. Which of these are theater against a data broker? I'd rather cut two low-value controls than add five.
3. Where is the threat model itself naive? Specifically, am I underweighting metadata and purchase-data brokers that never touch my network at all, where none of these network controls help?

Most de-Google posts are victory laps. I want the honest version, because the failures taught me more than the wins.

What stuck with zero regret:

• Search Google -> DuckDuckGo. Instant, never looked back.
• Mail Gmail -> Tuta on a custom domain. The custom domain is the real unlock, because it means I can leave Tuta later without changing my address again.
• Browser Chrome -> hardened Firefox-based setup + Mullvad Browser for anything I want anti-fingerprinting.
• OS Windows -> Arch on my daily driver.
• Passwords / 2FA -> Bitwarden + YubiKeys and Ente Auth.

What I gave up on, and the pattern behind it:

Every failed swap failed because of other people, not the tool. Chat is the clearest example. Signal works for the friends who'll install it, but family flatly would not leave iMessage, so I stopped fighting it and accepted a split. Trying to move a whole family off a default is a social problem wearing a technical costume, and I lost that fight more than once.

So my actual question for this sub: which of your swaps survived contact with daily life, and which ones did you roll back? And when they failed, was it the alternative that let you down, or the people around you who wouldn't move? I think we'd all calibrate better if we talked about the abandoned swaps as openly as the successful ones.

Ran into this the hard way and I keep seeing others make the same assumption, so I want to both flag it and hear how people handle it.

The assumption: routing your resolver through your VPN tunnel is "more private." The reality with Mullvad and most WireGuard VPNs is that port 53 gets hijacked in-tunnel. So if your Unbound is doing recursion inside the tunnel, it silently breaks and resolution quietly falls back to the VPN provider's own resolver. Pi-hole still shows queries, everything looks fine, but your carefully built chain is bypassed and you're using their DNS.

What actually worked for me: Pi-hole -> self-hosted Unbound -> DoT to an encrypted upstream, with direct egress, never through the tunnel. Still encrypted end to end, but the resolver path stays under my control and my Pi-hole filtering actually applies. The VPN only carries the traffic that's supposed to be in it.

That leaves me with a design question I keep going back and forth on, and I'd like other people's take:

Unbound as a recursive resolver vs Unbound forwarding over DoT to an upstream. Full recursion is the "purest" answer and talks to root servers directly, but it can't live inside the tunnel for the reason above, and it leaks a different metadata pattern to authoritatives. DoT-forwarding hands trust to one upstream but is clean, fast, and encrypted. I went DoT-forward. Where did you land, and why? And has anyone found a clean way to keep true recursion while still getting VPN egress for the rest of the network?

Most "I de-Googled" posts show the wins. I'm more interested in the honest version: the swaps that survived contact with daily life vs the ones you rolled back because they were too painful, broke something, or nobody around you would cooperate.

For me the ones that stuck:

• Search Google -> DuckDuckGo, never looked back
• Mail Gmail -> Tuta on a custom domain
• Browser Chrome -> hardened Zen + Mullvad Browser
• VPN -> Mullvad, self-hosted on my own gateway
• Passwords / 2FA -> Bitwarden, YubiKeys + Ente Auth
• OS Windows -> Arch

And the honest friction: Chat is where privacy meets other people's willingness. Signal works for some of my circle, but family flatly would not leave iMessage, so I stopped fighting it. That compromise taught me more than any tool did.

So what stuck for you and what didn't? Especially interested in the swaps you abandoned, and whether the reason was the tool or the people around you. I think the failures are more useful to talk about than the wins.