Tethering DNS problem

[SafwatHalaby]

When AFWALL is enabled, USB tethering DNS resolution does not work. However, browsing sites by ip works, so the only problem is the DNS.

(Tethering) - DHCP+DNS services is enabled. Enabling or disabling (root) - Applications running as root or (Kernel) - Linux Kernel has no effect.

Versions: AFWall+ (v1.3.4.1), Android 4.4.4 Cyanogenmod 11-20140805-M9-hammerhead, Nexus 5.

There were similar issues before: #178 , #4

Edit: Using Black list mode solves this, see attached image.

[cernekee]

I have seen this problem too.

Last time I looked at it, we didn't know of a reliable way of determining whether USB tethering was active. There are broadcasts and/or undocumented APIs that tell us if wifi tethering is active.

Intercepting commands on the netd socket is one possible path forward, but maybe there is a better one (or maybe we should just look for a USB interface with IP 192.168.42.1)?

[SafwatHalaby]

I am totally inexperienced with iptables so this might be irrelevant: But can't you simply tell it "do not block the ports related to DNS?".

[cernekee]

Typically we would want that policy to be enabled/disabled based on whether wifi is used for the connection uplink or for tethering.

I just remembered another complication: some 3G modems show up as network interfaces named "usbN" (N is a number). Unfortunately, so does a tethered device. AFWall doesn't currently have a way to distinguish the two cases.

[SafwatHalaby]

Here's a mini guide for a very, very dirty trick, but it works. The final setup: TCP over SOCKS5 over SSH over TCP over ADB

TCP over ADB (Computer to phone communication)

1. Enable AFWALL, enable (root) - Applications running as root
2. Make sure you have ADB on your computer, it allows you to forward TCP packets to your phone and connect to the ssh server.
3. Establish TCP over ADB with the following computer command: adb forward tcp:5113 tcp:22 Note that 5113 was chosen arbitrary, this tells ADB: "Anything that connects to localhost on the computer at port 5113 is to be forwarded to the phone to port 22"

At this point, you can forget about ADB, you now have a way to forward TCP to your phone, just connect anything to localhost:5113 and it will reach the phone at port 22.

SSH over TCP (regular SSH)

1. Install an SSH server on your phone. On Cyanogenmod and other ROMS, the ssh server is already there, you just need to activate it via the phone's terminal (or adb shell), see the appropriate guide for your particular ROM. Also, some SSH servers are available on the Play store.
2. At this point, if you point your computer SSH client to localhost:5113 it will connect to your phone's SSH server.

Socks5 over SSH

1. Just execute ssh -D 8787 localhost -p 5113
2. At this point, your ssh client will connect to your phone's ssh daemon,but it will also create a socks5 server on your computer's localhost, port 8787. Any socks5 client that connects to localhost:8787 will leave the network via your phone! (port 8787 was picked arbitrarily)

TCP over socks5

That's client dependent. To browse the web, change e.g. Firefox's preferences so that it uses the socks5 proxy at localhost:8787, (You also need remote DNS), now, you have "tethered" Firefox! it will be able to bypass AFWALL because the Android SSH Daemon is considered a root application.

Note that the hassle is only for the setup, consequent tethering sessions only require the following command sequence

adb forward tcp:5113 tcp:22 ssh -D 8787 root@localhost -p 5113

Run firefox here or whatever you want

adb forward --remove tcp:5113 #Delete the adb bridge when finished.

[SafwatHalaby]

Using "Black list" mode solves this.

[SafwatHalaby]

Thanks for the valuable info, I eventually deleted AFWALL because it is causing too much headache when it comes to tethering, I will try the techniques you mentioned when I have the chance.

[DaPa]

I also hit wifi tethering connection problems using i9100 CM11 M12 (android 4.4.4, kernel 3.0.64) and AFWall+ 1.3.4.1, so I want to list my experience. After trial and error I found that I had to enable only these 3 items in AFWall (white list mode, Lan control enabled, logging enabled):

