(This is a very old thread, but I wanted to post our final resolution to the problem in the same thread so it's easily linked to on the Nabble archive.)<div><br></div><div>Because our campus uses 1-to-1 NATing (ea<span style>ch machine on the campus network has both an internal and an external IP address), we had to move our Opensim server to the DMZ and have it assigned a static external IP address in order for off campus users to connect. </span></div>
<div><span style><br></span></div><div><span style>Through this thread, we discovered </span><span style>O</span><span style>pensim does the DNS resolution for the remote client and spits out whatever the IP address resolves to locally, which means no matter what combination of IP address or hostname is listed in the region.ini file, so long as the hostname resolves to an internal IP address from inside the network, no one from outside could connect. The only option was to bypass the 1-to-1 NATing and have an external static IP address assigned, and then everything worked perfectly from both on and off campus.</span></div>
<div><font color="#222222" face="Arial"><br></font></div><div><font color="#222222" face="Arial">Hope this helps anyone else on a similar network setup and many thanks again to everyone who helped us figure out what was happening under the hood. :)</font></div>
<div><font color="#222222" face="Arial"><br></font></div><div><font color="#222222" face="Arial">- Chris/Fleep</font></div><div><font color="#222222" face="Arial"><br></font></div><div><font color="#222222" face="Arial">Chris M. Collins (SL/OS: Fleep Tuque)</font></div>
<div><font color="#222222" face="Arial">Center for Simulations & Virtual Environments Research (UCSIM)</font></div><div><font color="#222222" face="Arial">UCIT Instructional & Research Computing</font></div><div><font color="#222222" face="Arial">University of Cincinnati</font></div>
<div><font color="#222222" face="Arial">406A Zimmer Hall</font></div><div><font color="#222222" face="Arial">315 College Drive</font></div><div><font color="#222222" face="Arial">PO BOX 210088</font></div><div><font color="#222222" face="Arial">Cincinnati, OH 45221-0088</font></div>
<div><font color="#222222" face="Arial"><a href="mailto:chris.collins@uc.edu">chris.collins@uc.edu</a></font></div><div><font color="#222222" face="Arial">(513) 556-3018</font></div><div><font color="#222222" face="Arial"><br>
</font></div><div><font color="#222222" face="Arial"><a href="http://ucsim.uc.edu">http://ucsim.uc.edu</a><br></font><br><div class="gmail_quote">On Tue, Apr 5, 2011 at 3:25 PM, Gary Beck <span dir="ltr"><<a href="mailto:gab4gab@gmail.com">gab4gab@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Teravus,<br>
Thank you for that explanation. I guess nothing is simple. The more I tested the less clear it was exactly how things worked.<span class="HOEnZb"><font color="#888888"><br>
- Gary</font></span><div class="im HOEnZb"><br>
<br>
----- Original Message ----- On April 05, 2011 "Teravus Ovares" said:<br>
Subject: Re: [Opensim-users] NAT & Corporate Firewall<br>
<br>
<br></div><div class="im HOEnZb">
We've had this discussion before on this list so you might be able to<br>
dig in the archives for the long winded answer.<br>
<br>
The short winded answer is this: The UDP protocol requires that the<br>
login server and any 'region connect' messages have an IP address in<br>
the response to the client. If the UDP protocol allowed you to only<br>
send a hostname, then this wouldn't be an issue. As far as the<br>
region looking up it's DNS info, neither the login server, or the<br>
region has enough of a network structure understanding to manage that<br>
'external ip/internal ip' thing better at the moment. Ideally,<br>
someone could write a subnet matching/ip rewriting scheme that gets<br>
sent to the login server so that the login server could supply the<br>
correct IP address based on the connecting client ip but it's probably<br>
going to be a lot of work to refactor that in because of the<br>
complexities of the object RegionInfo and how it interacts with the<br>
various types of grid services, (standalone, grid, standalone grid,<br>
hypergrid... etc).<br>
<br>
One thing that I think is important to note. I vaguely remember<br>
something about sending the client 0.0.0.0 and triggering the client<br>
to do the lookup but, at the time, the client had some bugs that<br>
prevented it from working. That might be a more feasable way to move<br>
forward. Test that option.<br>
<br>
-Teravus<br>
<br>
<br></div><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
Opensim-users mailing list<br>
<a href="mailto:Opensim-users@lists.berlios.de" target="_blank">Opensim-users@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-users" target="_blank">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-users</a><br>
</div></div></blockquote></div><br></div>