Hello,
"You are in a maze of twisty little firmwares, all terrible".
I'm at the point where the new and improved firewall helper could use some additional testing by various users, though there's some issues with the design that still need to be resolved. But not being one to keep issues inherited from the original from stopping progress...
Code: https://github.com/yawning/go-fw-helper Bug: https://trac.torproject.org/projects/tor/ticket/13338
Yes, it's another Go app. It should work both as a helper for tor (PortForwardingHelper in the torrc), and for flashproxy. I am currently only concerned about the latter use case since it will immediately make flashproxy more useful in various environments, and I'm not sure people that can't setup port forwarding should be running relays in the first place.
How to test it: $ go build github.com/yawning/go-fw-helper
One of: * Play with it by hand. "-h" dumps usage. * Edit the torrc-defaults file shipped with Tor Browser to have flashproxy use the helper. On the Linux bundle the file in question is located at tor-browser_en-US/Browser/TorBrowser/Data/Tor
The flashproxy ClientTransportPlugin line should look something like: ClientTransportPlugin flashproxy exec ./TorBrowser/Tor/PluggableTransports/flashproxy-client --port-forwarding-helper=/path/to/go-fw-helper --register :0 :9000
You *can* edit where it says "9000" to use a different port, but having it auto assigned will lead to it being harder to remove when done.
* Try running a tor relay using PortForwardingHelper. I personally don't recommend this, and haven't tested it at all, but there's no reason why it won't work unless the tor side of the code rotted (unlikely?).
Caveats: * Not sure which version of the Go compiler/runtime this requires. Development was done on 1.3.3. It probably requires 1.2.x but it may work on older versions (Not a bug/WONTFIX). * UPnP discovery requires being able to listen on a UDP traffic and accept incoming packets. Your local firewall may prevent this. (Not a bug/WONTFIX). * flashproxy does not know how to deal with mappings expiring, so things will stop working after 2 hours if NAT-PMP is used. * Neither flashproxy nor tor know how to use go-fw-helper to delete mappings, because tor-fw-helper did not have such a thing.
WARNING: If UPnP is used as the protocol, mappings are indefinite. You will need to use the router's admin interface or "go-fw-helper -d" to remove it. Yes, there is a very good reason why this is like this, despite the protocol on paper having the length as a registration time parameter.
Note: NAT-PMP mappings obtained by go-fw-helper last for 2 hours.
* go-fw-helper's "-T" option doesn't do everything tor-fw-helper's does. (Meh?) * The UPnP mapping description is hard coded to "Tor relay" to match tor-fw-helper.
Useful extensions over tor-fw-helper:
Dump all current mappings with: $ go-fw-helper -l
Remove mappings with: $ go-fw-helper -d ([<external port>]:<internal port>]
Both of those options only work with UPnP because NAT-PMP does not have a method of querying mapping information, and because at least one NAT-PMP implementation deployed on a lot of routers does not handle removal correctly (Bug reported to maintainer, and fixed in master but people do not update router firmware enough. There is a way to force go-fw-helper to let you delete port forwarding entries, but it's intentionally undocumented, because I don't want to support it.)
Force a certain protocol (Case sensitive): $ go-fw-helper --protocol=NAT-PMP ... $ go-fw-helper --protocol=UPnP ...
Tested on: * 64 bit Linux * 64 bit FreeBSD 9.3 * 32 bit Windows 7
Need testing on: * Darwin (esp with NAT-PMP) * With more routers than the 2 I have immediate access to. If something breaks "-v" gets you debug output.
Questions, Comments, Feedback appreciated,
On Sun, Oct 26, 2014 at 08:41:08AM +0000, Yawning Angel wrote:
Hello,
"You are in a maze of twisty little firmwares, all terrible".
I'm at the point where the new and improved firewall helper could use some additional testing by various users, though there's some issues with the design that still need to be resolved. But not being one to keep issues inherited from the original from stopping progress...
Code: https://github.com/yawning/go-fw-helper Bug: https://trac.torproject.org/projects/tor/ticket/13338
This is great. Is there any reason not to call it tor-fw-helper, and replace/deprecate the existing src/tools/tor-fw-helper?
I'm thinking that as a conservative step, we should first deploy using a static external port for flash proxy. An ephemeral port is better for scanning resistance, but there is also the risk of poking long-lasting holes in firewalls and overflowing port forwarding tables in these shoddy routers.
We need at least to add a loop to where flashproxy-client calls the port forwarding helper. Ideally we would also try to remove the mapping before exiting. We could do it in the first SIGINT handler--though we know that SIGINT handling doesn't work on Windows because tor immediately zaps you with TerminateProcess. We could do something like we do with terminateprocess-buffer and meek-client-torbrowser, and add an --exit-on-stdin-eof option to flashproxy-client so that it can detect when it is supposed to shut down gracefully. I'm not sure it's worth it though, especially if unmapping ports is unreliable.
We'll need a tor-browser-bundle branch that builds go-fw-helper and adds it to the ClientTransportPlugin line. I'll look at adding the flashproxy-client loop.
- The UPnP mapping description is hard coded to "Tor relay" to match tor-fw-helper.
Is there any way to omit it or leave it blank? I thought there was a ticket somewhere about "Tor relay" making Tor use more conspicuous, but I can't find it now.
David Fifield
On Sun, 26 Oct 2014 02:07:26 -0700 David Fifield david@bamsoftware.com wrote:
On Sun, Oct 26, 2014 at 08:41:08AM +0000, Yawning Angel wrote:
Hello,
"You are in a maze of twisty little firmwares, all terrible".
I'm at the point where the new and improved firewall helper could use some additional testing by various users, though there's some issues with the design that still need to be resolved. But not being one to keep issues inherited from the original from stopping progress...
Code: https://github.com/yawning/go-fw-helper Bug: https://trac.torproject.org/projects/tor/ticket/13338
This is great. Is there any reason not to call it tor-fw-helper, and replace/deprecate the existing src/tools/tor-fw-helper?
No particular reason for the former. This could even be done at the packaging step since I kind of don't want to move the repo. I think, assuming people like my stab at this, that having it live in it's own space under git.tp.o somewhere would be best.
I'm thinking that as a conservative step, we should first deploy using a static external port for flash proxy. An ephemeral port is better for scanning resistance, but there is also the risk of poking long-lasting holes in firewalls and overflowing port forwarding tables in these shoddy routers.
Indeed. It has no external dependencies so adding it to the build process should be trivial, just not something I've bothered with yet.
We need at least to add a loop to where flashproxy-client calls the port forwarding helper. Ideally we would also try to remove the mapping before exiting. We could do it in the first SIGINT handler--though we know that SIGINT handling doesn't work on Windows because tor immediately zaps you with TerminateProcess. We could do something like we do with terminateprocess-buffer and meek-client-torbrowser, and add an --exit-on-stdin-eof option to flashproxy-client so that it can detect when it is supposed to shut down gracefully. I'm not sure it's worth it though, especially if unmapping ports is unreliable.
I would think it's worth trying to do so, particularly if ephemeral ports are used. NAT-PMP mappings (the one that has routers that have trouble unmapping), have a sane lifespan (currently 2h, but changing this is trivial). As far as I know removing UPnP mappings should always work, and that's the protocol that needs infinite duration mappings due to firmware badness.
There's no harm in trying to unregister mappings. Unless the undocumented flag is set, go-fw-helper will just fail to remove NAT-PMP mappings with an internal error.
I changed the reporting for the deregistration process to mostly match the registration as well, so automating this is straight forward.
I may reconsider disallowing NAT-PMP deregistration since the router side implementation where I found the bug supports both UPnP and NAT-PMP, and so in such environments UPnP should be used anyway due to how the code is setup.
We'll need a tor-browser-bundle branch that builds go-fw-helper and adds it to the ClientTransportPlugin line. I'll look at adding the flashproxy-client loop.
- The UPnP mapping description is hard coded to "Tor relay" to
match tor-fw-helper.
Is there any way to omit it or leave it blank? I thought there was a ticket somewhere about "Tor relay" making Tor use more conspicuous, but I can't find it now.
It's a constant in the UPnP code. This is also trivial to omit/change, if people want it to be different, but having it well defined makes the admin side of things easier. NAT-PMP doesn't have a description field.
As a side note, before I sent the e-mail, I was browsing the web for a bit with flashproxy configured to use the helper, so at least in my test environment things work as expected.
-
David Fifield -
Yawning Angel