Network Settings

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
m (minor formatting cleanup)
 
(64 intermediate revisions by 18 users not shown)
Line 1: Line 1:
OpenSim/Grid can be pretty tricky when it comes to setting it up on a private network this document covers what OpenSim needs in terms of network resources.
+
{{Quicklinks}}
 +
<br />
  
==Ports used by OpenSim==
+
= Introduction =
  
===Grid===
+
These are instructions for making an OpenSimulator installation accessible externally through a firewall or router. Please note that if you are using consumer network hardware, you will need a router that supports NAT loopback. See [[NAT Loopback Routers]] if you want give both LAN and external users access.
  
* TCP/8000 - Reserved
+
For help on general connection issues, see [[Troubleshooting#Networking and config issues]].
* TCP/8001 - Grid Server - Regions and other grid services talk to this
+
 
* TCP/8002 - User Server and Login Services - Clients, Regions, and other grid services talk to this
+
= Standalone Mode =
* TCP/8003 - Asset Services - Regions and other grid services talk to this
+
== TCP ==
* TCP/8004 - Inventory Services - Regions and other grid services talk to this
+
 
* TCP/8005 - Reserved (Dispatch Services)
+
* '''TCP/9000'''
* TCP/8895 - needed for region to region communications
+
 
* UDP+TCP/9000 - Default First Simulator - grid, regions, and clients talk to these
+
The http_listener_port configured in the [Network] section of OpenSim.ini needs to be accessible externally.  By default this is 9000.
* UDP+TCP/9001 - Default Second Simulator - grid, regions, and clients talk to these
+
 
* UDP+TCP/900x - Each next simulator...
+
In standalone mode this provides
 +
 
 +
* HTTP access to the simulator (needed for the capabilities protocol, amongst other things.
 +
* HTTP access to public services, such as as login.
 +
 
 +
In standalone mode, no private service port is exposed since all simulator to service communication occurs internally within the OpenSim.exe process.
 +
 
 +
If you have XMLRPC active for in-world scripts (http://wiki.secondlife.com/wiki/Category:LSL_XML-RPC) (this is not active by default), then you will also need to make the XmlRpcPort configured in the [XMLRPC] section of OpenSim.ini accessible by external systems.  By default, this is '''TCP/20800'''.
 +
 
 +
== UDP ==
 +
 
 +
* '''UDP/9000-9xxx'''
 +
 
 +
The configured InternalPort of each region needs to be accessible for UDP traffic from the viewer (to exchange movement data, object information, etc.).  These configuration files are found in the bin/Regions/ directory.  The usual port for the first region is 9000, but each region needs its own port (usually then 9001, 9002, etc.). However, any other set of ports can also be configured.
 +
 
 +
== IP Address ==
  
===StandAlone===
+
In the region configuration files found in bin/Regions/, each region will have an ExternalHostName configured.  For example,
* UDP+TCP/9000 - Everything runs on this port
+
  
===Initial setup===
+
<source lang="ini">
* Check your /bin/Regions/default.xml
+
ExternalHostName = 82.73.39.77
It shows something like this:
+
<source lang =xml>
+
<Config sim_UUID="1e988108-76ec-45db-b89e-4ba98905681c" sim_name="mysimname" sim_location_x="1000" sim_location_y="1000"  
+
internal_ip_address="192.168.2.101" internal_ip_port="9000" allow_alternate_ports="false"
+
external_host_name="82.73.39.77" master_avatar_uuid="00000000-0000-0000-0000-000000000000"
+
estate_covanant_uuid="00000000-0000-0000-0000-000000000000"
+
master_avatar_first="test" master_avatar_last="user" master_avatar_pass="******" />
+
 
</source>
 
</source>
* Retrieve your [http://www.ip-adress.com/ external_host_name]
 
* Get your internal_ip_address (ipconfig for windows, or ifconfig for linux)
 
* Make sure the settings match
 
  
If you have a router in front of your internet-modem, check out ''NAT and Port Forwarding''.
+
For viewers external to your LAN to contact your installation, this must be directly accessible from their location. In the most basic case, your server would be directly accessible from the Internet.
Else you're good to go.
+
  
==NAT and Port Forwarding ==
+
# Retrieve your [http://www.ip-adress.com/ external_host_name]
===Straightforward===
+
# Get your internal_ip_address (using ipconfig for windows, or ifconfig for linux)
If your host does not have a public IP address (eg it is hidden behind a home router) you will have issues hosting grid and region servers if you plan on connecting clients to it on both sides of the router, however this can be worked around through the use of port forwarding and ip-redirecting.
+
# Make sure the settings match
  
* Set internal_ip_address to your local LAN-ip(e.g. 192.168.2.1) (region xml-file)
+
If you're running a simulator at home, it's much more likely that access to your LAN runs through a router which does not make your computer accessible via the Internet. For more information on this, check out the ''NAT and Port Forwarding'' section below.
* Set the external_host_name to your external IP-Address (Not a hostname, since DNS-resolving doesn't work properly) (region xml-file)
+
* Forward the appropriate ports to the OpenSim-server on both UDP and TCP (router-setup)
+
* Reroute traffic for '''Linux:'''
+
** iptables -t nat -A OUTPUT --dst $EXTERNAL_IP -p tcp --dport 9000:9010 -j DNAT --to-destination $INTERNAL_IP
+
** iptables -t nat -A OUTPUT --dst $EXTERNAL_IP -p udp --dport 9000:9010 -j DNAT --to-destination $INTERNAL_IP
+
Those iptables lines will redirect any traffic going to $EXTERNAL_IP on ports 9000 to 9010 to $INTERNAL_IP. The internal ip is the LAN-IP of your server, and External ip is your internet IP.
+
''Use the above iptables command on all internal machines'' except your gateway/router. This assumes your gateway/router machine does not also host your sim. This also assume you have a default ACCEPT policy on your internal machines. So to connect from within your LAN, use the above iptables commands to reroute the traffic to the server internal ip.
+
* Reroute traffic for '''Windows:'''
+
** netsh (please find out how this works!)
+
  
Optional:
+
= Grid Mode =
* Register an external domain-name (for external connections)
+
 
 +
== Simulator ==
 +
 
 +
* '''TCP/9000'''
 +
* '''UDP/9000-9xxx'''
 +
 
 +
For each simulator on your grid, the same ports as described for the standalone situation above need to be accessible to external viewers.  Although public services are not handled by OpenSim.exe in this configuration, the simulator HTTP port still needs to be available for other viewer <-> simulator communication mechanisms (e.g. capabilities).
 +
 
 +
== Services ==
 +
 
 +
* '''TCP/8002'''
 +
* '''TCP/8003''' (internal only, see below)
 +
 
 +
In the standalone configuration, both simulator and services are contained within a single process (OpenSim.exe).
 +
 
 +
However, in the grid configuration, services run separately in one or more Robust.exe shells.
 +
 
 +
Some of these services, such as login, need to be accessible to viewers.
 +
 
 +
In the default Robust.exe configuration, these are all served on the public port 8002.  These needs to be accessible by external viewers.
 +
 
 +
However, in the grid configuration there are also a set of private services (asset, inventory, etc.). By default, these run on port 8003 (TCP only) and it should not be made accessible to viewers. In a closed grid port 8003 should only be accessible to the machines which are being used to run the grid. If Robust and all OpenSim instances running regions are on a single machine no external access to port 8003 should be allowed.
 +
 
 +
= Optional and Add-on Module Specific Ports =
 +
 
 +
== FreeSWITCH Voice ==
 +
 
 +
* '''TCP+UDP 5060''' - SIP Ports (5060 for default call profile)
 +
* '''TCP+UDP 1720''' - H.323 ports for call setup
 +
 
 +
More details on the Freeswitch ports used and firewall configuration details are at:
 +
 
 +
* [[Freeswitch Module#Firewall Config]]
 +
* http://wiki.freeswitch.org/wiki/Firewall
 +
 
 +
== Mumble Voice ==
 +
 
 +
* SIP Ports
 +
* ICE Ports
 +
 
 +
= NAT and Port Forwarding =
 +
 
 +
== Straightforward ==
 +
 
 +
If your host does not have a public IP address (eg it is hidden behind a home router) you will have issues hosting grid and region servers if you plan on connecting clients to it on both sides of the router, however this can be worked around through the use of port forwarding and ip-redirecting.This will also correct issues where the client hangs at region handshake.<br />
 +
 
 +
* Set internal_ip_address to your local LAN-ip(e.g. 192.168.2.1) (regions.ini file)
 +
* Set the external_host_name to your external IP-Address (Not a hostname, since DNS-resolving doesn't work properly) (regions.ini file)
 +
* Forward the appropriate ports to the OpenSim-server on both UDP and TCP (router-setup)
 +
* Open appropriate ports on the OpenSim-server's firewall on both UDP and TCP<br />
 +
* Reroute traffic for '''Linux:'''
 +
** iptables -t nat -A OUTPUT --dst '''''EXTERNAL_IP''''' -p tcp --dport 9000:9010 -j DNAT --to-destination '''INTERNAL_IP'''
 +
** iptables -t nat -A OUTPUT --dst '''''EXTERNAL_IP''''' -p udp --dport 9000:9010 -j DNAT --to-destination '''''INTERNAL_IP'''''
 +
** service iptables restart<br />
 +
 
 +
Those iptables lines will redirect any traffic going to '''''EXTERNAL_IP''''' on ports 9000 to 9010 to I'''''NTERNAL_IP'''''. The internal ip is the LAN-IP of your server, and External ip is your internet IP. ''Use the above iptables command on all internal machines'' except your gateway/router. This assumes your gateway/router machine does not also host your sim. This also assume you have a default ACCEPT policy on your internal machines. So to connect from within your LAN, use the above iptables commands to reroute the traffic to the server internal ip.
 +
 
 +
* Reroute traffic for '''Windows:'''
 +
** netsh (this method needs experimentation and elaboration. Please see the [[Talk:Network Settings|Discussion page]] for some guesswork on where to start)
 +
*** note from paulieFlomar: I tried using Windows built-in tools like FireWall, netsh, and IP Security Policy. My experience with these tools was unsuccessful. I then tried to create an outgoing rule with some third-party firewall products. I tried ZoneAlarm and Sunbelt Firewall. Neither of these products would allow me to create outgoing rules. Finally, I tried creating an outgoing rule in my Linux IP Tables firewall. This worked. I created 2 rules which I placed in a firewall script, before my NAT rule. The rules were:
 +
 
 +
iptables -t nat -A PREROUTING --dst '''''EXTERNAL_IP''''' -p tcp --dport 9000:9010 -j DNAT --to-destination '''''INTERNAL_IP'''''
 +
 
 +
iptables -t nat -A PREROUTING --dst '''''EXTERNAL_IP''''' -p udp --dport 9000:9010 -j DNAT --to-destination '''''INTERNAL_IP'''''
 +
 
 +
These rules worked. I can now access my region from my LAN.
 +
 
 +
Optional:
 +
 
 +
* Register an external domain-name (for external connections)  
 
* Use Bind for internal domain-name resolving
 
* Use Bind for internal domain-name resolving
  
===DynDNS loopback===
+
== DynDNS loopback ==
  
This method was used and successfully tested using www.dyndns.com (creates a virtual domain for your pc/ip, like yourcomputer.ath.cx) as loopback for devices on a LAN with three machines (pentium 2.8ghz running windows xp - internet server , amd opteron running ubuntu 7.10 64bit - as opensim server - and MacBook with OSX 10.4.11 - as client), a modem (thomson/alcatel speedtouch 330) and a mini-switch (which brand no one ever heard of). The connection of these machines is made as following: Modem -> Win Pc -> Switch -> Mac and Ubuntu. Dyndns is used to loopback to the Win Pc, and then it forwards the request to the internal LAN opensim server, which grants everything for the client. As for the client, if he is inside the private LAN then he is now actually someone on the internet requesting for access to the opensim server. Thus, if the client is someone on the internet then he will be treated like that. Tricky ? Further details ahead:
+
This method was used and successfully tested using www.dyndns.com (creates a virtual domain for your pc/ip, like yourcomputer.ath.cx) as loopback for devices on a LAN with three machines (pentium 2.8ghz running windows xp - internet server , amd opteron running ubuntu 7.10 64bit - as opensim server - and MacBook with OSX 10.4.11 - as client), a modem (thomson/alcatel speedtouch 330) and a mini-switch (which brand no one ever heard of). The connection of these machines is made as following: Modem -&gt; Win Pc -&gt; Switch -&gt; Mac and Ubuntu. Dyndns is used to loopback to the Win Pc, and then it forwards the request to the internal LAN opensim server, which grants everything for the client. As for the client, if he is inside the private LAN then he is now actually someone on the internet requesting for access to the opensim server. Thus, if the client is someone on the internet then he will be treated like that. Tricky&nbsp;? Further details ahead:  
  
Method:
+
Method:  
* Set the simulator listening IP address to your dyndns domain - edit ''opensim/bin/Regions/default.xml''; and change the external_host_name to  ''external_host_name="yourcomputer.ath.cx"''. Leave internal_ip_address "0.0.0.0" and port "9000".
+
* Set the client (SecondLife Viewer) -loginuri to "yourcomputer.ath.cx:8002" (the port used was 8002, yours can be different if you configured it that way) - i didnt used the  -loginserver flag also.
+
* Port Forward the above ports on the internet server (in this case, win xp). You do so by creating exceptions in Windows Firewall for the above mentioned ports, and for both connections: Internet Connection and LAN - this keeps the ports open for the web requests to travel over the private network.
+
* Edit "hosts" file (on windows, this is C:\Windows\System32\Drivers\etc\hosts and on Unix-type systems, this is /etc/hosts) entry on your internet server (in this case, win xp box) and  add the following line: ''xxx.xxx.xxx.xxx<nowiki>&nbsp;&nbsp;&nbsp;&nbsp;</nowiki> yourcomputer.ath.cx''. Of course, xxx.xxx.xxx.xxx is your opensim server internal LAN IP.
+
  
yourcomputer.ath.cx is now available for everyone to connect and you may login with the client!
+
* Set the simulator listening IP address to your dyndns domain - edit ''opensim/bin/Regions/Regions.ini''; and change the external_host_name to ''external_host_name="yourcomputer.ath.cx"''. Leave internal_ip_address "0.0.0.0" and port "9000".
 +
* Set the client (SecondLife Viewer) -loginuri to "yourcomputer.ath.cx:8002"  (the port used was 8002, yours can be different if you configured it that way ie: "yourcomputer.ath.cx:9000 on Standalone mode) - i didnt use the -loginserver flag also. This can be set in the Grid Manager of most third party viewers.
 +
* Port Forward the above ports on the internet server (in this case, win xp). You do so by creating exceptions in Windows Firewall for the above mentioned ports, and for both connections: Internet Connection and LAN - this keeps the ports open for the web requests to travel over the private network.
 +
* Edit "hosts" file (on windows, this is C:\Windows\System32\Drivers\etc\hosts and on Unix-type systems, this is /etc/hosts) entry on your internet server (in this case, win xp box) and add the following line: ''xxx.xxx.xxx.xxx<nowiki>&nbsp;&nbsp;&nbsp;&nbsp;</nowiki> yourcomputer.ath.cx''. Of course, xxx.xxx.xxx.xxx is your opensim server internal LAN IP.
  
===Local connections with ZyXEL DSL modem/router and NAT/Port Forwarding===
+
yourcomputer.ath.cx is now available for everyone to connect and you may login with the client!
 +
 
 +
<br />
 +
 
 +
== DynDNS and the free IPCop Linux Firewall ==
 +
 
 +
Here an other way with the IPCop Linux Firewall, DynDNS and a OpenSimulator server
 +
 
 +
* Setup an IPCop firewall with 3 interfaces (red, green, orange) and put the OpenSimulator server on the orange interface (all OpenSimulator server's on one Linux box). Red is the internet, green is your lan.
 +
* Setup the DynDNS service on the IPCop Firewall.
 +
* change the external_host_name in the default.xml to the DynDNS name
 +
* do'nt change the internal_ip_address in the default.XML, it should be 0.0.0.0
 +
* if there, delete all loopbacks in /etc/hosts only 127.0.0.1 should be localhost
 +
* customize the Port Forwarding on the IPCop Firewall (8002 TCP, 9000 UDP/TCP and for every additonal region 900X UDP/TCP). Port forwarding should be set to the (orange) interface adress of the OpenSimulator Box
 +
 
 +
Then it should be possible to conenct from inside the LAN (green) and it is also possible to conenct from the internet (over the red interface). (well, the inside-lan connections are also made now over the RED interface, but infact, this is in the same ISP network, it should be quit fast&nbsp;;-)
 +
 
 +
* Attention&nbsp;: the ports on the IPCop Firewall must also be open if you connect from inside (green) to your OpenSimulator Grid&nbsp;!
 +
 
 +
If you are using the OS WebGui, do'nt forget to set the "SMTP AUTH" in your email server. Most of the dynamic IPs are blocked at ISP level so the new users do'nt get any confirmation email.
 +
 
 +
This was tested with the Hippo OpenSimulator Viewer and with the Login URL&nbsp;: http://DynDNSName:8002
 +
 
 +
<br />
 +
 
 +
== Local connections with ZyXEL DSL modem/router and NAT/Port Forwarding ==
  
 
This solution works with the ZyXEL Prestige 660ME-61 DSL Router. It may work with other models made by ZyXEL.  
 
This solution works with the ZyXEL Prestige 660ME-61 DSL Router. It may work with other models made by ZyXEL.  
  
Method:
+
Method:  
* Connect by TELNET to your ZyXEL DSL modem. Use the same IP address that you would if you were using the web interface. For example, the default ip on most Embarq ZyXEL DSL modems is 192.168.2.1.  
+
 
 +
* Connect by TELNET to your ZyXEL DSL modem. Use the same IP address that you would if you were using the web interface. For example, the default ip on most Embarq ZyXEL DSL modems is 192.168.2.1.
  
 
  telnet 192.168.2.1
 
  telnet 192.168.2.1
  
* Enter your password. If you do not know it, try just pressing <ENTER> or ask your ISP for the password. They may or may not give it to you.  
+
* Enter your password. If you do not know it, try just pressing &lt;ENTER&gt; or ask your ISP for the password. They may or may not give it to you.
  
* Select menu option "24. System Maintenance" from the menu.  
+
* Select menu option "24. System Maintenance" from the menu.
  
 
                     Copyright (c) 1994 - 2004 ZyXEL Communications Corp.
 
                     Copyright (c) 1994 - 2004 ZyXEL Communications Corp.
Line 94: Line 183:
 
                           Enter Menu Selection Number:
 
                           Enter Menu Selection Number:
  
 +
<br />
  
 
* Select menu option "8. Command Interpreter Mode" from the menu
 
* Select menu option "8. Command Interpreter Mode" from the menu
Line 114: Line 204:
  
 
  Copyright (c) 1994 - 2004 ZyXEL Communications Corp.
 
  Copyright (c) 1994 - 2004 ZyXEL Communications Corp.
  Sprint > ip nat loopback on  
+
  Sprint &gt; ip nat loopback on  
  
 
* At the prompt type "exit".
 
* At the prompt type "exit".
  
  Sprint> exit
+
  Sprint&gt; exit
  
 
* Select menu option "99. Exit"
 
* Select menu option "99. Exit"
  
* Follow all other steps for configuring and starting your server as outlined in [http://opensimulator.org/wiki/Main_Page#Getting_Started_with_OpenSim Getting Started].
+
* Follow all other steps for configuring and starting your server as outlined in [[Main Page#Getting Started with OpenSim|Getting Started]].
  
 +
<br />
  
===Local connections with the DLink GamerLounge Extreme N router===
+
== Local connections with the DLink GamerLounge Extreme N router ==
Networking and router configurations have been responsible for 98% of all trouble I have had setting up and operating OpenSimulator region server software. Insuring that you have a capable router properly configured should be the first thing on the list of configuration checkpoints for a smooth and trouble-free path to OpenSimulator software operations in GridMode.
+
  
Below is a series of screen snapshots with the key pages of my router configuration interface with proper settings displayed.
+
Networking and router configurations have been responsible for 98% of all trouble I have had setting up and operating OpenSimulator region server software. Insuring that you have a capable router properly configured should be the first thing on the list of configuration checkpoints for a smooth and trouble-free path to OpenSimulator software operations in GridMode.  
  
The settings below assume that you have an otherwise working connection and do not touch on such subjects as port conflicts or logging your network onto your ISP's provider network.
+
Below is a series of screen snapshots with the key pages of my router configuration interface with proper settings displayed.  
  
{|
+
The settings below assume that you have an otherwise working connection and do not touch on such subjects as port conflicts or logging your network onto your ISP's provider network.
|[[image:router config snapshot1.png|250px|thumb|'''1.Status''']]
+
 
|[[image:router config snapshot2.png|250px|thumb|'''2.Advanced > Gaming''']]
+
{| class="FCK__ShowTableBorders"
|[[image:router config snapshot3.png|250px|thumb|'''3.Routing''']]
+
|-
 +
| [[Image:Router config snapshot1.png|thumb|250px|1.Status]]  
 +
| [[Image:Router config snapshot2.png|thumb|250px|2.Advanced > Gaming]]  
 +
| [[Image:Router config snapshot3.png|thumb|250px|3.Routing]]
 
|}
 
|}
{|
+
 
|[[image:router config snapshot4.png|250px|thumb|'''4.firewall''']]
+
{| class="FCK__ShowTableBorders"
|[[image:router config snapshot5.png|250px|thumb|'''5.Advanced network settings''']]
+
|-
 +
| [[Image:Router config snapshot4.png|thumb|250px|4.firewall]]  
 +
| [[Image:Router config snapshot5.png|thumb|250px|5.Advanced network settings]]
 
|}
 
|}
  
 
* provided that all information supplied in ~opensim/bin/OpenSim.ini and in your ~opensim/Regions/*.xml are properly configured, this should have you up and running.
 
* provided that all information supplied in ~opensim/bin/OpenSim.ini and in your ~opensim/Regions/*.xml are properly configured, this should have you up and running.
 +
 +
<br />
 +
 +
==Local and Internet connections with Linux iptables and NAT/Port Forwarding== <!-- Contributed by Tony Maro tony@maro.net http://www.ossramblings.com - this is a subset example based on a much larger script I use and I haven't tested this code specifically, but it _should_ work right ;-) -->Please don't copy this verbatim - much more should go into a firewall setup, but this will at a bare minimum get NAT working with forwarding to your OpenSimulator server from both inside and outside your LAN.
 +
 +
Example firewall.sh script: <source lang="bash">
 +
echo 1 > /proc/sys/net/ipv4/ip_forward
 +
echo 1 > /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal
 +
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
 +
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
 +
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
 +
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
 +
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
 +
modprobe nf_conntrack_ftp
 +
modprobe nf_nat_ftp
 +
 +
INT = "eth0" # your internal network card on the firewall
 +
EXT = "eth1" # Your external network card on the firewall
 +
IPTABLES = "/sbin/iptables" # Path to your iptables executable
 +
 +
OPENSIMEXT = "66.102.1.103/32" # Example external IP - replace with yours
 +
OPENSIMINT = "192.168.1.240/32" # Internal IP of your OpenSimulator server
 +
INTSUBNET = "192.168.1.0/24" # Your internal subnet range
 +
 +
# Flush rules when we are restarting the script
 +
$IPTABLES -F
 +
$IPTABLES -F -t nat
 +
$IPTABLES -F -t mangle
 +
 +
# Set up sane defaults
 +
$IPTABLES -P INPUT DROP
 +
$IPTABLES -P OUTPUT ACCEPT
 +
$IPTABLES -P FORWARD DROP
 +
 +
# Allow all connections from inside the network to the firewall on all ports
 +
$IPTABLES -A INPUT -i $INT -j ACCEPT
 +
# Allow all outbound connections from the inside. Much better to limit this...
 +
$IPTABLES -A FORWARD -o $EXT -j ACCEPT
 +
 +
# Configure basic NAT
 +
$IPTABLES -A FORWARD -i $EXT -m state --state RELATED,ESTABLISHED -j ACCEPT
 +
$IPTABLES -t nat -A POSTROUTING -o $EXT -j SNAT --to-source $OUTNAT
 +
 +
# Configure forwarding for OpenSimulator (you need to add ports if you are not running in standalone
 +
# or if you are running more than one region)
 +
$IPTABLES -A PREROUTING -p tcp -d $OPENSIMEXT --dport 9000 -j DNAT --to-destination $OPENSIMINT
 +
$IPTABLES -A PREROUTING -p udp -d $OPENSIMEXT --dport 9000 -j DNAT --to-destination $OPENSIMINT
 +
 +
# Now for the magical juice that lets inside users and outside users both access your server
 +
# Configure to allow internal network users to access the OpenSimulator server using the
 +
# external IP address. This fixes failing to connect to regions over UDP due to NAT config
 +
# Make sure you configure the proper external IP for each of your regions
 +
$IPTABLES -t nat -A PREROUTING -i $INT -s $INTSUBNET -d $OPENSIMEXT -j DNAT --to-destination $OPENSIMINT
 +
$IPTABLES -t nat -A POSTROUTING -o $INT -s $INTSUBNET -d $OPENSIMINT -j DNAT --to-source $OPENSIMEXT
 +
 +
</source>
 +
 +
<br />
 +
 +
NOTE: Contrary to what is displayed above, DHCP services are not required to operate OpenSimulator server software.
 +
 +
<br />
 +
 +
= NAT LoopBack Routers Listings =
 +
 +
[[NAT Loopback Routers|opensimulator.org/wiki/NAT_Loopback_Routers]]
 +
 +
== VMware VMXNET3 NIC Issue ==
 +
 +
When running OpenSimulator in a 64-bit CentOS 6 VM under VMware ESXi 5, with the latest VMware Tools installed, and using the VMXNET3 vNIC, I (smxy) found that my viewer would consistently be disconnected from my grid at approximately 12 minutes after connecting (with the child agents dying sooner, as evidenced by regions turning red in the mini-map), with ACK timeouts reported at the region consoles. This behavior was 100% repeatable. I discovered that deleting the VMXNET3 vNIC and replacing it with the E1000 vNIC (and maintaining the same MAC address) eliminated the problem completely.
 +
 +
A few weeks later, I noticed someone (LilinEnyo) reporting ACK timeouts, in IRC. It turns out she was running "ubuntu 64bit" under ESXi 5, with VMware tools installed and using the VMXNET3 vNIC. In her case, the ACK timeouts were disconnecting her viewer at approximately 5 minutes after connecting. I had her switch to the E1000 vNIC and it eliminated the issue for her, too.
 +
 +
= Historical =
 +
 +
== OpenSimulator Grid - Ports for Grid Services - up to version 0.6.9 ==
 +
 +
Note this is no longer the current version...
 +
 +
* TCP/8000 - Reserved
 +
* TCP/8001 - Grid Server - Regions and other grid services talk to this
 +
* TCP/8002 - User Server and Login Services - Clients, Regions, and other grid services talk to this
 +
* TCP/8003 - Asset Services - Regions and other grid services talk to this
 +
* TCP/8004 - Inventory Services - Regions and other grid services talk to this
 +
* TCP/8005 - Reserved (Dispatch Services)
 +
* TCP/8006 - Messaging Server
 +
* TCP/8895 - Used in early releases for region-to-region communications
  
  
NOTE: Contrary to what is displayed above, DHCP services are not required to operate OpenSimulator server software.
 
 
[[Category:Users]]
 
[[Category:Users]]

Latest revision as of 06:58, 19 September 2020


Contents

[edit] Introduction

These are instructions for making an OpenSimulator installation accessible externally through a firewall or router. Please note that if you are using consumer network hardware, you will need a router that supports NAT loopback. See NAT Loopback Routers if you want give both LAN and external users access.

For help on general connection issues, see Troubleshooting#Networking and config issues.

[edit] Standalone Mode

[edit] TCP

  • TCP/9000

The http_listener_port configured in the [Network] section of OpenSim.ini needs to be accessible externally. By default this is 9000.

In standalone mode this provides

  • HTTP access to the simulator (needed for the capabilities protocol, amongst other things.
  • HTTP access to public services, such as as login.

In standalone mode, no private service port is exposed since all simulator to service communication occurs internally within the OpenSim.exe process.

If you have XMLRPC active for in-world scripts (http://wiki.secondlife.com/wiki/Category:LSL_XML-RPC) (this is not active by default), then you will also need to make the XmlRpcPort configured in the [XMLRPC] section of OpenSim.ini accessible by external systems. By default, this is TCP/20800.

[edit] UDP

  • UDP/9000-9xxx

The configured InternalPort of each region needs to be accessible for UDP traffic from the viewer (to exchange movement data, object information, etc.). These configuration files are found in the bin/Regions/ directory. The usual port for the first region is 9000, but each region needs its own port (usually then 9001, 9002, etc.). However, any other set of ports can also be configured.

[edit] IP Address

In the region configuration files found in bin/Regions/, each region will have an ExternalHostName configured. For example,

ExternalHostName = 82.73.39.77

For viewers external to your LAN to contact your installation, this must be directly accessible from their location. In the most basic case, your server would be directly accessible from the Internet.

  1. Retrieve your external_host_name
  2. Get your internal_ip_address (using ipconfig for windows, or ifconfig for linux)
  3. Make sure the settings match

If you're running a simulator at home, it's much more likely that access to your LAN runs through a router which does not make your computer accessible via the Internet. For more information on this, check out the NAT and Port Forwarding section below.

[edit] Grid Mode

[edit] Simulator

  • TCP/9000
  • UDP/9000-9xxx

For each simulator on your grid, the same ports as described for the standalone situation above need to be accessible to external viewers. Although public services are not handled by OpenSim.exe in this configuration, the simulator HTTP port still needs to be available for other viewer <-> simulator communication mechanisms (e.g. capabilities).

[edit] Services

  • TCP/8002
  • TCP/8003 (internal only, see below)

In the standalone configuration, both simulator and services are contained within a single process (OpenSim.exe).

However, in the grid configuration, services run separately in one or more Robust.exe shells.

Some of these services, such as login, need to be accessible to viewers.

In the default Robust.exe configuration, these are all served on the public port 8002. These needs to be accessible by external viewers.

However, in the grid configuration there are also a set of private services (asset, inventory, etc.). By default, these run on port 8003 (TCP only) and it should not be made accessible to viewers. In a closed grid port 8003 should only be accessible to the machines which are being used to run the grid. If Robust and all OpenSim instances running regions are on a single machine no external access to port 8003 should be allowed.

[edit] Optional and Add-on Module Specific Ports

[edit] FreeSWITCH Voice

  • TCP+UDP 5060 - SIP Ports (5060 for default call profile)
  • TCP+UDP 1720 - H.323 ports for call setup

More details on the Freeswitch ports used and firewall configuration details are at:

[edit] Mumble Voice

  • SIP Ports
  • ICE Ports

[edit] NAT and Port Forwarding

[edit] Straightforward

If your host does not have a public IP address (eg it is hidden behind a home router) you will have issues hosting grid and region servers if you plan on connecting clients to it on both sides of the router, however this can be worked around through the use of port forwarding and ip-redirecting.This will also correct issues where the client hangs at region handshake.

  • Set internal_ip_address to your local LAN-ip(e.g. 192.168.2.1) (regions.ini file)
  • Set the external_host_name to your external IP-Address (Not a hostname, since DNS-resolving doesn't work properly) (regions.ini file)
  • Forward the appropriate ports to the OpenSim-server on both UDP and TCP (router-setup)
  • Open appropriate ports on the OpenSim-server's firewall on both UDP and TCP
  • Reroute traffic for Linux:
    • iptables -t nat -A OUTPUT --dst EXTERNAL_IP -p tcp --dport 9000:9010 -j DNAT --to-destination INTERNAL_IP
    • iptables -t nat -A OUTPUT --dst EXTERNAL_IP -p udp --dport 9000:9010 -j DNAT --to-destination INTERNAL_IP
    • service iptables restart

Those iptables lines will redirect any traffic going to EXTERNAL_IP on ports 9000 to 9010 to INTERNAL_IP. The internal ip is the LAN-IP of your server, and External ip is your internet IP. Use the above iptables command on all internal machines except your gateway/router. This assumes your gateway/router machine does not also host your sim. This also assume you have a default ACCEPT policy on your internal machines. So to connect from within your LAN, use the above iptables commands to reroute the traffic to the server internal ip.

  • Reroute traffic for Windows:
    • netsh (this method needs experimentation and elaboration. Please see the Discussion page for some guesswork on where to start)
      • note from paulieFlomar: I tried using Windows built-in tools like FireWall, netsh, and IP Security Policy. My experience with these tools was unsuccessful. I then tried to create an outgoing rule with some third-party firewall products. I tried ZoneAlarm and Sunbelt Firewall. Neither of these products would allow me to create outgoing rules. Finally, I tried creating an outgoing rule in my Linux IP Tables firewall. This worked. I created 2 rules which I placed in a firewall script, before my NAT rule. The rules were:

iptables -t nat -A PREROUTING --dst EXTERNAL_IP -p tcp --dport 9000:9010 -j DNAT --to-destination INTERNAL_IP

iptables -t nat -A PREROUTING --dst EXTERNAL_IP -p udp --dport 9000:9010 -j DNAT --to-destination INTERNAL_IP

These rules worked. I can now access my region from my LAN.

Optional:

  • Register an external domain-name (for external connections)
  • Use Bind for internal domain-name resolving

[edit] DynDNS loopback

This method was used and successfully tested using www.dyndns.com (creates a virtual domain for your pc/ip, like yourcomputer.ath.cx) as loopback for devices on a LAN with three machines (pentium 2.8ghz running windows xp - internet server , amd opteron running ubuntu 7.10 64bit - as opensim server - and MacBook with OSX 10.4.11 - as client), a modem (thomson/alcatel speedtouch 330) and a mini-switch (which brand no one ever heard of). The connection of these machines is made as following: Modem -> Win Pc -> Switch -> Mac and Ubuntu. Dyndns is used to loopback to the Win Pc, and then it forwards the request to the internal LAN opensim server, which grants everything for the client. As for the client, if he is inside the private LAN then he is now actually someone on the internet requesting for access to the opensim server. Thus, if the client is someone on the internet then he will be treated like that. Tricky ? Further details ahead:

Method:

  • Set the simulator listening IP address to your dyndns domain - edit opensim/bin/Regions/Regions.ini; and change the external_host_name to external_host_name="yourcomputer.ath.cx". Leave internal_ip_address "0.0.0.0" and port "9000".
  • Set the client (SecondLife Viewer) -loginuri to "yourcomputer.ath.cx:8002" (the port used was 8002, yours can be different if you configured it that way ie: "yourcomputer.ath.cx:9000 on Standalone mode) - i didnt use the -loginserver flag also. This can be set in the Grid Manager of most third party viewers.
  • Port Forward the above ports on the internet server (in this case, win xp). You do so by creating exceptions in Windows Firewall for the above mentioned ports, and for both connections: Internet Connection and LAN - this keeps the ports open for the web requests to travel over the private network.
  • Edit "hosts" file (on windows, this is C:\Windows\System32\Drivers\etc\hosts and on Unix-type systems, this is /etc/hosts) entry on your internet server (in this case, win xp box) and add the following line: xxx.xxx.xxx.xxx     yourcomputer.ath.cx. Of course, xxx.xxx.xxx.xxx is your opensim server internal LAN IP.

yourcomputer.ath.cx is now available for everyone to connect and you may login with the client!


[edit] DynDNS and the free IPCop Linux Firewall

Here an other way with the IPCop Linux Firewall, DynDNS and a OpenSimulator server

  • Setup an IPCop firewall with 3 interfaces (red, green, orange) and put the OpenSimulator server on the orange interface (all OpenSimulator server's on one Linux box). Red is the internet, green is your lan.
  • Setup the DynDNS service on the IPCop Firewall.
  • change the external_host_name in the default.xml to the DynDNS name
  • do'nt change the internal_ip_address in the default.XML, it should be 0.0.0.0
  • if there, delete all loopbacks in /etc/hosts only 127.0.0.1 should be localhost
  • customize the Port Forwarding on the IPCop Firewall (8002 TCP, 9000 UDP/TCP and for every additonal region 900X UDP/TCP). Port forwarding should be set to the (orange) interface adress of the OpenSimulator Box

Then it should be possible to conenct from inside the LAN (green) and it is also possible to conenct from the internet (over the red interface). (well, the inside-lan connections are also made now over the RED interface, but infact, this is in the same ISP network, it should be quit fast ;-)

  • Attention : the ports on the IPCop Firewall must also be open if you connect from inside (green) to your OpenSimulator Grid !

If you are using the OS WebGui, do'nt forget to set the "SMTP AUTH" in your email server. Most of the dynamic IPs are blocked at ISP level so the new users do'nt get any confirmation email.

This was tested with the Hippo OpenSimulator Viewer and with the Login URL : http://DynDNSName:8002


[edit] Local connections with ZyXEL DSL modem/router and NAT/Port Forwarding

This solution works with the ZyXEL Prestige 660ME-61 DSL Router. It may work with other models made by ZyXEL.

Method:

  • Connect by TELNET to your ZyXEL DSL modem. Use the same IP address that you would if you were using the web interface. For example, the default ip on most Embarq ZyXEL DSL modems is 192.168.2.1.
telnet 192.168.2.1
  • Enter your password. If you do not know it, try just pressing <ENTER> or ask your ISP for the password. They may or may not give it to you.
  • Select menu option "24. System Maintenance" from the menu.
                   Copyright (c) 1994 - 2004 ZyXEL Communications Corp.
                             Prestige 660ME-61 Main Menu
    Getting Started                      Advanced Management
      1. General Setup                     21. Filter Set Configuration
      2. WAN Backup Setup                  22. SNMP Configuration
      3. LAN Setup                         23. System Password
      4. Internet Access Setup             24. System Maintenance
                                           25. IP Routing Policy Setup
    Advanced Applications                  26. Schedule Setup
      11. Remote Node Setup
      12. Static Routing Setup
      15. NAT Setup                        99. Exit
                         Enter Menu Selection Number:


  • Select menu option "8. Command Interpreter Mode" from the menu
                         Menu 24 - System Maintenance
                        1.  System Status
                        2.  System Information and Console Port Speed
                        3.  Log and Trace
                        4.  Diagnostic
                        5.  Backup Configuration
                        6.  Restore Configuration
                        7.  Upload Firmware
                        8.  Command Interpreter Mode
                        9.  Call Control
                        10. Time and Date Setting
                        11. Remote Management
                         Enter Menu Selection Number:
  • At the prompt type "ip nat loopback on".
Copyright (c) 1994 - 2004 ZyXEL Communications Corp.
Sprint > ip nat loopback on 
  • At the prompt type "exit".
Sprint> exit
  • Select menu option "99. Exit"
  • Follow all other steps for configuring and starting your server as outlined in Getting Started.


[edit] Local connections with the DLink GamerLounge Extreme N router

Networking and router configurations have been responsible for 98% of all trouble I have had setting up and operating OpenSimulator region server software. Insuring that you have a capable router properly configured should be the first thing on the list of configuration checkpoints for a smooth and trouble-free path to OpenSimulator software operations in GridMode.

Below is a series of screen snapshots with the key pages of my router configuration interface with proper settings displayed.

The settings below assume that you have an otherwise working connection and do not touch on such subjects as port conflicts or logging your network onto your ISP's provider network.

1.Status
2.Advanced > Gaming
3.Routing
4.firewall
5.Advanced network settings
  • provided that all information supplied in ~opensim/bin/OpenSim.ini and in your ~opensim/Regions/*.xml are properly configured, this should have you up and running.


==Local and Internet connections with Linux iptables and NAT/Port Forwarding== Please don't copy this verbatim - much more should go into a firewall setup, but this will at a bare minimum get NAT working with forwarding to your OpenSimulator server from both inside and outside your LAN.

Example firewall.sh script:
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
modprobe nf_conntrack_ftp
modprobe nf_nat_ftp
 
INT = "eth0" # your internal network card on the firewall
EXT = "eth1" # Your external network card on the firewall
IPTABLES = "/sbin/iptables" # Path to your iptables executable
 
OPENSIMEXT = "66.102.1.103/32" # Example external IP - replace with yours
OPENSIMINT = "192.168.1.240/32" # Internal IP of your OpenSimulator server
INTSUBNET = "192.168.1.0/24" # Your internal subnet range
 
# Flush rules when we are restarting the script
$IPTABLES -F
$IPTABLES -F -t nat
$IPTABLES -F -t mangle
 
# Set up sane defaults
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P FORWARD DROP
 
# Allow all connections from inside the network to the firewall on all ports
$IPTABLES -A INPUT -i $INT -j ACCEPT
# Allow all outbound connections from the inside. Much better to limit this...
$IPTABLES -A FORWARD -o $EXT -j ACCEPT
 
# Configure basic NAT
$IPTABLES -A FORWARD -i $EXT -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -o $EXT -j SNAT --to-source $OUTNAT
 
# Configure forwarding for OpenSimulator (you need to add ports if you are not running in standalone
# or if you are running more than one region)
$IPTABLES -A PREROUTING -p tcp -d $OPENSIMEXT --dport 9000 -j DNAT --to-destination $OPENSIMINT
$IPTABLES -A PREROUTING -p udp -d $OPENSIMEXT --dport 9000 -j DNAT --to-destination $OPENSIMINT
 
# Now for the magical juice that lets inside users and outside users both access your server
# Configure to allow internal network users to access the OpenSimulator server using the 
# external IP address. This fixes failing to connect to regions over UDP due to NAT config
# Make sure you configure the proper external IP for each of your regions
$IPTABLES -t nat -A PREROUTING -i $INT -s $INTSUBNET -d $OPENSIMEXT -j DNAT --to-destination $OPENSIMINT
$IPTABLES -t nat -A POSTROUTING -o $INT -s $INTSUBNET -d $OPENSIMINT -j DNAT --to-source $OPENSIMEXT


NOTE: Contrary to what is displayed above, DHCP services are not required to operate OpenSimulator server software.


[edit] NAT LoopBack Routers Listings

opensimulator.org/wiki/NAT_Loopback_Routers

[edit] VMware VMXNET3 NIC Issue

When running OpenSimulator in a 64-bit CentOS 6 VM under VMware ESXi 5, with the latest VMware Tools installed, and using the VMXNET3 vNIC, I (smxy) found that my viewer would consistently be disconnected from my grid at approximately 12 minutes after connecting (with the child agents dying sooner, as evidenced by regions turning red in the mini-map), with ACK timeouts reported at the region consoles. This behavior was 100% repeatable. I discovered that deleting the VMXNET3 vNIC and replacing it with the E1000 vNIC (and maintaining the same MAC address) eliminated the problem completely.

A few weeks later, I noticed someone (LilinEnyo) reporting ACK timeouts, in IRC. It turns out she was running "ubuntu 64bit" under ESXi 5, with VMware tools installed and using the VMXNET3 vNIC. In her case, the ACK timeouts were disconnecting her viewer at approximately 5 minutes after connecting. I had her switch to the E1000 vNIC and it eliminated the issue for her, too.

[edit] Historical

[edit] OpenSimulator Grid - Ports for Grid Services - up to version 0.6.9

Note this is no longer the current version...

  • TCP/8000 - Reserved
  • TCP/8001 - Grid Server - Regions and other grid services talk to this
  • TCP/8002 - User Server and Login Services - Clients, Regions, and other grid services talk to this
  • TCP/8003 - Asset Services - Regions and other grid services talk to this
  • TCP/8004 - Inventory Services - Regions and other grid services talk to this
  • TCP/8005 - Reserved (Dispatch Services)
  • TCP/8006 - Messaging Server
  • TCP/8895 - Used in early releases for region-to-region communications
Personal tools
General
About This Wiki