Automatically networked domain-server


#1

In order to make it easier for people to get to your domain-server, we’ve just added a new feature called “automatic networking”. You can set this in the “Metaverse Registration” section of your domain-server settings.

There are three options:

  1. Full: this will have your domain-server check in with our “ice-server” every so often and update its public networking information and local networking information. Interface clients will then connect to your domain-server by telling the ice-server they want to connect to you. On most types of home networks this should just work. This means you don’t need to open any ports on your router or have a DNS name or static IP to get users to connect to your domain.

  2. IP Only: this will update your IP address with data-web every so often. This is useful for users who want to open the domain-server port on their firewall (40102) but who have a dynamic IP address at home and don’t want to have to keep changing their IP address in data-web. As your IP address at home changes, we will update it for you in data-web so users can get to the new address.

  3. None: this is the way all current domains work. We only use the network address you have entered in data-web for users to connect to you. This means you need a DNS name that will resolve to your IP address, or a IP address that isn’t going to change.

We think most domain-server users will want to leverage full automatic networking to make it very simple for users to find their domain.

If you already have your own domain, feel free to close 40102 and switch to full automatic networking to test it out. If you’ve been holding off on creating your domain because you wanted to avoid firewall settings, now would be a good time to get going!

Please comment here if you have any problems getting set up, or even if you’d just like to let us know that you’ve changed over to full auto networking so we can test getting to your domains!


#2

This is a very good function for many users, does it mean the dont have the router loopback problem anymore to if its set to fully automatic ?


#3

Can you describe what you mean by “router loopback problem”?


#4

Going to try, many people (as example , opensim) have problems to reach there own server behind there router. In the router is some option disabled so router cannot access the internal server when you try to acess it from the inside. I think wiki describes it better.

NAT loopback

NAT loopback, also known as NAT hairpinning or NAT reflection,[6] is a feature in many consumer routers[7] which allows a user to connect to his/her own public IP address from
inside the LAN. This is especially useful when, for example, a website is hosted at that IP address. The following describes an example

network:

  • Public address: 203.0.113.1 (this is the address of the WAN interface on the router)
  • Internal address of router: 192.168.1.1
  • Address of the server: 192.168.1.2
  • Address of a computer: 192.168.100.1

If a packet is sent to the public address (203.0.113.1) by a computer at 192.168.100.1, the packet would normally be routed to the default gateway (the router), unless an explicit route is set in the computer’s routing tables. A router with the NAT loopback feature detects that 203.0.113.1 is the address of its WAN interface, and treats the packet as if coming from that interface. It decides based on DNAT (port forwarding) rules on the destination for the packet. For example, if the data were sent to port 80 and there is a DNAT rule for port 80 directed to 192.168.1.2, then the host at that address will receive the packet. If no applicable DNAT rules are available, the router’s firewall drops the packet. An ICMP Destination Unreachable reply may be sent. If any DNAT rules were present, address translation is still in effect; the router still rewrites the source IP address in the packet. The computer (192.168.100.1) sends the packet as coming from 192.168.100.1, but the server (192.168.1.2) receives it as coming from 203.0.113.1. When the server replies the process is identical as for an external sender. Thus, two-way communication is possible between hosts inside the LAN network via their public IP address. NAT loopback is especially useful when the server hosts a domain name that resolves to a public address. When the router does not perform NAT loopback, any connection attempts to that IP address fail.

There are enough routers from isp that dont support this option anymore or is disabled, many manufactures seems to remove this option to sofar i know.

Wiki nat loopback


#5

Yeah - give it a try. Because the ice-server knows your local address we don’t need a nat that supports hairpinning. Should just work.


#6

For me its not easy to test without messing up everything. also my server is seperate system. so skipping this test. we need to find someone that have hit this problem before.


#7

I have got a stack manager running at on of my domains: meverhagen.nl and called the domain dutch on the dataweb.

Tried to teleport to the domain from another machine on the same wlan network.

When I put off the firewall ports 40100-40105 on the router routing to the local ip I got the stack manager running then I can reach the domain when I enter dutch, but not on the domain name with the full option.

With the none option and the firewall ports open then I can reach it with both the domain name and the dutch name.

I do not know if someone from outside can teleport in.

It is a pretty empty domain, there should be some things in. Saw some models at one login.


#8

@MarcelEdward I logged into “dutch” from san francisco fine. I have put a voxel at the location in this picture.


#9

Realized I didn’t actually clarify how to get to domain-server settings!

They can be found at http://{DOMAIN_IP}:40100/settings where DOMAIN_IP is the IP address for your machine that is running your domain-server.

If you’re running the stack manager on your local machine this means you can get to your settings at
http://localhost:40100/settings


#10

It seems people still need to forward the right ports udp + tcp in the router. by accident udp where closed in the router but tcp forward where set with the result that you get a “Not Connected” message when you teleport to that domain. and everything where set first time to fully automatic in the stack manager settings. After fixing the udp forward things worked perfect, with ip Only as option on the settings page.

Sofar i understand this option where made to solve this problem, with portforwarding and routers ?

Anyway it works now, and if theres a bug i hope we can test it again with the other to see if it works fine without port forwarding in the router. if thats not needed.