NAT problem understood

[theCoder]

I think...

After playing around trying to log into my brand new 0.3.0 install, here's what I've found.

The login server at eqlogin.eqemu.net tends to ignore the worldaddress (from the .ini file), if that's ever sent. It always reports back my external IP to my EQ client (confirmed through packet sniffing).

There are no problems with the EQEmu world or zone servers. At least as far as letting the users log in (I haven't gotten past that point yet). The world server, as far as I can tell, services login requests correctly. The problem is not what's being sent, or where it's being sent to, but where it's being sent from.

Here's what I see is happening:
1) The EQ client correctly gets my world server external IP address from the login server as X. It sends a login request to the world server at X.

2) The world server receives the request, processes it, and returns a response. Since the world server knows that the client is on the internal network, it uses the internal inteface (IP address Y) to send the response (actually, this is Linux's doing, but it's still right).

3) So far so good. But here's the problem. Everquest uses UDP to send data, which is a connectionless protocol. Because it's connectionless, applications that use it have to examine the source address of each packet to determine what the packet is for. So, when the EQ client sends a packet to IP X, it expects a response from X, not Y. I imagine (though I don't know for sure) that the the EQ client is just dropping the packets from IP Y, since it doesn't know that they're really from X.

So what are the solutions?

• Running your own login server is one solution, but it's not great. First, you can't do that, since even minilogin isn't being released anymore. Second, that means that you can't connect to the official login server. A stop-gap measure at best
  
• It would theoretically be possible to write a NAT module for EQEmu like the module for FTP. This module would fix the IP address so that it was the internal IP (Y) instead of the external IP (X). A little bit better solution, but hard to do (I don't even know where to start on that)
  
• Perhaps modify the world (and zone?) server so that it always says it's from IP in the send is X, even if it's using the internal interface. I don't know how much work this would entail. The downside to this approach is that it would most likely require that the server be run as root (I don't think normal users would be able to do this).
  
• Change the login server on eqlogin.eqemu.net to return the worldaddress field instead of the connection source. This would mean that external people couldn't play on my server (since my worldaddress is currently Y), but they can't anyway, since port 9000 isn't open externally.

Anyone have any other ideas? I'm not sure what else to do, and right now I can't even play on my own server. I'm going to try to look into the third option, since it seems the easiest for me to do (I think the fourth is the easiest, but I can't do that).

[theCoder]

I think I've found a way to make the world server work... I'll post a patch later tonight when I get some time...

[theCoder]

I believe that this will work. I haven't been able to test it fully (I know that the world modification works, and the zone modification is the same so it should work) because eqemu.net says my server is locked... I'll have to look into this tomorrow...

