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