[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Fwd: Orbot v15.1.0 Alpha 1
Nathan Freitas wrote:
I really don't understand how Orbot or Droidwalls iptables rules are
co-existing with Android VPN. This is really a new one for me. I will
make sure transproxy is working on Android 5.1 though, so that at least
we can be sure we didn't break anything.
I have completely re-defined the "transproxy" feature using iptables rules in the nat table. Transproxy in orbot is completely de-activated (I don't use it at
all). Didn't trust the Orbot transproxy feature as:
1. It was returning icmp codes instead of dropping the packets silently (standard practice in firewalling);
2. Allows full net access to selected applications (I need to have the ability to specify which application should be allowed to transproxy which
protocols/ports, not just proxying everything with no control over anything).
Basically, my custom droidwall script clears everything up everywhere (including ipv6, "nat" and "raw" tables in both ipv4 and ipv6) and starts from scratch - I
completely re-define *all* iptables rules, thus keeping close control of everything.
Droidwall has, in my view, a design flaw when executing the custom script *before* doing its own thing (defining another chain called "droidwall" and piling
everything up in it, plus it also doesn't make use of the connection tracking in the kernel), so when I replaced the standard iptables executables with dummy
ones (no-ops), I hit two birds with one stone - prevented droidwall messing around with my iptables rules and also prevented somebody else (an app, an
adversary) using the standard iptables executables for nefarious purposes.
Sorry, going off on a tangent a bit here...
3. Orbot simply ignores what I have specified as Socks, Transproxy and
DNSPorts to be used. Example: in my configuration I specify the interface
to be used
explicitly, i.e. "127.0.0.1:5400" as DNS port (this was the only way I
could get it to work in the "latest" stable Orbot version). I tried
variations of that
configuration (i.e. specify just the port number), but that didn't work
either.
That is strange. It shouldn't ignore that. This is configured in the
Orbot individual settings values, or through torrc entries?
Through the GUI settings. Can't use "DNSPort" because of "DNSPort auto" definitions and the fact that tor chokes on it (see below).
4. No matter what I configure in my settings, Orbot (both versions)
always generates torrc file that contains "SocksPort auto", "DNSPort
auto" and "TransPort
auto". Why? I know that it closes the old (auto-generated) ports and
re-opens different ones (as per my custom torrc) later, but that should
not be the case and
it should honour what I have specified in my configuration.
Can you just clarify what you mean my your configuration? Is that via
Orbot settings, or a torrc file somewhere?
Both. The GUI options allow for configuration of some torrc properties, but there is also an option to specify a custom torrc - that is where I include the rest
of my torrc definitions, but because of, say, "DNSPort auto", I cannot use "DNSPort" as it is already defined "by default".
5. There is no GeoIP database supplied with any Orbot version, which
makes all GeoIP-related commands I issued in my custom torrc completely
useless. I had to
copy these files from my desktop tor version in order to make this work
(Orbot is supposed to "come with tor", but apparently not everything is
included).
There is GeoIP but it only unpacks it from the APK if you specify rules
in Orbot settings that need it.
It should, in my view, always unpack these files. What happens if I don't use any options at the point of installation, but include these in my custom torrc
file at some late point. What then?
Again, you are hand modifying the torrc file which isn't our expected method of use.
You are presenting the user with an option to add custom torrc definitions, so Orbot should, therefore, cater for whatever is in there (and that includes GeoIP
declarations!).
and it works OK from what I can see, though both Tor versions suffer from
bug #9972 I submitted nearly 3 years ago, which is still open.
This is not an Orbot specific issue though, right?
Correct.
Another axe to grind with tor is its inability to specify binding
interface for the various ports it uses. It currently requires an IP
address
(<ip_address>:<port>). That format can't be used when I have VPN running
or have an interface that has a dynamic IP address for example. I'd like
to be able to
specify, say, "DNSListenAddress tun0:7253" for example.
Again, Tor and not Orbot, but yes, that would be useful!
Yep, correct also.
Thanks for the very detailed notes. I will try to reproduce what you are
seeing.
No worries - let me know if you need any information from me.
I have been running the old (stable) Orbot for nearly a week now without any issues. Pleasantly surprised how it adjusts to changing IP addresses when my VPN
connects/disconnects (by the way, I do not use the VPN which comes with the stock android - I use the VPN apk which comes from the guardian project and the
FDroid repo!).
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk