I got it working. I will need to do more testing, but I noticed in the wireshark I captured yesterday that there were icmp unreachable messages. So, I wondered if maybe the server was arp'ing for some reason trying to find the client. But if the server arps on 172.x it is not going to work, since the client is on 192.x So I looked at the local_network line in the login.ini Rather than have that reflect the server dmz address, I changed it to reflect the client local network, 192.168.0 And, voila, it works now with the client on a different subnet than the server.

Not 100% positive that is what fixed it. I'll test some more to confirm.

Definitely seems to be the local_network setting. When the server is on 172.x, and the client is on 192.x, then I need to have the local_network setting reflect the network prefix of the client network, not the server's local network.

See below from my current login.ini:

[database]
host = 172.16.210.11
port = 3306
db = peq
user = root
password = eqemu
subsystem = MySQL

[options]
unregistered_allowed = TRUE
reject_duplicate_servers = FALSE
trace = TRUE
world_trace = FALSE
dump_packets_in = FALSE
dump_packets_out = FALSE
listen_port = 5999
local_network = 192.168.0.
auto_create_accounts = TRUE

[security]
plugin = EQEmuAuthCrypto
mode = 5

[Titanium]
port = 5998
opcodes = login_opcodes.conf

[SoD]
port = 5999
opcodes = login_opcodes_sod.conf

[schema]

So, now I wonder, can you have it both ways? Have the server in my dmz where I connect to it as described above, but also allow for public logon? Would I just need to have both login servers specified in login.ini and, of course, forward the necessary ports from the web? That should do it?

Hmmm, I never changed that setting from the default of "192.168.1.", I think I remember somewhere that it says make no changes other an DB entries for username and password. I use localhost even with in both my servers for HOST. Try just putting it back to how it was normally the above "192.168.1."

I run mine on VPS hosts as well as at home with no problems.

I changed it back to localhost for db, and the default 192.168.1. and I cannot enter the world.

I'll try localhost for db, and 192.168.0. for local_network... Well, that seems to work. It seems, for me at least, that I need to have the correct prefix in the local_network setting. hunh..

That is very odd indeed. My VPS servers have public IPs and I left the local at 192.168.1. but have no issues from other subnets. I wonder if you could add multiple privet subnet prefixes in that line?

What happens if local_network = blank?

Your subnet needs to match whatever your LAN is using...

If you're behind your router, then you should be using the local subnet.

Pretty sure a dmz still puts you behind the router.

I tried to be clever and put local_network=0.0.0.0 no joy.

So, this is only for the mini login server? If you are doing a public server, I assume this does not apply?

A dmz would put you behind a router in the consumer sense, yes. Consumer "routers" are not really just routers. They tend to be wireless access points, routers and security appliance/firewall all rolled into one. In this thread, when I say router, I don't mean a device that separates me from the Internet. I mean an actual router. A device that simply forwards a packet on to it's next hop and performs no other security at all.

So, in my case, the server is on a local subnet that uses 172.16.210.0/24 for addressing. I have been calling that "dmz". (I will eventually move that network to a proper dmz on an edge device like a firewall soon, I just wanted to work out this stuff first). And my PC is on a different local subnet that uses 192.168.0.0/24 for addressing. I can only access the emu server is I set the local_network=192.168.0. Technically, they are both behind a router as in a device that forwards packets based on layer 3 route tables, and they are also both technically local subnets in the sense that they are not directly on the internet and are behind a firewall. Though the traffic between the emu server and the pc does not pass a firewall, it passes a router.

Sorry, probably too much information and a bit pedantic.

My bad.