<br><br><div class="gmail_quote">On Fri, Jun 20, 2008 at 8:04 AM, Stefan Andersson <<a href="mailto:stefan@tribalmedia.se">stefan@tribalmedia.se</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">




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

 <br>
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)<br>
 <br>
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.<br>
 <br>
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.<br>
 <br>
Which gets complex.<br></div></blockquote><br>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:<br>
<br>1) upon the registration, the region sends its IP "as seen locally" <br><br>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.<br>
<br>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.<br>
<br>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...<br>
<br>any pitfalls in the above quick write up that I've missed ?<br><br>/d<br><br><br></div>