To install the patch, run from your eqemu directory:
patch -p1 < EQEmu-0.3.0-NAT.patch
(adjusting the file name for wherever it's actually saved, of course).

The patch file only modifes the net.cpp files in the respective world and zone directories. Let me know if there are any problems.

Note: because of limitations of this message board, I had to rename the file to add a .zip extension. It really is a g'zipped tarball of a patch file.

[Trumpcard]

If this works, Im going to buy you a beer...

[theCoder]

The NAT patch does work, at least for me logging into my server. I opened the ports up on the firewall, so others should be able to try it also (though it would have always worked for everyone on the outside). The server name is "theCoder test" and it mentions the NAT patch.

Basically, all it does is bind the daemons to a specific interface instead of INADDR_ANY. This apparently causes Linux to send response packets back through that interface so it picks up the correct from IP address. The world server picks up the IP address from the worldaddress line in LoginServer.ini (the ini parser is buggy, so remove the account= and password= lines from the file to get it to work). The zone server uses the address passed in on the command line. Both servers use gethostbyname, so the address can either be the actual external IP, or a name that resolves to the IP. Note that it has to be the external IP (the one that eqemu.org sees), not the internal one.

[Trumpcard]

Awesome! Works like a champ! Would these changes cause any problems in the windows version, it would be great to get this tested out across the board then get it merged into the source...

1st time Ive been able to logon to my own linux server... Awesome work Coder!!

[theCoder]

I tried to put in the necessary ifdef's to make the code work on Windows (based on other code I saw in the EMU). I haven't tried this, however, but it _should_ work.

It would be nice if this made it into the next release, but if not, I'll be sure to put out a patch file for it.

[Kyraxe]

Hi,

I just switched over my old P2 to Redhat 7, and it will be working as my NAT. Can I also have the EQEmu server on this machine, and if so what do I have to do with your file in order to set this up so that my 3 other home machines can connect to it?


Cheers,
Kyraxe

[Lurker_005]

There is another way around the Nat problem, set your external IP or name that your using to resolve to 127.0.0.1 in your host file

You can set an ip to an ip can't you? or do you have to use a hostname (dynamic hostname if need be)?

Anyhow this is reported to solve the problem without patching. You computer connects like it is all set to 127.0.0.1 and everyone else connects using your external IP.

[theCoder]

To answer Kyraxe's question, there are two solutions that I know of. I think the easiest solution is to use the patch I made (btw, it does still work for 0.3.1, patch just says the lines are off, but it still applies correctly). See one of my previous posts for how to apply it.

If you use the NAT patch, then all you have to do is put your external IP address as the worldaddress (in the LoginServer.ini and as a command line argument to the zone processes). That's all you have to do.

The other solution (which I recently learned from Hogie on the IRC channel) is to use domain names to your advantage. I think this is what Lurker was trying to say, but obviously, you don't really want to use the loopback (127.0.0.1) since you aren't going to be running the EQ client on a Linux machine . The DNS solution is faily easy to do for Linux computers (/etc/hosts is well defined), but you'll have to hunt around on your Windows box to find it's hosts file (mine is in windowssystem32driversetc, but I've seen it in other places on other installs). The other thing you'll need is a domain name for your IP address (goto www.dhs.org if you don't have one -- you can get a subdomain for free there). What you need to do in this solution is use the domain name as the world address. The login server at eqemu.net will report that name back to the EQ client when it wants to connect (when I wrote the patch, I mistakenly thought it only sent back the IP address). To allow your internal hosts to connect to your server, you need to modify their hosts file to override the DNS setting. So add a line like the following to each internal EQ client machine's hosts file:

int.ern.al.IP domainname.dhs.org

filling in the numbers for the IP address (for example, I use 192.168.1.1) and your correct domain name.

Personally, I think the NAT patch is a little cleaner solution, but I'm biased. Unfortunately, the NAT patch only works if your emu server is running on your NAT computer. People like cduckman (another thread) who want to run their emu on another internal machine would benefit more from the DNS solution. So take whichever solution works best for you.

[Kyraxe]

Thanks for the replies. I am going to try and set up my Redhat machine today and see if I can get this going. =)

[DeletedUser]

Herm, the loginserver should be using the worldaddress (assuming the linux version of world sends it right). This issue is exactally why it was added, so you could use the hosts file to have the dns entry point to your internal address from internal machines.

[theCoder]

Quagmire, I think the Loginserver is working just fine. The reason I thought that it didn't use the worldaddress (besides the fact that it's closed and not open like the rest of this project) is that I tried putting in my internal IP in the worldaddress field, but that didn't work. I later found out that the world server's INI parsing routine is broken for fields that have no data (like account= and password=). Those cause the next item to not be read. So simply removing them from the LoginServer.ini file makes it work. And the DNS solution would (I think) work also.

However, I like pointing my domain name at my external IP address and the computer's name at the internal IP address, so I'm going to stick with the NAT patch for now. Really, having more solutions to a problem isn't a bad thing at all

[Kyraxe]

Hey Codeman, I got it setup using the domain name and the hosts file. However I am still unable to connect to my server, I get a 1017 error (and no I don't have a firewall running) Would this be caused by me messing up one of the IP entries somewhere? Any ideas? =)



Thanks

[theCoder]

Kyraxe,

First verify that on the EQ client computer, the name resolves correctly. Go to a command prompt and run 'ping domainname' (domainname being your domain name of course). It should say 'Pining domainname [x.x.x.x]'. Make sure that x.x.x.x is your internal (not external) IP address.

Also, make sure that you don't have any account= or password= lines in your LoginServer.ini file on your server. You don't need them, and last I checked, they screwed up the parser so that it would read the worldaddress field. When you start up the world server, it should say

World server listening on: domanname:9000

If it doesn't then something is wrong.

If both of those check out, then I can't think of anything off the top of my head that's wrong...