mangos zero Dynamic DNS Realm Address on Mangos Zero

[tacomaster5000]

Greetings,

I have been wracking my head against this problem for days now and I am hoping, nay pleading for some help.  I have a VMWare cluster at home that I am trying to setup for a MaNGOS Zero private server and I keep running into a problem getting outside clients to connect to the Realm Server.  Here is the rundown -

• I have a MaNGOS Zero server in my DMZ subnet on my firewall. 
• The firewall is setup to NAT TCP ports 8085 and 3724 from the WAN interface to the Zero server.
• I have a DynamicDNS client running on my Firewall that is updating a public DNS record (e.g. mangos.mydomain.com)
• I have a DNS override internally to resolve public DNS records like mangos.mydomain.com to the DMZ IP address
• The BindIP entry in the file /etc/mangosd.conf reads:  "0.0.0.0" which means 'bind on all IPs'

I can affirm that all of the above connectivity and configuration is correct and working (15 years of network engineering experience).

However - when I update the 'zero_realm' database table 'account' by updating the row record for my Realm's 'address' column from the default IP address to my DynamicDNS record, two things of interest happen:

1. Clients on my internal, trusted network can login and access the realm no problem.
2. Clients outside of my network (internet) can authenticate to the server, but can not connect to the Realm Server.

According to the documentation fro Mangos Zero - the address column documentation states:
 

Quote

• Field:  address
• Type:  varchar(32)  //This should be able to hold 32 alpha-numeric characters.

A valid IP address at which the world server is accessible. This can be a private IP address, like 192.168.0.1, but also a public IP address if your world server is publicly accessible.

The realm list server will redirect connections after logging in and selecting a realm to this IP address.

Please note, that the IP address configured here has to match with the IP address you have configured in the world server configuration file.

 

What The Hell Is Going On?

As far as I can tell, when the client authenticates to the Zero server, the server sends back the contents of the 'address' column of the account table to the WoW Client so it can resolve and connect to the RealmServer IP address. 

Because my internal network client connects just fine, should't that mean that the presence of a DNS record in that row (instead of an IP) will work no matter where the client is connecting from? 

1. Client resolves the Auth server from the local 'realmlist.wtf' and does a successful login.
   1. Internal client resolves DMZ IP
   2. External client resolves WAN interface IP -> NAT -> DMZ IP
2. Server: "Hey man, welcome in, here is your server IP, mangos.mydomain.com"
3. Client: "Oh snap, I have to do a NSLOOKUP to get the corresponding IP for that"
   1. Internal client resolves DMZ IP
   2. External client resolves WAN interface IP -> NAT -> DMZ IP

I tested using my WAN IP in the 'address' field

• Naturally, the internal clients were no longer able to connect (this is due to something called split horizon)
• External clients started working!

Can you help me with a fix??

• I don't want to upgrade my home ISP to a business line in order to get a static WAN IP.
• I would like the internal and external clients to resolve the correct DNS record IP based on which side of the Firewall they are on and connect to that IP.

I have considered writing a local script that checks my WAN IP and compares it against the 'address' entry in the database and updates the DB if they do not match.  The downside is that I will not be able to play the game when I'm home - or - I would have to play over my cell phone's data connection (very much not ideal).

I have considered that what I am trying to do is simply not possible due to the WoW client being written in such a way that it only supports being passed a static IP address to the realm server.  This somewhat does not make sense to me however, because when I have the 'address' field set to my domain name internal client connections work just fine.  If the client truly did not support fully qualified domain names (FQDN) for the realm address, then one would expect neither internal nor external clients to connect given this configuration.

 

[Talendrys]

Hello, the other, easiest solution is to duplicate the row in the realm table. One with the local IP and the second one with the WAN IP.

By doing this and selecting the right realm definition, both people will be able to login to the same realm by selecting the right one.

Tal'

[antz]

I know i'm a little late to the party, but there are two address fields in the realmlist table:
address for the external ip address
localAddress for local LAN access

surely setting the localAddress to your LAN IP will allow local users to access the server ok ?

[tacomaster5000]

OK - so because I was so determined to figure this out I decided to reverse engineer the packet flow to get a better understanding about how the client and server communicate with one another.  The answer was uncovered during the packet analysis, you see:

I was under the assumption that the server passed the FQDN from the address field in the database to the client so that the client could do it's own DNS lookup.  This is not actually the case. 

What happens is that the server itself does the DNS lookup of the contents of the 'address' field in the realm DB and then sends the client the resolved IP address once they have been authenticated.  Because my local DNS service was configured to override this particular DNS record (mangos.mydomain.com) the server was passing the client outside my network the DMZ IP address which it could never reach.

Long Story Short

The solution was to disable my internal DNS override (which was resolving the DMZ IP address for internal clients) so that the Mangos Zero server would resolve the DynamicDNS record of the WAN interface and send that to the client upon login.

If you run into this problem yourself make sure that -

1.  Your Mangos Zero server will resolve the public IP of your realm's FQDN:

example:

    ssh mangos_server_IP_address
    nslookup mangos.mydomain.com (or whatever you have in the 'address' field of the realm DB)
    resposne:  Your Firewall's Public IP

    
2.  Your Mangos hostname is NOT the same as your external Dynamic DNS FQDN.  Example:

• if hostname (/etc/hostname) is mangos.mydomain.com AND Dynamic DNS is mangos.mydomain.com (THIS WILL NOT WORK)
  • Why?  Because the Mangos server uses the server's operating system calls to lookup hosts and the first record it will return is the IP address of the local interface if these two are the same.

What about internal clients - won't these stop working?

Correct.  The address table is now going to be populated by an externally facing IP address which internal clients cannot reach due to Split Horizion (mentioned above).  You'll need to have your internal clients using a VPN or your cell phone's data network via its Mobile HotSpot feature.