NAT problem understood

[Trumpcard]

Coder,
Are any changes necessary to the NAT server host file? I'm trying out this technique, but havent been successful with it yet.

So, in a nutshell, you just override your external dns name on the client box to your internal ip, thats it?

[TheClaus]

Trumpcard,

I got this to work by doing the following. I changed my HOSTS file in windows to the following.

192.168.1.1 theclaus.kicks-ass.org

Then I opened a cmd prompt and tested it by pinging theclaus.kicks-ass.org. It should come back as 192.168.1.1. Then I used this script file that theCoder made and modified it. After that I tested and been running fine all weekend. Attached is the eqemud script. You'll notice that I have the zones are going to the localhost for the world. That is cause they are on the same machine. It was orginally setup to go to the $PUB_IP on both but couldn't connect on the inside. With this setup both myself and outside people can connect fine. Don't forget to CHMOD 755 file so it will execute. Then when I run my server I do a ./eqemud start

[theCoder]

The NAT patch was written so that people didn't have to change any DNS entries. However, it will only work if and only if the world and zone servers are running on the NAT server. The NAT patch makes the EMU listen on only the external interface (actually, whichever interface you specify, but you want the external one). NAT servers have to have at least two interfaces, but the login server can only record and give out one of those. If the world server specifies to the login server that it is on the internal one, external clients cannot connect. If the world server says it's on the external interface, internal EQ clients get confused because of how the UDP packets are returned when the EMU listens on both interfaces. By forcing the EMU to only listen on the external interface, the UDP packets get formed the way the EQ client expects them and everything works.

What the NAT patch won't help with is an EMU server behind a NAT server. The only way I know of to solve that is with port forwarding on the NAT server and DNS work on the EQ clients (note that you shouldn't need to mess with the hosts file on the NAT server).

A better solution would be to have a separate entry in the conf file specifying the bind address the EMU should use (0.0.0.0 will bind to all interfaces). As soon as I get some time (I'm in the midst of moving across the country right now, so I shouldn't even be reading this board ), I'm going to look into that, and also look into setting up autoconf and making a more "linux friendly" version.

[Trumpcard]

Very cool, thanks... I'll try it out again when I get in this afternoon. Nice thing about this script is that it will fit nicely
into rc3.d or /etc/runlevels.

Just got finished installing gentoo linux this weekend on my primary partition (left RH7.3 on my secondary).

I can't begin to tell you how much faster it is! My KDE performance is probably 50% faster. It helps to recompile glibc and kde with the newest binutils (2.12+ that has the new combreloc added in).

I pretty much built everything from scratch, you'd be amazed at having things compiled from the ground floor with the right compiler options. (i686 makes a huge difference, most everything these days in prepackaged formats ends up with i386).

It took me no time to get the majority of my functionality shifted from my RH partition over to the gentoo one. I may end up moving everything over eventually. For now dual boot will work, but I have a feeling that she will be going to way of the dodo before too long. The emerge portage system is really cool too, it makes system updates a snap. Give the distro a shot if you guys get the chance, I bet you won't be disappointed. I had showeq back up and running in a couple of hours after got the system stable. (had to rebuild my kernel a few times).

I was able to port my websites, database servers, mail configuration over in the course of a days time.

Its definitely easier getting showeq running correctly on gentoo than it is on RH7.3 (I was having issues with the new one colocating gcc 3.0.4 and 2.96)

I got the tip about Gentoo from Ratt, I'll have to send him a thank you note, this distro rocks! One odd thing, that I've actually come to like is they do not provide a telnetd daemon, it's sshd or nothing baby.. Makes it harder for me to get to it from work where we only have a telnet proxy, but I can just telnet to my prod boxes then ssh from there.

Very slick...

[theCoder]

Thanks for the heads up on gentoo. If I ever get some new hardware, I'll give it a try.