• Lan WiFi GSM Application
• 0 1 0 "1000: Settings, Dev Tools, ...."
• 0 0 1 "-14: (NTP) - Internet time servers"
• 0 0 1 "-12: (Tethering) - DHCP + DNS services"

The laptop (Win7x64) connected only when I turned off the Comodo firewall and it got automatically the IP 192.168.43.249/255.255.255.0, with gateway, DNS and DHCP servers set to 192.168.43.1. The connection was dropping when I re-enabled Comodo firewall, and in order to make it work I had to change in Comodo Firewall -> Global Rules a blocking rule for incoming "ECHO REQUEST" ICMP messages: I modified that rule to still block these messages except those from 192.168.43.1 to 192.168.43.249. After this the connection was reliable. I made a profile "wi-fi tethering" in AFWall so it's now easy to switch from this mode to the others... Hope it helps others too.

[SafwatHalaby]

(Regarding the duplicate tag) This is not exactly a duplicate since it re-occurred after the previous issue was closed.

[uudruid74]

Sam issue persists with Bluetooth tether. Add as custom script:

iptables -A 'afwall' -p udp -m udp -d 172.26.38.1 --dport 53 -j ACCEPT
iptables -A 'afwall' -p udp -m udp -d 172.26.38.1 --sport 53 -j ACCEPT

If you use USB tether or whatever, just replace the IP above with the one that keeps blinking on your screen (if you have the toasts turned on) every time you click a link :)

[muv]

Same bug with USB Tethering here -- DNS is broken. Latest AFWall 2.9.0, CyanogenMod 12.1. @uudruid74 your workaround makes it work indeed. Thank you.

[sarnold]

Using the kernel option net.ifnames=0 solves the interface naming problem; normally I set it as cmdline option. It should be possible to or reset this (probably with a reboot) and even push a bug to cm/aosp. Haven't tried on android yet, but I will shortly...

[kaefert]

I just installed AFWall+ 2.9.1 through FDroid 0.102 on my Samsung Galaxy S5 running Android 6.0.1

Hotspot Tethering worked out of the box :)

[breversa]

@uudruid74 : your workaround works fine with AFWall+ 2.9.1 (+key) on CyanogenMod 13.1 for USB tethering.

I had to had add the IP addresses of the several DNS servers of my phone provider and clear the rules/restart AFWall+/restart my phone because USB tethering wouldn't stay on, but all is fine now.

Any way to make that work out of the box ?

[michael-brade]

I can confirm this with 2.9.4. AFWall's log seemed misleading with messages about blocked packages from app null (9999). But as soon as I added the DNS servers as well as @uudruid74's rules, it worked.

[michael-brade]

PS: what I find strage is that afwall-wifi-tether is nowhere used, no jump into it seems to be available. Here are my rules, with the 6 added custom rules in afwall, denoted by empty lines:

-A INPUT -j bw_INPUT
-A INPUT -j fw_INPUT
-A FORWARD -j oem_fwd
-A FORWARD -j fw_FORWARD
-A FORWARD -j bw_FORWARD
-A FORWARD -j natctrl_FORWARD
-A OUTPUT -j afwall
-A OUTPUT -j oem_out
-A OUTPUT -j fw_OUTPUT
-A OUTPUT -j st_OUTPUT
-A OUTPUT -j bw_OUTPUT

-A afwall -d 192.168.42.65/32 -p udp -m udp --dport 53 -j ACCEPT
-A afwall -d 192.168.42.65/32 -p udp -m udp --sport 53 -j ACCEPT
-A afwall -d 8.8.8.8/32 -p udp -m udp --sport 53 -j ACCEPT
-A afwall -d 8.8.4.4/32 -p udp -m udp --sport 53 -j ACCEPT
-A afwall -d 8.8.8.8/32 -p udp -m udp --dport 53 -j ACCEPT
-A afwall -d 8.8.4.4/32 -p udp -m udp --dport 53 -j ACCEPT

