[Opensim-dev] A software to connect its own region and TP in from locally...

[Dalien Talbot]

On Fri, Jun 20, 2008 at 8:04 AM, Stefan Andersson <stefan at tribalmedia.se>
wrote:

>
> The issue you're seeing is known as the 'NAT bounce' or 'NAT
> loopback' issue - your router only translates and/or forwards traffic
> crossing the LAN-WAN border, which means that if you access your computer
> with the _external_ IP from _within_ the LAN, the traffic isn't 'bounced'
> back into the LAN, but is lost.
>
> Normally, you would solve this by simply address the computer with your
> _internal_ IP from the inside (typically, you have host file settings or an
> internal dns that serves internal ip's within the LAN)
>
> now, things are getting complicated with the Second Life viewer, as the
> viewer demands regions be addressed with _IP_, not host name, so the viewer
> never resolves anything, so host magic won't work.
>
> so, on login and teleports, when the grid tells the viewer where to start,
> it would have to serve you your _internal_ IP - but your _external_ ip to
> the rest of the world.
>
> Which gets complex.
>

I think the vast majority of the cases (in the case the outbound connections
are masked behind the same IP as the one used for the inbound port
redirection) could be taken care of by a modification of the grid
registration/teleport logic:

1) upon the registration, the region sends its IP "as seen locally"

2) the grid server takes that IP (denote as privateIP), as well as the IP it
sees as source (denote it as publicIP) and keeps in the registration
database.

3) upon the teleport request, the sending region informs the grid server
about the IP of the client. The grid server compares this IP with publicIP -
if they are the same, means the client is behind the home router - so the
grid server returns the privateIP which the originating region uses to send
the user to the target region. If the clientIP and publicIP are different -
then the assumption is that the client and the server are on the different
sides of the NAT - so the publicIP is used for the teleport.

The (1) can be extended to also include N "known public client addresses"
into the registration - so the condition for giving out the privateIP within
the teleport packet is the equality of the client IP to any of those...

any pitfalls in the above quick write up that I've missed ?

/d
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080624/ed8dde1f/attachment-0001.html>