I'm not sure why you can't ssh out of your work box, though. I can't imagine that someone would port block outgoing ssh connections but allow outgoing telnet connections, but I guess stranger things have happened... If that's the case, set up sshd to listen on port 23 (the telnet port) and then tell your ssh client (I'd recommend PuTTY on windows) to connect on port 23.

One thing you shouldn't do is ssh from a telnet connection. Anyone can listen in on the telnet side almost eliminating the security of ssh (unless the telnet connection is on a secure line).

[Trumpcard]

Well, we only have a telnet proxy server, you actually telnet to the proxy, then you telnet from it, you're not being transparently passed through it like you would through a http/ftp proxy..

Makes me miss the old days at IBM of having a socks-i-fied connection...

[btuch]

Does anyone have a NAT patch for the 0.3.7 or 0.3.8 patch? Been looking through the source and it looks like the entire section was re-written.

[TheClaus]

You shouldn't need it. If you look at the entire post it shows how to get it working without the patch. The way I have done it is to put theclaus.kicks-ass.org (pub_ip) into my HOSTS file under Windows and then pointed it to my internal ip on my network 192.168.1.1

That should work.

[btuch]

TheClaus,

I have all the servers set to run on my external IP, on a Linux box runnin NAT/MASQ. Set up this way, others can connect to my outside IP, but I cannot connect from my internal IP. I always get an error in the log files that I have been disconnected....

From TheCoder's post:

The NAT patch was written so that people didn't have to change any DNS entries. However, it will only work if and only if the world and zone servers are running on the NAT server. The NAT patch makes the EMU listen on only the external interface (actually, whichever interface you specify, but you want the external one). NAT servers have to have at least two interfaces, but the login server can only record and give out one of those. If the world server specifies to the login server that it is on the internal one, external clients cannot connect. If the world server says it's on the external interface, internal EQ clients get confused because of how the UDP packets are returned when the EMU listens on both interfaces. By forcing the EMU to only listen on the external interface, the UDP packets get formed the way the EQ client expects them and everything works.

I am having that very problem, where the world server seems to be bound to both my internal and external IP addresses. This is why I'm looking to patch the code. However after going through the source, it looks like a lot has changed since v0.3.0. Hopefully someone can post a patch, or some instructions on where to place code to get the world server to bind to only the IP address specified.

Its not a DNS issue, but an IP issue with the world server binding to both IPs I think.

-Brian

[Trumpcard]

Heres my take on it...

The code should support binding to an interface, rather than using INADDR_ANY, this is a case thats going to happen. 50% or more of linux users are going to be using their linux box as a firewall/masq. box and trying to play from the internal lan. It also cuts off other potential binding issues that could happen when using multihomed machines.

I'd like to see a command line option passing in which interface to use into zone on startup, should be a simple change combined with the changes Coder made.

On the otherhand, there is a workaround, even though I wasnt able to get it to work, you should try it first. I still think that this is a valid change to put in that stems off potential problems in the future though.

[btuch]

Trumpcard,

I see your post, I'll try the script when I get home.

Thanks!

-Brian

[Trumpcard]

Read the whole thread, the instructions are in there...

Basiclly, you give your linux box a dns name from a free server (dyndns.org , freedns, etc). The you change your windows host file on your internal network to map

LINUX DNS NAME INTERNAL IP

So internal requests to your masq box will go to the internal interface rather than going out and back in.

[btuch]

Didn't work.

I can connect to the login server, but then the world server log gives "Bad/expired session key: ls#1".

So....hopefully someone can come up with the patch for the >=0.3.8 to tell the world server to bind specifically to 1 IP, and not both.

-Brian

[TheClaus]

I'll setup a linux server tonight and see if I can get it to work. Basically what Trump and I said should work though.

[btuch]

I think I found the area to put TheCoder's patch into the 0.3.8 release...

In the file ~/world/console.cpp for the line:

address.sin_addr.s_addr = htonl(INADDR_ANY);

and put a // in front of it.

Then below that line paste the lines (without the --snip--):

--snip--
// bind only to the address specified as the world address
hostent* bindaddr = gethostbyname(net.GetWorldAddress());

if (bindaddr != NULL)
{
#ifdef WIN32
memcpy ((char FAR *)&(address.sin_addr), bindaddr->h_addr, bindaddr->h_length);
#else
memcpy ((char*)&(address.sin_addr), bindaddr->h_addr, bindaddr->h_length);
#endif
}
else
{
// could not resolve world address... bind to all interfaces then
cout << "Error: could not resolve world address " << net.GetWorldAddress() << endl;
cout << "Listening on INADDR_ANY" << endl;
address.sin_addr.s_addr = htonl(INADDR_ANY);
}
--snip--

I tested this, and the world server will now bind to the IP specified in the LoginServer.ini

The only changes I made were I took out the references to "this->" and added in "net.".

I'll test it when I get home from my internal LAN.

-Brian