-A afwall -o tun+ -j afwall-vpn
-A afwall -o ppp+ -j afwall-vpn
-A afwall -o tap+ -j afwall-vpn
-A afwall -m mark --mark 0x3c/0xfffc -g afwall-vpn
-A afwall -m mark --mark 0x40/0xfff8 -g afwall-vpn
-A afwall -o eth+ -j afwall-wifi
-A afwall -o wlan+ -j afwall-wifi
-A afwall -o tiwlan+ -j afwall-wifi
-A afwall -o ra+ -j afwall-wifi
-A afwall -o bnep+ -j afwall-wifi
-A afwall -o rmnet+ -j afwall-3g
-A afwall -o pdp+ -j afwall-3g
-A afwall -o uwbr+ -j afwall-3g
-A afwall -o wimax+ -j afwall-3g
-A afwall -o vsnet+ -j afwall-3g
-A afwall -o rmnet_sdio+ -j afwall-3g
-A afwall -o ccmni+ -j afwall-3g
-A afwall -o qmi+ -j afwall-3g
-A afwall -o svnet0+ -j afwall-3g
-A afwall -o ccemni+ -j afwall-3g
-A afwall -o wwan+ -j afwall-3g
-A afwall -o cdma_rmnet+ -j afwall-3g
-A afwall -o usb+ -j afwall-3g
-A afwall -o rmnet_usb+ -j afwall-3g
-A afwall -o clat4+ -j afwall-3g
-A afwall -o cc2mni+ -j afwall-3g
-A afwall -o bond1+ -j afwall-3g
-A afwall -o rmnet_smux+ -j afwall-3g
-A afwall -o ccinet+ -j afwall-3g
-A afwall -o v4-rmnet+ -j afwall-3g
-A afwall -o seth_w+ -j afwall-3g
-A afwall -o v4-rmnet_data+ -j afwall-3g
-A afwall -d 192.168.42.65/32 -p udp -m udp --dport 53 -j ACCEPT
-A afwall -d 192.168.42.65/32 -p udp -m udp --sport 53 -j ACCEPT
-A afwall -d 8.8.8.8/32 -p udp -m udp --sport 53 -j ACCEPT
-A afwall -d 8.8.4.4/32 -p udp -m udp --sport 53 -j ACCEPT
-A afwall -d 8.8.8.8/32 -p udp -m udp --dport 53 -j ACCEPT
-A afwall -d 8.8.4.4/32 -p udp -m udp --dport 53 -j ACCEPT
-A afwall-3g -j afwall-3g-postcustom
-A afwall-3g-fork -j afwall-3g-home
-A afwall-3g-home -m owner --uid-owner 1016 -j RETURN
-A afwall-3g-home -m owner --uid-owner 10009 -j RETURN
-A afwall-3g-home -m owner --uid-owner 10082 -j RETURN
-A afwall-3g-home -p udp -m udp --dport 53 -m owner --uid-owner 0 -j RETURN
-A afwall-3g-home -j afwall-reject
-A afwall-3g-postcustom -j afwall-3g-fork
-A afwall-3g-roam -p udp -m udp --dport 53 -m owner --uid-owner 0 -j RETURN
-A afwall-3g-roam -j afwall-reject
-A afwall-3g-tether -p udp -m owner --uid-owner 0 -m udp --dport 53 -j RETURN
-A afwall-3g-tether -p udp -m owner --uid-owner 9999 -m udp --dport 53 -j RETURN
-A afwall-3g-tether -p tcp -m owner --uid-owner 0 -m tcp --dport 53 -j RETURN
-A afwall-3g-tether -p tcp -m owner --uid-owner 9999 -m tcp --dport 53 -j RETURN
-A afwall-3g-tether -j afwall-3g-fork
-A afwall-reject -j NFLOG --nflog-prefix  "{AFL}" --nflog-group 40
-A afwall-reject -j REJECT --reject-with icmp-port-unreachable
-A afwall-vpn -m owner --uid-owner 1016 -j RETURN
-A afwall-vpn -m owner --uid-owner 10009 -j RETURN
-A afwall-vpn -m owner --uid-owner 10082 -j RETURN
-A afwall-vpn -p udp -m udp --dport 53 -m owner --uid-owner 0 -j RETURN
-A afwall-vpn -j afwall-reject
-A afwall-wifi -j afwall-wifi-postcustom
-A afwall-wifi-fork -d 10.59.0.0/20 -j afwall-wifi-lan
-A afwall-wifi-fork ! -d 10.59.0.0/20 -j afwall-wifi-wan
-A afwall-wifi-lan -p udp -m udp --dport 53 -j RETURN
-A afwall-wifi-lan -m owner --uid-owner 1016 -j RETURN
-A afwall-wifi-lan -m owner --uid-owner 10009 -j RETURN
-A afwall-wifi-lan -m owner --uid-owner 10032 -j RETURN
-A afwall-wifi-lan -m owner --uid-owner 10068 -j RETURN
-A afwall-wifi-lan -m owner --uid-owner 10082 -j RETURN
-A afwall-wifi-lan -m owner --uid-owner 10083 -j RETURN
-A afwall-wifi-lan -p udp -m udp --dport 53 -m owner --uid-owner 0 -j RETURN
-A afwall-wifi-lan -j afwall-reject
-A afwall-wifi-postcustom -m owner --uid-owner 1014 -j RETURN
-A afwall-wifi-postcustom -m owner --uid-owner 1010 -j RETURN
-A afwall-wifi-postcustom -j afwall-wifi-fork
-A afwall-wifi-tether -p udp -m owner --uid-owner 0 -m udp --sport 67 --dport 68 -j RETURN
-A afwall-wifi-tether -p udp -m owner --uid-owner 9999 -m udp --sport 67 --dport 68 -j RETURN
-A afwall-wifi-tether -p udp -m owner --uid-owner 0 -m udp --sport 53 -j RETURN
-A afwall-wifi-tether -p udp -m owner --uid-owner 9999 -m udp --sport 53 -j RETURN
-A afwall-wifi-tether -p tcp -m owner --uid-owner 0 -m tcp --sport 53 -j RETURN
-A afwall-wifi-tether -p tcp -m owner --uid-owner 9999 -m tcp --sport 53 -j RETURN
-A afwall-wifi-tether -j afwall-wifi-fork
-A afwall-wifi-wan -m owner --uid-owner 1016 -j RETURN
-A afwall-wifi-wan -m owner --uid-owner 10009 -j RETURN
-A afwall-wifi-wan -m owner --uid-owner 10032 -j RETURN
-A afwall-wifi-wan -m owner --uid-owner 10068 -j RETURN
-A afwall-wifi-wan -m owner --uid-owner 10082 -j RETURN
-A afwall-wifi-wan -m owner --uid-owner 10083 -j RETURN
-A afwall-wifi-wan -p udp -m udp --dport 53 -m owner --uid-owner 0 -j RETURN
-A afwall-wifi-wan -j afwall-reject
-A bw_FORWARD -m quota2 ! --name globalAlert  --quota 2097152 
-A bw_INPUT -m quota2 ! --name globalAlert  --quota 2097152 
-A bw_INPUT -m owner --socket-exists
-A bw_OUTPUT -m quota2 ! --name globalAlert  --quota 2097152 
-A bw_OUTPUT -m owner --socket-exists
-A bw_costly_shared -j bw_penalty_box
-A fw_INPUT -j fw_standby
-A fw_OUTPUT -j fw_standby
-A fw_dozable -m owner --uid-owner 0-9999 -j RETURN
-A fw_dozable -j DROP
-A natctrl_FORWARD -i wlan0 -o usb0 -m state --state RELATED,ESTABLISHED -g natctrl_tether_counters
-A natctrl_FORWARD -i usb0 -o wlan0 -m state --state INVALID -j DROP
-A natctrl_FORWARD -i usb0 -o wlan0 -g natctrl_tether_counters
-A natctrl_FORWARD -j DROP
-A natctrl_tether_counters -i usb0 -o wlan0 -j RETURN
-A natctrl_tether_counters -i wlan0 -o usb0 -j RETURN

