Brian Warner <[email protected]> writes:

> 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.

Thanks.  I set to

   rfc1918adddress:port,dyndns-name:port

and things seemed to work.  I am boggled by 127.0.0.1, but I'm trying to
get other clients behind the same NAT to work, not other clients on the
same box.


Attachment: pgpzLMlBtMacZ.pgp
Description: PGP signature

_______________________________________________
tahoe-dev mailing list
[email protected]
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev

Reply via email to