"Only Control IPv6 Chains" behaves as exclusive toggle instead of additive — breaks per-app IPv4 rules when enabled (Android 17)
Environment:
Device: Google Pixel 8
Android version: 17
Root method: Magisk 30.7 (30700)
AFWall+ version: 4.0.3
iptables mode: System iptables
Description:
When both "IPv6 support" and "Only Control IPv6 Chains" are enabled simultaneously, the app appears to switch to managing only IPv6 chains and stops enforcing the existing IPv4 per-app rules, rather than additively managing both IPv4 and IPv6 chains in parallel.
Steps to reproduce:
Enable "IPv6 support"
Leave "Only Control IPv6 Chains" unchecked → INPUT/OUTPUT/FORWARD (IPv6) toggles remain grayed out / non-editable, OUTPUT (IPv6) stuck on "BLOCKED"
Enable "Only Control IPv6 Chains" → IPv6 chain toggles become editable, but previously configured per-app IPv4 rules stop being enforced
Disable "Only Control IPv6 Chains" again → reverts to step 2 state (IPv6 OUTPUT permanently blocked, non-editable)
Expected behavior:
Both IPv4 and IPv6 chains should be independently configurable and enforced simultaneously, allowing per-app rules on both protocols without one disabling the other.
Actual behavior:
The two checkboxes act as a mutually exclusive protocol selector rather than additive controls. This results in either:
IPv6 OUTPUT permanently blocked for all apps (uncontrollable), or
IPv4 per-app rules being ignored while IPv6 is controllable
Impact:
This causes apps relying on IPv6-routed traffic (e.g., Google Play Services / DroidGuard attestation calls) to fail intermittently or be entirely blocked regardless of per-app allow rules, since IPv6 OUTPUT defaults to blocked and cannot be changed without sacrificing IPv4 control.
Additional notes:
This behavior was not present on Android 16 with the same AFWall+ version/config — suggests a possible regression tied to networking stack changes in Android 17 rather than a config error on the user side.
Additional issue: "Built-in" iptables binary breaks all connectivity
Separately, switching the iptables binary preference from "System" to "Built-in" (AFWall+'s bundled binary) causes a complete loss of internet connectivity for all apps, system-wide, regardless of any configured rules. Reverting to "System" iptables restores connectivity immediately.
This suggests the bundled iptables binary may be incompatible with the Android 17 kernel (possible causes: kernel built without legacy iptables support / nftables-only kernel, missing netfilter modules the built-in binary expects, or architecture mismatch). Would be useful to know if this is a known limitation on newer GKI kernels, or if there's a way to get diagnostic output from the built-in binary's failure.
Steps to reproduce:
Go to Preferences → set iptables binary to "Built-in"
Apply/save
All network access is immediately lost for all apps
Revert to "System" → connectivity restored
"Only Control IPv6 Chains" behaves as exclusive toggle instead of additive — breaks per-app IPv4 rules when enabled (Android 17)
Environment:
Device: Google Pixel 8
Android version: 17
Root method: Magisk 30.7 (30700)
AFWall+ version: 4.0.3
iptables mode: System iptables
Description:
When both "IPv6 support" and "Only Control IPv6 Chains" are enabled simultaneously, the app appears to switch to managing only IPv6 chains and stops enforcing the existing IPv4 per-app rules, rather than additively managing both IPv4 and IPv6 chains in parallel.
Steps to reproduce:
Enable "IPv6 support"
Leave "Only Control IPv6 Chains" unchecked → INPUT/OUTPUT/FORWARD (IPv6) toggles remain grayed out / non-editable, OUTPUT (IPv6) stuck on "BLOCKED"
Enable "Only Control IPv6 Chains" → IPv6 chain toggles become editable, but previously configured per-app IPv4 rules stop being enforced
Disable "Only Control IPv6 Chains" again → reverts to step 2 state (IPv6 OUTPUT permanently blocked, non-editable)
Expected behavior:
Both IPv4 and IPv6 chains should be independently configurable and enforced simultaneously, allowing per-app rules on both protocols without one disabling the other.
Actual behavior:
The two checkboxes act as a mutually exclusive protocol selector rather than additive controls. This results in either:
IPv6 OUTPUT permanently blocked for all apps (uncontrollable), or
IPv4 per-app rules being ignored while IPv6 is controllable
Impact:
This causes apps relying on IPv6-routed traffic (e.g., Google Play Services / DroidGuard attestation calls) to fail intermittently or be entirely blocked regardless of per-app allow rules, since IPv6 OUTPUT defaults to blocked and cannot be changed without sacrificing IPv4 control.
Additional notes:
This behavior was not present on Android 16 with the same AFWall+ version/config — suggests a possible regression tied to networking stack changes in Android 17 rather than a config error on the user side.
Additional issue: "Built-in" iptables binary breaks all connectivity
Separately, switching the iptables binary preference from "System" to "Built-in" (AFWall+'s bundled binary) causes a complete loss of internet connectivity for all apps, system-wide, regardless of any configured rules. Reverting to "System" iptables restores connectivity immediately.
This suggests the bundled iptables binary may be incompatible with the Android 17 kernel (possible causes: kernel built without legacy iptables support / nftables-only kernel, missing netfilter modules the built-in binary expects, or architecture mismatch). Would be useful to know if this is a known limitation on newer GKI kernels, or if there's a way to get diagnostic output from the built-in binary's failure.
Steps to reproduce:
Go to Preferences → set iptables binary to "Built-in"
Apply/save
All network access is immediately lost for all apps
Revert to "System" → connectivity restored