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,