SSID Firewall Rule Stopped Filtering After a Wi-Fi Switch
An SSID-keyed firewall fails open when Android returns an unknown network name. Separate identity from enforcement and give unknown its own policy.
The rule was simple: filter traffic only while connected to the office Wi-Fi. It held for months, then one morning the phone sat on the same SSID with the same key icon and the filtering had stopped. Nothing about the network had changed; what changed was whether the app could see the network's name. On Android, "which Wi-Fi am I on" and "block this traffic" are two separate jobs, and a firewall that conflates them fails open exactly when the name becomes unavailable.
The symptom: identity disappears, policy follows
An SSID rule reads a value and then chooses a branch. When the read returns nothing useful, the code has to do something, and the common default is "not the expected network, so do not filter". That default turns a permission problem into a traffic leak. The key icon stays visible because the VPN service is still running; it is just enforcing a different branch.
Look at the order of events rather than the network. A permission prompt declined, a system update that moved SSID access behind a different permission, location services turned off, or a work profile policy change can all produce the same result while the phone stays on the same access point.
Why the name can come back unknown
WifiInfo.getSSID() returns the service-set identifier of the current network, and Android documents that access to location-sensitive fields depends on permission. When access is unavailable, the call returns UNKNOWN_SSID instead of failing loudly. An empty or unknown value is therefore not evidence that the phone left Wi-Fi; it is evidence that the app cannot classify the network.
Two checks separate the cases. Confirm the phone is associated and see what the system reports, then confirm the app actually holds the permission it needs on this Android release:
adb shell cmd wifi status
adb shell dumpsys package <your.app> | grep -i -E "ACCESS_FINE_LOCATION|NEARBY_WIFI_DEVICES"If the status line shows a connected network while the app sees an unknown name, you have a permission or API-level problem, not a Wi-Fi problem. Fix that before touching the firewall rules, because every rule downstream is being evaluated against a value the app cannot read.
Where the filtering actually runs
A local Android firewall normally uses the VpnService model without sending traffic to a remote server: it takes the virtual interface, applies its own rules and forwards what it allows. The platform permits one active VPN service per user profile, and a second one replaces the first rather than stacking with it. A separate firewall app and a separate work VPN therefore do not form a two-stage chain; one of them wins.
That matters for an SSID rule because the enforcement point and the observation point are different components. The VpnService decides what leaves the device; the Wi-Fi API only supplies a label. An app can enforce correctly and classify incorrectly, which is exactly the failure in this article.
Give unknown its own policy
Treat the network identity as having three states, and write down the policy for each before you ship the rule. The third state is the one that gets forgotten, and it is the one an attacker or a misconfiguration will put you in.
| Observation | Policy to specify |
|---|---|
| Expected SSID is readable | The explicit filtering policy you designed |
| A different SSID is readable | The default policy for untrusted networks |
| Unknown, changing or unreadable | Fail closed until classification is reliable |
Fail closed means the unknown state inherits the strictest sensible policy rather than the most convenient one. If that makes the phone unusable on a new network, the right fix is a deliberate, visible exception, not a silent trust decision hidden in a null check.
A familiar SSID is a label, not proof of the network operator. Anyone can run an access point with the office name, so a name match should never be the only thing standing between a sensitive session and an untrusted segment.
Test the transitions, not the steady state
Steady-state testing passes on the network where you built the rule. The failures live in transitions: permission denied, Wi-Fi to cellular, one SSID to another, the VPN service restarted, and another VPN app taking over the interface. For each, decide whether existing connections are reconsidered and whether protected traffic stays blocked while the state is unknown.
Write the result as three sentences: the observed condition, the component that enforces the decision, and the deliberate fallback. If any of the three is missing, the rule is not a policy yet, it is a guess that happens to work on the office network.