[tor-dev] tor-fw-helper redux

[Yawning Angel]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20141026/971b718c/attachment.sig>