There is also Net Policy way of using Firewall, which works for ADB/Root users.
Net policy allows a user to configure certain networking behaviour of an app without modifying the ip tables directly and/or running a firewall app.
And new Berkeley Packet Filter (BPF) method.
relevant part
IP tables based blocking and VPN-based packet filtering remain the most used filtering technology in Android due to the availability of many open source firewall tools (and closed source ones most of which are just clones of the former). However, these sort of blocking, as I’ve argued before, are not very effective, and from Android 12, their effectiveness has been further reduced. This has happened because Android 12 has integrated eBPF (extended BPF), and since then the internals of the AOSP has been modified to use eBPF instead of the traditional IP tables approach. If you don’t know about BPF, let me explain it in simple words: BPF is a kernel-level packet filtering mechanism that has the ability to decide which packet (any data transmitted from or to the internet has to go through a few layers, packet is one of them) goes to where or which packets it needs to drop. This allows a system whitelisted program in Android to directly send/receive packets without going through the typical route used by ip tables or VPNs. This means that the vendor can arbitrarily allow their vendor (and system) apps to bypass ip tables and VPNs which is not good thing for user privacy since for these applications, all the protections (for example, anti-censorship protections) become useless. This is where the BPF rules may help. The underlying implementation of the above mentioned command modifies the BFP map albeit temporarily overriding the existing UID rules if already present. This effectively allows us to temporarily override the rules even for the whitelisted apps. But in some cases, the rules may be refreshed even without a reboot. I’m still currently investing the implementation, so I don’t have the exact details.
The last , Karma runs on my actual old phone whiteout problems.
Using for actual OS gif ,s the info, that is bild for older OS, maybe will not work as expected
So, maybe not working for a firewall it,s not a good base. So I wrote a mail to Mister Karma, how is that’s working whif actual OS … never listen an answer. Don’t like that.
The last option to use this new concept of firewall i don’t understand.
How I bring this to running ?
cmd connectivity set-chain3-enab
Just that command at the terminal and that,s it ?
Sorry for this strange English, it,s not my language.
IDK I’m not from CS background I’ll wait for Muntashir’s investigation and proper implementation.
Maybe @SkewedZeppelin or @ignoramous has more knowledge about it.
You need either Magisk or KernelSu or Apatch. Lineage does not provide root, except for adb root, which is not enough.
In addition, firewall in Lineage is policy based. Afwall is based on Iptables. Lineage firewall cannot restrict System applications. Nor can it touch System processes. Afwall can.
Non-root firewalls create overhead on your device. They re-route all Internet traffic through their server where restrictions are set or run a server on your device. Such apps must run all the time wasting resources and battery. Afwall runs only when set and when you switch between Wifi and Mobile data. It changes iptables in kernel according to your settings.
No, it can’t. NetGuard is worse at this as it does not yet support “VPN Lockdown” mode (“Block connections without VPN” mode) which prevents installed apps from bypassing the VPN, let alone System apps.
As for System apps, none of the userspace VPN apps can prevent a bypass. The OS itself and System apps can bypass VPN, at will. This is how “connectivity checks” (to detect captive portal) are done by the OS anyway.
There very well could be many such bypasses in the Android builds popular OEMs ship (which are usually not open source to be readily auditable like vanilla AOSP is).