[tahoe-dev] dealing with NAT

[Brian Warner]

On 2/2/11 8:44 AM, Greg Troxel wrote:
> 
>   Most of the nodes on VolunteerGrid2 are set up behind routers with
>   port-forwarding to the nodes. With the exception of one 6+ year old
>   router, it is working we haven't experienced any problems. (The
>   router in question is scheduled for replacement.)
> 
> By 'it is working', do you mean that tahoe client nodes which are
> behind the same nat as one of the servers can store shares on those
> servers? If so, is the NAT box doing NAT on those packets even though
> they arrive on the internal vs external interface, or is tub.locations
> configured as I asked, or something else?

For reference, in NAT-plus-port-forwarding environments, you should
probably set your tub.location to something like
"127.0.0.1:55555,externalip.example.org:55555" (assuming a 1:1 inbound
port-forwarding). Everybody will try both ports, but internal hosts will
succeed with the first hint, and external hosts will succeed with the
second. Foolscap tries all hints in parallel, starts SSL on any that
finish TCP, starts foolscap negotiation on any that finish SSL, and uses
the first one that finishes foolscap negotiation (and drops any that
don't). So multiple hints are the Right Way to handle funky
split-horizon things like that.

> One could also say that in a volunteergrid type system it may be just
> as well not to use your own server.

Foolscap uses a special local loopback when you ask Tub "A" to use an
object also hosted on Tub A: it doesn't even touch the network (it just
inserts fireEventually() barriers to retain the usual Far-reference
ordering behaviors). So leaving out the 127.0.0.1 hint won't prevent a
client from using itself as a server. (It might prevent one host behind
your NAT box from connecting to a different host behind your NAT box, or
to a different Tahoe process running on that same host, but if your NAT
box does "hairpin routing" then it'll still get through).

cheers,
 -Brian