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,
--
Yawning Angel
Attachment:
pgpT0s_n8khTF.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev