Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tethering DNS problem #327

Open
SafwatHalaby opened this issue Nov 23, 2014 · 29 comments

Comments

Projects
None yet
@SafwatHalaby
Copy link

commented Nov 23, 2014

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.
screenshot_2014-12-07-12-11-30

@cernekee

This comment has been minimized.

Copy link
Contributor

commented Nov 23, 2014

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

This comment has been minimized.

Copy link
Author

commented Nov 23, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Nov 23, 2014

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

This comment has been minimized.

Copy link
Author

commented Nov 25, 2014

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

This comment has been minimized.

Copy link
Author

commented Dec 7, 2014

Using "Black list" mode solves this.

@CHEF-KOCH

This comment has been minimized.

Copy link
Contributor

commented Dec 19, 2014

Do not use blacklist mode, never ever use a firewall with blacklist mode!!! There are several security reasons to not use this and it's also the reasons why this is not enabled by default.

I'm also fighting with this since the beginning of all iptables based firewalls. And I think it have to do with several aspects and problems. As cernekee wrote one of them is that we don't know which interface is used or interfaces with strange names which AFWall+ can't respect.

As I wrote in the other thread forcing the DNS under windows/linux and Android fixes most of this problems without any troubles (for me). Just use OverrideDNS (paid app but only one which also works on KitKat/Lollipop) on Android or use the Wiki example to set the DNS with the firewall (not for Lollipop) and enter the same DNS in you OS under the network interface (only ipv4!). That works 100% no matter which interface name. You do not need to touch the adb.

The only thing is that if you enable/disable the firewall you need sometimes to restart your phone (don't know why), but it's only in rear situations. Make sure (root) - Applications running as root and the DHCP+DNS option is enabled under whitelist, this also works with netd disabled on CM roms (non Lollipop based).

@SafwatHalaby

This comment has been minimized.

Copy link
Author

commented Dec 23, 2014

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

This comment has been minimized.

Copy link

commented Jan 20, 2015

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

This comment has been minimized.

Copy link
Author

commented Jan 20, 2015

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

@CHEF-KOCH

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2015

Check my workarounds for several issue here. Remember to set the DNS for multiple interfaces at the same time isn't possible!
Typically interface names are (but depending on the kernel settings): usb0, rndis0, enp0s26f7u3, iface(depending how many usb ports), enp0s1u23, enp0s1. The freaking names like enpXXX is widely used by some linux distros.

Please allays check this if there is a DNS problem:

  • DHCP is up and running with a proper configuration
  • Default Gateway Router to resolve/check pings from the Internet
  • You provider does not blocked tethering (general - see my first workaround)
  • You provider does not blocked tethering, because low money (DNS will be unavailable) [can't fixed]
  • In your NetworkConnectionBridge configuration there is something wrong, check wpa_supplicant.conf and your 20-dns.conf -> There are also some kernel/roms which provide additional files to change the interface names an reverse tethering example is here

We need this output via adb/terminal emulator to see which interfaces are available and for other important info:

netcfg
lsusb
dmesg|tail
route
ip link 
ip ru + ip route ls tab [iface number]
# May needs to be changed to your iface, may also helps if you change/remove mtp
setprop sys.usb.config rndis,nat,adb

After some more research and over 20 hours of debugging and drive + error here is what the current state is:

The whole resolve.conf stuff does not work anymore, this only works for wired-tether or explicit on Wifi only (depending on dhcp config). This can be shown by adb shell dumpsys connectivity | grep DnsAddresses which shows that no matter what you set, on USB-Thethering it still uses your providers DNS.

On stock roms:

  • USB thetering IP is hardcoded (com.android.server.connectivity.Tethering + android.net.wifi.WifiStateMachine.startTethering();)
  • Normally it is set to 192.168.43.1/24 as the server and netd handle the tethering stuff using dnsmasq which results in the first DNS Range in 192.168.42.1-254 to the second 192.168.43.1-254. Check with busybox ps | grep dnsmasq.
  • USB0 always use dhcp (or dhcpv6) (dhcpcd --nogateway --nohook resolv.conf --nohook hostname usb0) and check the settings via route add -host my_sshd_remote_host_IP dev usb0.
  • Android can't handle two interfaces at the same time (means your can't apply with external apps like OverrideDNS the new DNS for USB0 and WiFI).
  • Check state iuf connected via ipleak.
  • On Android 4.+ Android offers DHCP by default so this never can be fixed by AFWall+ or any related problem with a misleading configuration.

On Firefox (for socks proxy):

  • You need to be set network.proxy.socks_remote_dns to true.

On AFWall+:

  • DHCP option was added as a workaround + a toggle for netd (depending how stuff was implemented especially on Stock this may result in 'connection unavailable'.)
//WiFI
private static final String DHCP_DEFAULT_RANGE1_START = "192.168.42.2";
private static final String DHCP_DEFAULT_RANGE1_STOP  = "192.168.42.254";
private static final String DHCP_DEFAULT_RANGE2_START = "192.168.43.2";
private static final String DHCP_DEFAULT_RANGE2_STOP  = "192.168.43.254";
//USB Client -> 192.168.42.129
private static final String USB_NEAR_IFACE_ADDR      = "192.168.42.129";
private static final String USB_NETMASK              = "255.255.255.0";

mDhcpRange = context.getResources().getStringArray(
            com.android.internal.R.array.config_tether_dhcp_range);
    if ((mDhcpRange.length == 0) || (mDhcpRange.length % 2 ==1)) {
        mDhcpRange = new String[4];
        mDhcpRange[0] = DHCP_DEFAULT_RANGE1_START;
        mDhcpRange[1] = DHCP_DEFAULT_RANGE1_STOP;
        mDhcpRange[2] = DHCP_DEFAULT_RANGE2_START;
        mDhcpRange[3] = DHCP_DEFAULT_RANGE2_STOP;
    }

It's hardcoded into the framework-res.apk which can be edited with several tools, <string-array name="config_tether_dhcp_range"> and others are good examples to look at.

See also #83545 & many others.

@uudruid74

This comment has been minimized.

Copy link

commented Oct 6, 2015

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 :)

@ukanth ukanth added the DNS label Aug 4, 2016

@muv

This comment has been minimized.

Copy link

commented Dec 1, 2016

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

This comment has been minimized.

Copy link

commented Dec 12, 2016

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

This comment has been minimized.

Copy link

commented Dec 18, 2016

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

This comment has been minimized.

Copy link

commented Dec 31, 2016

@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

This comment has been minimized.

Copy link

commented Apr 26, 2017

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

This comment has been minimized.

Copy link

commented Apr 26, 2017

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

This comment has been minimized.

Copy link

commented Nov 1, 2017

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

@aryoda

This comment has been minimized.

Copy link

commented Jan 7, 2018

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

This comment has been minimized.

Copy link

commented Jan 4, 2019

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

This comment has been minimized.

Copy link
Owner

commented Jan 4, 2019

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

@harryharryharry

This comment has been minimized.

Copy link

commented Jan 4, 2019

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

This comment has been minimized.

Copy link
Owner

commented Jan 4, 2019

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

@harryharryharry

This comment has been minimized.

Copy link

commented Jan 4, 2019

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

This comment has been minimized.

Copy link
Owner

commented Jan 4, 2019

Export the rules from preference and attach it here.

@ukanth

This comment has been minimized.

Copy link
Owner

commented Jan 4, 2019

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

@petersnows25

This comment has been minimized.

Copy link

commented Feb 11, 2019

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

This comment has been minimized.

Copy link

commented Feb 13, 2019

@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

This comment has been minimized.

Copy link

commented Feb 13, 2019

@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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.