AFWall+ Review: An iptables Firewall for Rooted Android

What AFWall+ Solves That Android Permissions Cannot

Standard Android permissions are binary and permanent. An app either has the INTERNET permission or it does not, and once granted, the user cannot limit that app to WiFi only or block it from reaching the network in the background. AFWall+ exists to fill that gap. It is a firewall application for rooted Android devices, built on the Linux iptables framework, and its stated purpose is to block unwanted network access by apps even when those apps hold internet permission. The README lists the intended outcomes directly: prevent data leaks and unauthorized background connections, monitor network activity, save battery and data, and block tracking and analytics by cutting off the connections those trackers need.

The audience is narrow by design. Root access is required, and the README says plainly that without root there is no functionality. That means the project is aimed at users running Magisk, LineageOS built-in su, or the legacy SuperSU, on devices where the bootloader has already been unlocked. It is not a consumer privacy app for stock phones. The README also draws two boundaries that matter for expectations: AFWall+ is not an antivirus and does not scan files for malware, and it is not an ad blocker, because it blocks network access rather than ads inside connections it has allowed.

How the iptables Rule Chain Intercepts Traffic

AFWall+ does not sit in the network stack as a proxy or a VPN service. According to the README, it operates at the Linux kernel level using iptables rules, and the mechanism is described as intercepting network requests before they leave the device, applying custom rules, allowing or blocking per app and per network type, and logging blocked attempts. Because enforcement happens in the kernel, an app cannot route around it by using a different HTTP library or by ignoring Android's permission model.

The rule structure is visible in the naming. The README's custom rule examples write into chains named `afwall-wifi`, which tells you the firewall maintains separate chains per network interface class. That is how the same app can be allowed on WiFi and blocked on mobile data. The supported network types listed are mobile data including roaming detection, WiFi, VPN, tethering over WiFi hotspot, USB and Bluetooth, Tor, and LAN.

Two advanced features follow from this architecture. Boot protection applies rules before apps start, which closes the window during boot when connections would otherwise escape. Startup delay management exists because applying rules too early can conflict with the system coming up. Both are configuration knobs the user has to tune. The README also warns of VPN conflicts, where some VPN apps may interfere with firewall rules, and notes that some system processes with root access may bypass rules entirely. That last point is a real hole in the model: root is both the requirement and the escape hatch.

Installing AFWall+ and Applying Your First Rule Set

The README does not give a source build walkthrough for end users. It points to three distribution channels: Google Play under `dev.ukanth.ufirewall`, F-Droid under the same package name, and the GitHub releases page. The repository does contain `build-binaries.sh`, `Android.mk`, `build.gradle` and a `binaries/` directory, so a source build is possible, but the README's quick start assumes you install a prebuilt package and then grant root.

Before installing, confirm that root actually works. The README gives this check and says it should return uid=0:

su -c "id"
# Should return: uid=0(root) gid=0(root)

If that command does not return a root uid, stop. Every feature in the app depends on it.

After installing from your chosen source, the README's quick start is four steps: grant root permission when prompted, enable the firewall with the toggle on the main screen, configure apps by tapping them to allow WiFi or mobile data, then apply the rules with the apply button. The order matters. Tapping apps only edits a pending rule set; nothing is enforced until you apply.

For advanced users, AFWall+ accepts custom iptables rules. The README shows two examples, one allowing a subnet and one blocking a port:

# Example: Allow specific IP range
-A afwall-wifi -d 192.168.1.0/24 -j ACCEPT

# Example: Block specific port
-A afwal

The second example is truncated in the README as published. Do not guess at the remainder. If you need port-level rules, read the full custom rules documentation in the repository before writing them, because a malformed rule in a firewall chain can leave you without connectivity until you disable the firewall from recovery.

Where AFWall+ Breaks Down

