[5.0+][ROOT][3.5.2] AFWall+ IPTables Firewall [16 May 2021]

[n0j0e]

Is the AFWall v3.5.3 beta stable enough to use it for daily?

 

[IronTechmonkey]

Is the AFWall v3.5.3 beta stable enough to use it for daily?

Keeping in mind that different usage cases may yield different results, AFWall v3.5.3 beta from Play Store has been running fine for me on 2 devices: stock Moto Android 10 and stock Moto Android 11 (both rooted with Magisk).

 

[n0j0e]

I'm running DerpFest AOSP A12.1 with a custom Private DNS. Any problems or runs fine with this beta?

 

[IronTechmonkey]

I'm running DerpFest AOSP A12.1 with a custom Private DNS. Any problems or runs fine with this beta?

Run beta & report observed issues. That's what betas are for.

 

[n0j0e]

Run beta & report observed issues. That's what betas are for.

Sure but if anyone here already running beta 3.5.3 fine (or not) with this specs many other users didn't waste time with testing..mostly i test things by my self but sometimes i have no time/fun to do it.

Also it seems i need to buy the unlocker for using the AFWall+ beta. Without i can't import my exported settings/rules from AFWall Donate! So it is not an option for me at the moment.

 

[IronTechmonkey]

Sure but if anyone here already running beta 3.5.3 fine (or not) with this specs many other users didn't waste time with testing..mostly i test things by my self but sometimes i have no time/fun to do it.

Well, the point of development threads such as this is to test rather than to ask for opinions about how it's working. Fair enough that you don't have time to test but it sounds like you know your way around well enough to review recent thread pages for issues. I could not speak for Android 12 but in 10 and 11 it seems good. Fortunately, in this thread there's not a lot of fluff so within five or so pages you can get a good idea. Then there is the GitHub page.

Also it seems i need to buy the unlocker for using the AFWall+ beta. Without i can't import my exported settings/rules from AFWall Donate! So it is not an option for me at the moment.

That's weird. I would have assumed that the beta did not require the unlocker. I have afwall+ beta and unlocker from Play Store installed but might be able to test without unlocker later or tomorrow.

Also, are you signed up for the afwall beta at Play Store and attempting to get it from there or manually installing it from another source?

 

[n0j0e]

Beta from Play Store without uninstalling the donation version. Maybe this is the culprit.

 

[IronTechmonkey]

Beta from Play Store without uninstalling the donation version. Maybe this is the culprit.

If Play Store sees you have the beta of the app and the Unlocker installed then that's the same as what I'm running which implies other factors, and one other difference is the Android version.
Odd..

 

[n0j0e]

Normally beta apps are replacing/updating the stable apps in Play Store..

 

[nutzfreelance]

im having a strange issue

i was having issues with an app accessing wifi because captive portal was blocked
so i disabled it in android 11

My firewall (afwall)recognizes the network attempt to connect but not as tutanota uid 10259 but as unknown uid -100 trying to connect to 81.3.6.164:443 among other addresses.

Tutanota logs in, it pings to let me know i have new mail, it tells me i have 2 new messages in the side bar, but it thinks it is offline (because i block the unknown app uid-100 from the Internet i assume) and it can't show me the messages.

It seems if i turn off captive portal the app will not connect (because it tries to connect an a unknown app uid -100 which is blocked)
If i turn ON captive portal (and wifi thinks there is no internet because of the fire wall) it WILL connect via the tutanota app uid (which is allowed by the firewall). Which seems completely backward

if i enable internet access to uid 1073 (netwrok manager,cell broadcast service, tethering, com.android.server.networkpermissionconfig) then every works it should.

this is not just a tutanota issue, fdroid classic acts the same, maybe some other apps

i dont have the issue on my pixel 6 android 12l
I don't have the issue on my pixel 6 with Android 12l
i do have this issue with lineageOS 19.1

 

[mmm4m5m]

I am wondering why the rules are different with Android 9 (stock ROM) and Android 11 (lineageOS). Looks like it works fine in both cases - blocking, allowing. Here example:

( If you wonder why I have 2 firewalls - just in case )

 

[ukanth]

Hello all,

Hope all are doing fine. I was out for past couple of months due to my surgery. I'm still recovering from it. Here is the latest BETA version to add support for Android 12+

I have not tested it on Android 13. I will try to do it this week.

AFWall_3.5.3_BETA2.apk

Shared with Dropbox

www.dropbox.com

Kindly raise the issue on github (existing or new one)

 

[temporarium]

Hello all,

Hope all are doing fine. I was out for past couple of months due to my surgery. I'm still recovering from it. Here is the latest BETA version to add support for Android 12+

I have not tested it on Android 13. I will try to do it this week.

AFWall_3.5.3_BETA2.apk

Shared with Dropbox

www.dropbox.com

Kindly raise the issue on github (existing or new one)

Get well soon!

 

[User_99]

ukanth, all the best.

 

[Utini]

guys i have read the past few pages about dns but can't find an answers,

Afwall is blocking the new private dns feature of android 9 pie, the dns traffic is reported as "(root) Apps running as root", port 853 TCP

can i easily open that tcp port 853 for DNS over TLS without allowing the whole "Apps running as root"? thanks !

Did anyone find a fix for this yet? I am also getting requests from "apps running as root" for port 853 and privatedns wont work.

Android 12, Pixel 6 Pro

 

[eriol1]

Did anyone find a fix for this yet? I am also getting requests from "apps running as root" for port 853 and privatedns wont work.

Android 12, Pixel 6 Pro

Search this thread for 853, you'll find many people who solved exactly this using a custom script

 

[Utini]

Search this thread for 853, you'll find many people who solved exactly this using a custom script

Oh good idea. This thread came up with this:

IPTABLES=/system/bin/iptables
$IPTABLES -I "afwall" -p tcp --dport 853 -j ACCEPT

But I guess the following version seems better as it will be a bit more restrictive but enough for what I need?

iptables -I afwall -p tcp --dport 853 -d 1dot1dot1dot1.cloudflare-dns.com,1.1.1.1,1.0.0.1,8.8.8.8,8.8.4.4 -m owner --uid-owner root -j ACCEPT

 

[eriol1]

Oh good idea. This thread came up with this:



But I guess the following version seems better as it will be a bit more restrictive but enough for what I need?

Yep. Looks like you have a good grasp on things

 

[Utini]

Alright, so setting a "dns" in the rule didn't work. It has to be the IP. But that is fine.

In "Set Custom Script" I now have this:

iptables -I afwall -p tcp --dport 853 -d 1.1.1.1,1.0.0.1,8.8.8.8,8.8.4.4 -m owner --uid-owner root -j ACCEPT

I do not have any "shutdown custom script". I guess that is fine?

Also, is my rule the preferred method of setting a custom script or should I use it like this (or does it not matter at all):

IPTABLES=/system/bin/iptables
$IPTABLES -A "afwall" -p TCP --dport 853 -d 1.1.1.1,1.0.0.1,8.8.8.8,8.8.4.4 -m owner --uid-owner root -j ACCEPT

 

[eriol1]

Alright, so setting a "dns" in the rule didn't work. It has to be the IP. But that is fine.

In "Set Custom Script" I now have this:


I do not have any "shutdown custom script". I guess that is fine?

Also, is my rule the preferred method of setting a custom script or should I use it like this (or does it not matter at all):

No need for a shutdown script for your use case.

I think setting the $iptables var is only necessary when you save your script to a file and reference the file in the custom script field.
Not entirely sure though, and either way, as long as what you did works you should be fine.