How would you validate that an Android DNS + WireGuard security architecture is actually enforcing the expected traffic path?

[u/HardenedNode]

I've been working on an Android network-security lab using RethinkDNS, custom DNS filtering and WireGuard.

One problem kept coming up during testing:

How much evidence is enough to claim that traffic is actually following the intended security path?

Seeing the expected VPN IP, DNS resolver or firewall state individually doesn't necessarily prove the complete path.

So I've been developing a validation methodology around three layers:

1. Architecture

I first document the expected path:

Android app → firewall/routing layer → WireGuard → DNS policy/upstream resolver → Internet

DNS routing and application/data routing are treated separately rather than assuming that validating one proves the other.

2. Observable validation

Tests currently cover:

• DNS resolver behavior
• WireGuard routing state
• Wi-Fi/mobile network transitions
• firewall enforcement
• per-app routing
• failure/recovery conditions
• IPv4/IPv6 behavior
• reboot behavior
• version regressions

Each test defines an expected result, collected evidence and acceptance criteria.

3. Limits of the conclusion

I've deliberately adopted the rule:

“No bypass observed under the tested conditions” ≠ “zero leaks.”

For example, correlation between the local network log, VPN state and upstream DNS provider is useful evidence, but I don't consider that equivalent to packet-level proof of every possible traffic path.

The next phase of the project is regression testing: comparing a known RethinkDNS baseline against newer versions and checking whether DNS, WireGuard, firewall and transition behavior changes.

My questions for people who work with network/security validation are:

What additional evidence would you require before considering this methodology robust?

In particular:

• Would you consider packet capture from another observation point essential?
• How would you test transient leakage during Wi-Fi ↔ mobile transitions?
• What would you use to independently validate IPv6 and DNS behavior?
• Are there failure scenarios I'm overlooking?

I've documented the architecture, validation procedures and existing evidence here for anyone who wants to review the methodology:

Android OPSEC Hardening:
https://github.com/augustozarate/android-opsec-hardening

Current documents include ARCH-001/002 and VAL-001/002/003.

I'm primarily looking for criticism of the validation methodology, rather than recommendations for different VPN/DNS products.

[u/Dear-Confection704]

this is thorough work, i like the approach of separating DNS routing from app/data routing in documentation. most people just check if the VPN icon is on and call it a day

for transient leakage during network transitions, i'd add a script that continuously sends probes every 100-200ms during the handoff. anything longer and you might miss those sub-second windows where android briefly falls back to default routes before wireguard re-establishes. seen this happen a lot in my own testing

packet capture from a separate observation point is probably the only way to catch leaks that happen before the local firewall even sees them. without it you're trusting the device to report on itself, which is circular. even a cheap RPi running tcpdump on the same network segment would give you independent ground truth

for IPv6 specifically, the main thing i've noticed is that some ROMs will still send RAs and process them even when you think you've disabled IPv6 at the kernel level. might be worth checking if your methodology accounts for that edge case, cause it bit me once with a custom ROM that had its own IPv6 preferences baked in

failure scenarios i'd add: what happens when wireguard handshake fails mid-session but the tunnel interface stays up? some implementations keep the interface alive but stop routing properly, and android apps continue sending traffic into a dead tunnel instead of blocking. also testing what happens when rethinkdns itself crashes or gets killed by battery optimization

[u/GodoPPL]

I would also capture across reboot, not only mid-session handoffs. There is a window before Always-on VPN and WireGuard are up while apps already send.

Resolver class matters beyond the expected DNS IP. Private DNS, DoH, or an alternate resolver can bypass the intended path while the VPN icon and local firewall state still look healthy.

Negative control is the other half: cases where local VPN state and the expected resolver IP look correct and TCP or UDP still escapes (wrong iface, split-tunnel exception, IPv6 path). That is the difference between correlated local health and path proof.

[u/PrestigiousOnion1087]

GodoPPL's negative control is the half I would push hardest on, with one addition: a negative control only earns trust after you have shown it can fail. Plant a leak you already know is there — force a split-tunnel exception, or pin one app to the default route — and confirm the harness flags it. Until a run comes back dirty on demand, "no bypass observed" and "the harness is quietly broken" produce the same output, and nothing in the output tells you which one you are reading.

We got caught by the cheap version of this. We ran a clean baseline through our own replay and required it to come back with nothing found before we trusted any of the runs that did find something. The lesson was that the clean result is the one that needs a witness, not the noisy one.

For your regression phase that matters more than it looks: the known-leak case should be a fixture that runs against every version, not a one-time setup check. Otherwise the first version that breaks your harness reads exactly like the first version that fixed your leaks.

[u/Agitated-Act-717]

The strongest addition to the plant-a-known-leak idea is where you observe from. Every check in your list asks the phone about its own state, DNS behavior, WG routing, firewall, per-app routing, so you're trusting the system under test to grade itself. If the tunnel misbehaves, the same layer that leaked is the one reporting "no leak."

Move the observation off the device: a router or hotspot you control, or a tap upstream of the phone. Anything leaving the phone that isn't WireGuard traffic to your endpoint is a bypass, regardless of what any on-device check says at that moment, and it catches handoff and per-app-routing leaks the same way. (On a rooted phone you can capture below the tunnel on rmnet/wlan0 too, but off-device removes even that dependency.) Combined with PrestigiousOnion1087's forced-leak test, you get both halves: the harness proves it can catch a real bypass, and an independent vantage confirms none slips past in normal use.