The most serious limitation is structural: root access is required and there is no fallback. On an unrooted phone the app has no functionality at all, per the README. That rules out most devices sold in the last several years, where unlocking is either unsupported by the vendor or voids warranty and breaks banking and DRM apps.

The second limitation is the bypass problem. The README states that some system processes may bypass rules if they have root access. A firewall that cannot see traffic from the most privileged processes on the device is not a complete boundary. If your threat model includes a compromised system component, AFWall+ does not close that door.

VPN conflicts are the third. The README warns that some VPN apps may interfere with firewall rules, without naming which ones or describing the failure mode. That is thin documentation for a combination many privacy-focused users will run, since a firewall and a VPN are often deployed together. Expect to test your specific VPN rather than trust a compatibility list, because none is provided.

Finally, the boot sequence is a genuine failure mode. Boot protection and startup delay exist precisely because rules applied at the wrong moment can conflict with system startup. If you misconfigure the delay or write a rule that blocks the wrong interface, the practical result can be a device that boots without network access. The README does not document a recovery procedure for that state.

AFWall+ vs NetGuard: Kernel Rules Against a Local VPN

The obvious alternative is NetGuard, which users search for alongside AFWall+ directly. The difference is architectural, not cosmetic. NetGuard filters traffic through Android's VPN service API, which means it works without root but only by routing traffic through a local VPN interface. AFWall+ does the opposite: it requires root and enforces rules in the kernel with iptables, with no VPN slot consumed.

That trade-off cuts both ways. NetGuard's approach means no root requirement, so it runs on stock devices, but it occupies the single VPN slot Android allows, which conflicts with any real VPN you want to run at the same time. AFWall+'s approach leaves the VPN slot free and enforces rules below the app layer, but it is useless on an unrooted phone and, per the README, can itself conflict with VPN apps. Neither is strictly better. If you cannot root, NetGuard is the only one of the two that will do anything. If you must run a VPN and want the firewall beneath it, AFWall+ is the one that does not compete for the same interface.

A second class of alternative is the custom ROM route: some LineageOS builds ship with built-in su, which the README lists as a supported root method, and per-app network restriction can sometimes be approximated through ROM-level privacy controls. Those controls are coarser than iptables chains and are not portable across ROMs.

Maintenance, Licensing and Upgrade Cost

The repository is not archived, and the last push was on 2026-08-06, the same day as the v4.1.0 release. The prior releases, v4.0.3 and v4.0.2, landed in March and February 2026, so the release cadence over the last several months has been steady rather than dormant. This is a volunteer project; the README states that AFWall+ is developed and maintained by volunteers and asks for donations and translation help through Crowdin.

Upgrade cost is low in the ordinary case. Installing a new APK over the old one preserves rules, and the README points to Changelog.md for what changed in each version. The real cost is version compatibility. The README claims Android 5.0 (API 21) through 14+, with legacy builds for older systems: version 2.9.9 for Android 4.x and version 1.3.4.1 for Android 2.x. Those legacy builds are frozen at old releases, so anyone on Android 4.x or older is not receiving the v4.x line at all.

The licence is GPL-3.0. For end users that changes nothing. For anyone embedding AFWall+ in a product or shipping a modified build, GPL-3.0 carries source disclosure obligations, and the repository also contains `playstore/` and `binaries/` directories that suggest a build and distribution pipeline worth reading before you fork. This is a description of the licence, not legal advice; consult a lawyer for your specific distribution.

Editorial conclusion

AFWall+ suits rooted Android users who want per-app control over WiFi, mobile data, VPN and tethering traffic and who accept that a bad rule set can cut off their own connectivity. It is the wrong tool for unrooted devices, for anyone expecting an antivirus or ad blocker, and for users who cannot recover from a boot-time rule mistake. Before relying on it, verify that `su -c "id"` returns uid=0 on your device, check that your root method is Magisk or LineageOS su rather than KingRoot, and read Changelog.md for the v4.1.0 changes since your installed version.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. ukanth/afwall on GitHub