duurrk
01-17-2011, 09:28 PM
Alright, I started setup for my server at the end of last week, and spent this weekend messing around with things. While I have plenty of other issues I'm still tackling (I definitely have my work cut out for me), I wanted to share something that I put off at first because of how much of a problem it was.
Let me start by saying, I'm running my server on a Win2k3 VM with the latest VM Workstation. I started by bridging the net connection, and after experiencing enough issues during initial setup, I found that I couldn't connect to my server running it privately (even from the host running the VM). So I ended up changing the "eqemu_config.xml" file to reflect "eqemulator.net" insteaad of my server's IP. In the same series of tests, I changed my VM net settings to NAT using the VMnet8 virtual NIC. I then found my server in the public login list. So that was victory number one. I later attempted to login from my laptop on the same subnet as the host running the VM. ::No dice:: I thought maybe the problem was a block from Symantec, or improper port-forwarding, etc. I messed around with settings for about two hours until I decided I would tackle it later.
Today, I messed around with things again, and discovered that bridging the net connection is a MUST with VMs. Here's why.. With VMWare's new software, bridging the NIC allows the VM to run a new IP given in sequential order for the host's subnet. Though I could log in just fine with a NAT'd address from my host > svr, it is a local exception only. To allow outside traffic (or even other physically separate LAN devices) to make the connection in, you've got to have your VM on the same subnet.
If you're running a VM, set your NIC to bridged, and statically assign the IP within the VM--to avoid problems like these: http://www.eqemulator.org/forums/showthread.php?t=25720. ADDITIONALLY!!! You must set the "<host></host>" under "<loginserver>" in "eqemu_config.xml" to the IP for 'eqemulator.net'. Because previous posts have given IPs that in later years changed, I'll just say the best practice is to ping it yourself from the host (not the VM--it has no idea how to get to it otherwise you wouldn't need to do this at all). Use that IP, and ensure that the port below is still set to 5998.
You will likely still need to set port-forwarding to your server for outside connections if you encounter remote login problems, and check firewalls, anti-virus clients, etc. One reason port-forwarding won't work (if you have attempted this with no success and it left you scratching your head), is that for devices like mine, you are left with a choice to forward to ANY IP you want.....(so long as it's in your Class C -- read the fine print) within "192.168.1.*". Now, if you want to get technical, NATing is supposed to allow you to specify the networks you want to use. If you have ever worked on commercial network gear, you know that you can use completely different IP ranges. It's all available to you. However, unless you spent several hundred or even thousands of dollars on nice routers and firewalls, you are probably left with only the option to forward to just one class C-- 192.168.1.*. So, at this point, that clearly rules out the option of forwarding anything to 192.168.163.* (one of the default subnets assigned to VMs using VMnet1 or VMnet8 virtual NICs), or any other subnet outside of 192.168.1.* for that matter.
Even if you aren't running VMs, I figured some of this information could be helpful. I hope it saves someone a headache, as I have experienced several in this entire process. Happy networking :)
Let me start by saying, I'm running my server on a Win2k3 VM with the latest VM Workstation. I started by bridging the net connection, and after experiencing enough issues during initial setup, I found that I couldn't connect to my server running it privately (even from the host running the VM). So I ended up changing the "eqemu_config.xml" file to reflect "eqemulator.net" insteaad of my server's IP. In the same series of tests, I changed my VM net settings to NAT using the VMnet8 virtual NIC. I then found my server in the public login list. So that was victory number one. I later attempted to login from my laptop on the same subnet as the host running the VM. ::No dice:: I thought maybe the problem was a block from Symantec, or improper port-forwarding, etc. I messed around with settings for about two hours until I decided I would tackle it later.
Today, I messed around with things again, and discovered that bridging the net connection is a MUST with VMs. Here's why.. With VMWare's new software, bridging the NIC allows the VM to run a new IP given in sequential order for the host's subnet. Though I could log in just fine with a NAT'd address from my host > svr, it is a local exception only. To allow outside traffic (or even other physically separate LAN devices) to make the connection in, you've got to have your VM on the same subnet.
If you're running a VM, set your NIC to bridged, and statically assign the IP within the VM--to avoid problems like these: http://www.eqemulator.org/forums/showthread.php?t=25720. ADDITIONALLY!!! You must set the "<host></host>" under "<loginserver>" in "eqemu_config.xml" to the IP for 'eqemulator.net'. Because previous posts have given IPs that in later years changed, I'll just say the best practice is to ping it yourself from the host (not the VM--it has no idea how to get to it otherwise you wouldn't need to do this at all). Use that IP, and ensure that the port below is still set to 5998.
You will likely still need to set port-forwarding to your server for outside connections if you encounter remote login problems, and check firewalls, anti-virus clients, etc. One reason port-forwarding won't work (if you have attempted this with no success and it left you scratching your head), is that for devices like mine, you are left with a choice to forward to ANY IP you want.....(so long as it's in your Class C -- read the fine print) within "192.168.1.*". Now, if you want to get technical, NATing is supposed to allow you to specify the networks you want to use. If you have ever worked on commercial network gear, you know that you can use completely different IP ranges. It's all available to you. However, unless you spent several hundred or even thousands of dollars on nice routers and firewalls, you are probably left with only the option to forward to just one class C-- 192.168.1.*. So, at this point, that clearly rules out the option of forwarding anything to 192.168.163.* (one of the default subnets assigned to VMs using VMnet1 or VMnet8 virtual NICs), or any other subnet outside of 192.168.1.* for that matter.
Even if you aren't running VMs, I figured some of this information could be helpful. I hope it saves someone a headache, as I have experienced several in this entire process. Happy networking :)