[atrent]

confirmed on afwall 2.9.6.1, I have to disable firewall to have DNS resolution

[aryoda]

confirmed on afwall 2.9.7 on a OnePlus 3T with LineageOS 7.1.2:

It seems that activating the tethering (personal hotspot using wifi) is not recognized by afwall (or signalled to afwall by LineageOS) because there is no jump or goto in the iptable rules to the afwall-wifi-tether or afwall-3g-tether chain. Instead the *-fork chains are called.

It looks like this code fragment of API.java is never TRUE despite of active tethering:

if (cfg.isTethered) {
                cmds.add("-A " + AFWALL_CHAIN_NAME + "-wifi-postcustom -j " + AFWALL_CHAIN_NAME + "-wifi-tether");
                cmds.add("-A " + AFWALL_CHAIN_NAME + "-3g-postcustom -j " + AFWALL_CHAIN_NAME + "-3g-tether");
            } else {
                # -A afwall-wifi-postcustom -j afwall-wifi-fork
                cmds.add("-A " + AFWALL_CHAIN_NAME + "-wifi-postcustom -j " + AFWALL_CHAIN_NAME + "-wifi-fork");
                # -A afwall-3g-postcustom -j afwall-3g-fork
                cmds.add("-A " + AFWALL_CHAIN_NAME + "-3g-postcustom -j " + AFWALL_CHAIN_NAME + "-3g-fork");
}

===========
System info
===========

Android version: 7.1.2
Manufacturer: OnePlus
Model: ONEPLUS A3003
Build: lineage_oneplus3-userdebug 7.1.2 NJH47F f61631cb3b
Active interface: unknown
Tether status: unknown
Roam status: no
IPv4 subnet: 
IPv6 subnet: 
/system/bin/su: 166576 bytes
/system/xbin/su: 166576 bytes
/system/app/Superuser.apk: not present
Superuser: none found

How about a "Tethering" on/off switch in the afwall UI as "last manual ressort"?

[harryharryharry]

I'm having this issue on omnirom 9. Logs show multiple attempts by an 'Unknown' process on source port 53, and 1 attempt by a process called mDNS on source port 5353 (which I cant find in the whitelist).

Are people (@ukanth ?) still looking into this issue that was opened more than 4 years ago?

[ukanth]

You should enable "dns via netd" along with kernel,root and tether from the apps. It works fine without any issue.

[harryharryharry]

I already had (kernel) (root) and (tethering) enabled, however there is no such entry as "dns via netd" (or is this an option somewhere else in afwall or in android settings ?

[ukanth]

Yes. it's under Preferences->Binaries - DNS Proxy

[harryharryharry]

Ah yes thanks. I selected "Enable dns via netd" but still no dns. Also not after reboot. Edit: the denials for the 'unknown' process (on src port 53) keep coming in in the logs.

[ukanth]

Export the rules from preference and attach it here.

[ukanth]

Also make sure you have LAN connection enabled and whitelisted for the above ones.

[petersnows25]

I have the same problem AfWall+ 3.0.4 Android 9

I had to add the following custom script: iptables -A 'afwall' -p udp -m udp --dport 53 -j ACCEPT iptables -A 'afwall' -p udp -m udp --sport 53 -j ACCEPT

Since Afwall+ allows you to "set custom script".

• Click "3 dots" on the right top corner
• click "set custom script"
• on "enter custom script bellow" place this 2 lines: iptables -A 'afwall' -p udp -m udp --dport 53 -j ACCEPT iptables -A 'afwall' -p udp -m udp --sport 53 -j ACCEPT

[aryoda]

@petersnows25 What do you mean with "Add to add the following custom script"?

Is this meant to show your set-up or is this a proposed work-around (which would be great!)?

[petersnows25]

@petersnows25 What do you mean with "Add to add the following custom script"?

Is this meant to show your set-up or is this a proposed work-around (which would be great!)?

It is a workaround

Afwall+ allows you to "set custom script".

• Click "3 dots" on the right top corner
• click "set custom script"
• on "enter custom script bellow" place this 2 lines: iptables -A 'afwall' -p udp -m udp --dport 53 -j ACCEPT iptables -A 'afwall' -p udp -m udp --sport 53 -j ACCEPT

[the-sibyl]

@petersnows25 The port 53 workaround works great. I have a Pixel 3 (blueline) with a very custom ROM that I built with, among other things, a shell script executed by init.rc that sets firewall rules as early as possible during boot. I had a few reasons for doing it manually, but it did introduce many unknowns.

Keep up the good work, everyone.

[AdamPS]

@petersnows25 port 53 workaround solves the problem for me. Are there any disadvantages? Would it be possible to include this as part of AfWall+ please?

[Msouza91]

Can confirm, stil experiencing this on the latest version of AfWall+ LineageOS 17.1 weekly The workaround with the script solved the problem, but is it good practice? I'm trying to be more secure with my phone, but no where savvy enough about firewalls and secure connections yet to understand completely, as it is outside of the "public" range of ports it shouldn't cause many issues, but are there some particularly dangerous edge cases?

[dec0de]

A better solution:

I believe the solutione given is not totally correct:

iptables -A 'afwall' -p udp -m udp --dport 53 -j ACCEPT <- this is corret iptables -A 'afwall' -p udp -m udp --sport 53 -j ACCEPT <- I cannot see why doing it with sport as well

DNS can nowadays use both udp and tcp, hence this would make more sence as a second line: iptables -A 'afwall' -p tcp -m tcp --dport 53 -j ACCEPT

When it comes to my solution I had to go a step further. Setting up bluetooth tethering between two android devices (in my case a Samsung Galaxy Tab S6 (Android 10) --> Sony Xperia X (android 7.0.1), both rooted, both having AFwall+ I noticed after connecting to the phone, bluetooth tethering totally ignores your DNS settings and assumes you want to send the DNS request to the gateway phone (in my case 192.168.44.1). Routing etc worked fine as long as I used IP numbers, but doing a ping www.google.com wouldn't work. After several days not being able to figure out where to specificly set the bluetooth DNS (can this even be done?), I came up with the following AFwall script to include. To make it a bit controllable what type of DNS you want to use I am fetching net.dns1 (the one you can manually set using the android UI). Bare in mind this will send all DNS requests to that server, not only when doing bluetooth tethering, but any time you connect using wireless or you name it; something that might not suit all...

--------------------------------------------------------------------------------------- OEM_SCRIPT_PATH=/system/bin/oem-iptables-init.sh IP6TABLES=/systembin/ip6tables IPTABLES=/system/bin/iptables DNS=$(getprop net.dns1) $IPTABLES -A 'afwall' -p udp --dport 53 -j ACCEPT $IPTABLES -A 'afwall' -p tcp --dport 53 -j ACCEPT $IPTABLES -t nat -D OUTPUT -p udp --dport 53 -j DNAT --to-destination $DNS $IPTABLES -t nat -D OUTPUT -p tcp --dport 53 -j DNAT --to-destination $DNS $IPTABLES -t nat -I OUTPUT -p udp --dport 53 -j DNAT --to-destination $DNS $IPTABLES -t nat -I OUTPUT -p tcp --dport 53 -j DNAT --to-destination $DNS ---------------------------------------------------------------------------------------

For all those trying to troubleshoot these things, termux is really your savior. a shell where you can install things such as vim, sudo, dig/nslookup etc. This is how I figured out that all but the DNS worked (pre using the above script):

ping 8.8.8.8 # if working routing works dig www.google.com # dig strangely doesn't use the gateway to request the DNS server

telnet [the ip you've got from dig] 80 # to see you can do some TCP GET / [enter] [enter]

dig www.google.com @[your gateway IP] # just check if your gateway relays DNS (which it probably wont) dig www.google.com @8.8.8.8 # maybe a bit redundant check, but why not ;-) ping www.google.com # this will probably fail as this DNS request will go through your gateway.**

Now create a script and make AFwall use it, do the above tests again and Voila! it will most probably work.

PS. i used the app DNSSetter to easily set the net.dns1 through the UI.

[breversa]

Thanks for your contribution ! But why not stray away from Google and use another, less privacy-threatening DNS provider like 1.1.1.1 ? :)

[dec0de]

Do you see any problem not using whatever DNS you want? I explicitly put in getprop and gave a suggestion for the app DNSsetter so whomever can put in whatever they prefer when it comes to DNS server. If you look closely I only mention google as a suggestion for troubleshooting. Nowhere is it used in the script.

[breversa]

Yes of course ; I actually was thinking of "straying away from Google-as-an-example" too.

[dec0de]

Edit: maybe this lines will not do as expected and can be removed: $IPTABLES -t nat -D OUTPUT -p udp --dport 53 -j DNAT --to-destination $DNS $IPTABLES -t nat -D OUTPUT -p tcp --dport 53 -j DNAT --to-destination $DNS

because if you change the DNS (using DNSSetter by example) and then do apply in AFwall, it will try to remove the iptable line using the new DNS IP which will fail. I am by no means an expert on iptables but to my knowledge there are two different ways, one by line number, or by exact match. I presume it might therefore be better to simply remove these two lines. You can of course also do something like

$IPTABLES -t nat -D OUTPUT $(set -- $(iptables -L afwall -n --lin |grep 'udp dpt:53'| head -1);echo $1) $IPTABLES -t nat -D OUTPUT $(set -- $(iptables -L afwall -n --lin |grep 'tcp dpt:53'| head -1);echo $1)

But I believe such a solution is more for the bold and brave. As the script will be running as root it might be better to limit what is done as much as possible.

[dec0de]

Well, what harm do you think me using one world famous DNS server and website will do to the people? Rest assure the very ones brave enough to manipulate their firewall on a script basis will have the freedom to do all their tests using whatever website and DNS of their choosing. But of course just as well as modern alcohol beverages need to put forward an alternative:

To all following my examples, remember you can just as well use DNS 1.1.1.1 and the website github.com to test

better?

[dec0de]

For the brave and foolhearted, these lines have now been tested and works:

`------------------------------------------------------------------------------------------------------------ OEM_SCRIPT_PATH=/system/bin/oem-iptables-init.sh IP6TABLES=/systembin/ip6tables IPTABLES=/system/bin/iptables DNS=$(getprop net.dns1) $IPTABLES -A 'afwall' -p udp --dport 53 -j ACCEPT $IPTABLES -A 'afwall' -p tcp --dport 53 -j ACCEPT

$IPTABLES -t nat -D OUTPUT $(set -- $($IPTABLES -t nat -L OUTPUT -n --lin |grep 'udp dpt:53'| head -1);echo $1) $IPTABLES -t nat -D OUTPUT $(set -- $($IPTABLES -t nat -L OUTPUT -n --lin |grep 'tcp dpt:53'| head -1);echo $1) $IPTABLES -t nat -I OUTPUT -p udp --dport 53 -j DNAT --to-destination $DNS $IPTABLES -t nat -I OUTPUT -p tcp --dport 53 -j DNAT --to-destination $DNS ------------------------------------------------------------------------------------------------------------ˋ

It will actually also take the right DNS (the one you might get through DHCP if connecting with WIFI) as well, meaning if of some reason your DNS doesnẗ work simply apply the rules in AFWall..

[dec0de]

A note for those who will need to use the above script: If you are switching from an earlier used WIFI network, the net.dns1 will still probably contain an IP of the earlier accesspoint (working as a relay DNS server). If this is the case you will first need to edit the DNS (using earlier mentioned DNS app by example), afterwards you will do an "Apply" in AFwall+ that will do a NAT to the stored DNS server...

[bphd]

Same but without any firewall at all

[0xzfs]

You can fix this by forcing standard DNS settings (Set private DNS mode: off/automatic) and allowing these apps in AFWall:

1. (mdns) Multicast DNS
2. ProxyHandler

If it still doesn't work, try to allow even these:

3. apps running as root
4. (tethering) - DHCP+DNS services

It seems to work differently for me in case I use another SIM card.

Anyway, 100% working fix is this one:

1. AFWall -> Preferences -> Rules/Connectivity
2. Check "LAN control"
3. Go back to your rules, find app [-10] (Any app) - Same as selecting all apps - !! WARNING!!
4. Check only LAN checkbox
5. Apply rules