1.1.0/1.2.0 broke host lookups on nexus 5x

[infinity0]

DNS lookups don't work, so most apps being forced through Tor don't work. Visiting an IP address directly over a forced Firefox works, so I guess this [i.e. fixing the DNS] would fix most things.

[infinity0]

To clarify, sometimes DNS does work (for some apps and not others) after I deactivate and reactivate orwall, but then stop working again after several minutes.

[infinity0]

Pinging @hgourvest since you were responsible for most of the commit changes between 1.0.6 and 1.2.0.

[hgourvest]

is this happened after you rebooted your phone?

[infinity0]

Yes, I've rebooted it like 10 times now.

[hgourvest]

ok, there is 2 issus at boot time:

1. when orbot start the first time, it open transproxy ports but he not yet really able to handle tcp packets or dns queries, so when it receive data, it crash 10 sec after receiving the first packets.
   It continue to crash after you restrat orbot.
2. at boot time, some times iptable fail to add some rules.

for now, my advice is stop reboot your phone, disable orWall at boot time, let orbot working 5 minutes without receiving data through transproxy, and then activate orWall. Everything should be fine if orbot initialize correctly without crashing because of unexpected data transmited through trans proxy.

This issu existed before I start working on orWall, I hope I will find a way to fix it.

[infinity0]

Thanks for the detailed explanation. I tried what you suggested, and currently it's hard to say if it was useful. The behaviour seems to be inconsistent - sometimes when I activate orWall, some apps have internet access via tor, and some apps just fail their network connections (all of these are forced through tor according to my orwall settings). I was also confused by your suggestion to enable transproxy in orbot - I never needed to do this before, and orwall should make this unnecessary - but it did seem to fix the "unknown host" errors that some apps were giving me.

I'll report back if I find any other interesting behaviours.

However, if this "issue existed before", why am I only seeing my problems in 1.1.0 and 1.2.0? I was using 1.0.6 just fine yesterday, without these problems.

[hgourvest]

hum, I never said to activate transproxy in orbot, it is not necessary.
Could you tell me what app do not work?

[hgourvest]

something usefull to understand the problem would be to send me your iptables rules when the problem occur:

adb shell
su
iptables -S > /sdcard/Download/filter.txt
iptables -t nat -S > /sdcard/Download/nat.txt

thanks in advance

[n0airc0n]

I also have issues with orwall since v1.1.0/1.2.0 on replicant 4.2. Here is the requested output. Note the `protoent* getprotobynumber(int)(3) is not implemented on Android' error message in the iptables output. It would be outstanding to have this fixed. :-)

---

shell@android:/ # iptables -S                                                  
-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT DROP
-N bw_FORWARD
-N bw_INPUT
-N bw_OUTPUT
-N costly_shared
-N fw_FORWARD
-N fw_INPUT
-N fw_OUTPUT
-N natctrl_FORWARD
-N oem_fwd
-N oem_out
-N ow_INPUT
-N ow_INPUT_LOCK
-N ow_LAN
-N ow_OUTPUT
-N ow_OUTPUT_LOCK
-N penalty_box
-A INPUT -j bw_INPUT
-A INPUT -j fw_INPUT
-A INPUT -j ow_INPUT
-A FORWARD -j oem_fwd
-A FORWARD -j fw_FORWARD
-A FORWARD -j bw_FORWARD
-A FORWARD -j natctrl_FORWARD
-A OUTPUT -j oem_out
-A OUTPUT -j fw_OUTPUT
-A OUTPUT -j bw_OUTPUT
-A OUTPUT -j ow_OUTPUT
-A bw_INPUT ! -i lo+ -m quota2 ! --name globalAlert  --quota 2097152 
-A bw_INPUT -i lo -j RETURN
-A bw_INPUT -m owner --socket-exists
-A bw_OUTPUT ! -o lo+ -m quota2 ! --name globalAlert  --quota 2097152 
-A bw_OUTPUT -o lo -j RETURN
-A bw_OUTPUT -m owner --socket-exists
-A costly_shared -j penalty_box
-A ow_INPUT -s 10.10.10.0/24 -j ow_LAN
-A ow_INPUT -m owner --uid-owner 10043 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -m comment --comment "Allow Orbot inputs" -j ACCEPT
-A ow_INPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "Allow related,established inputs" -j ACCEPT
-A ow_INPUT_LOCK -m owner --uid-owner 10043 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
-A ow_INPUT_LOCK -j DROP
-A ow_OUTPUT -d 10.10.10.0/24 -j ow_LAN
-A ow_OUTPUT -m owner --uid-owner 10043 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -m comment --comment "Allow Orbot outputs" -j ACCEPT
protoent* getprotobynumber(int)(3) is not implemented on Android
-A ow_OUTPUT -d 127.0.0.1/32 -p udp -m owner --uid-owner 0 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -m udp --dport 5400 -m comment --comment "Allow System DNS queries" -j ACCEPT
-A ow_OUTPUT_LOCK -m owner --uid-owner 10043 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
-A ow_OUTPUT_LOCK -j DROP

---

shell@android:/ # iptables -t nat -S

-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N natctrl_nat_POSTROUTING
-N oem_nat_pre
-N ow_OUTPUT
-A PREROUTING -j oem_nat_pre
-A OUTPUT -j ow_OUTPUT
-A POSTROUTING -j natctrl_nat_POSTROUTING
-A ow_OUTPUT -d 10.10.10.0/24 -j RETURN
-A ow_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ow_OUTPUT -m owner --uid-owner 10043 -m comment --comment "Orbot bypasses itself." -j RETURN
protoent* getprotobynumber(int)(3) is not implemented on Android
-A ow_OUTPUT -p udp -m owner --uid-owner 0 -m udp --dport 53 -m comment --comment "Allow DNS queries" -j REDIRECT --to-ports 5400

---

[infinity0]

Even when DNS works, it appears they are not routed over tor - e.g. I can visit check.torproject.org but not any onion addresses.

[infinity0]

Alright I think I managed to figure out how to temporarily manually bash it into shape, but I think the bug is still present and will probably bite me again (so it might be necessary to repeatedly do the below).

How .onion over TransProxy works is, the application performs a DNS request for x.onion [1] which gets forwarded by the REDIRECT rules to Tor's DNSProxy. Tor will give a fake 10.x.x.x address, which the application will try to contact, which gets forwarded again by the REDIRECT rules to Tor's TransProxy. Tor sees the request for this fake 10.x.x.x address and knows it is for x.onion, so it handles it accordingly. More info here.

Sometimes this sequence breaks, and it's unclear exactly how. I had some success doing some combination of the following:

• run ndc resolver flushnet local and ndc resolver flushnet lo to flush the DNS cache. Various resources on the internet says lo but the source code suggests "local" is what is actually needed. Both commands give me 200 0 Resolver command succeeded, in fact I get this even when replacing "lo" with any string, so it's hard to tell if this actually does anything. This is CM-13 (Android 6.0.1) on a Nexus 5X.
• run host <your onion address>, it will hopefully give you a result, and put this in /system/etc/hosts. don't forget to remove it afterwards, because this address is only valid temporarily.

More info available by:

• netstat -ln
• tcpdump -ni lo
• going into Orbot settings, enabling debug logs, then run adb logcat Tor:I *:S. Don't forget to disable again afterwards because it really is quite a lot of logs.

[1] except Firefox blocks this unless network.dns.blockDotOnion is overridden to false, it's unclear how to set that on the android Firefox however, so you probably can't visit onion sites on a orwall-REDIRECTED Firefox. Orfox completely bypasses this - it goes through the SOCKS proxy - so that works.