Dedicated Server WAN Join Issues

[13-]

Here's a short list of the things that I have done so far:

• I have followed the "Dedicated Server Quick Setup Guide - Windows" to the letter.
  • I am experienced with SteamCMD, and have used it to host many dedicated servers.
  • I have used a custom batch file to install and validate the dedicated server.
• I have generated and procured the proper valid token file and placed it in the base cluster directory.
• I have forwarded my ports correctly, with 11000 & 11001 UDP being available for the master & slave.
  • The server is visible via LAN & WAN without any issues.
  • The Master Query port of 10889 UDP is forwarded and the ping readout is also available and accurate.
• The cluster.ini is configured with default settings, save for the hostname and description.
• The server.ini files have the default recommended values in them.
• The firewall on the server in question has the application allowed inbound and outbound.
• The server logs report no anomalous behavior.

Here's a short list of the things that I have not been able to do:

• Establish a successful connection with the server over the WAN tab.
  • My wife and I can both connect to the server using LAN protocol (LAN tab).
• Pin down why the server log no longer displays failed P2P connections.
  • Initially, when I launched the server after configuring, it was displaying failed connection attempts, presumably from other WAN players who had seen this entry on the master list.
• Understand why at times the server fails to appear on either list after being rebooted.
  • Upon inspection, there are no lingering processes using the allocated ports.
• Identify the cause of this anomalous network behavior.
  • As I have run many databases, Arma Servers (with or without embedded database functionality), and custom networking projects, the cause of this behavior eludes me.

I am therefore, asking for the assistance of others to determine the root of these asinine sets of circumstances. As far as my training and expertise goes, there is nothing that should be preventing sessions from being established via WAN. There are no interfering software suites, misconfigured OS environments, nor interloping network conditions. As far as I can tell, the problem will most likely lie within DST or it's inherent configuration documentation. Please take a look at the pertinent master and slave log material for any insight you may offer.

Note that the files presented herein have had identifiers appended to them in the form of x_master / x_slave for ease of viewing.

 

cluster.ini

server_log_master.txt

server_log_slave.txt

server_master.ini

server_slave.ini

[Daniel86268]

I've gone thorugh your configs, and they all look correct, and as you said, the logs don't hint for any issues.

How long did you wait for connecting over the list after launching the server? Because it usually takes a minute or two to list the server in the server list after fully booting up.

Another thing I could've imagined would be that there would be other services running on those ports, but you already said you checked that, and the logs didn't say anything about it, so there's everything ok.

A DST server usually doesn't need portforwarding, it just connects to the Klei servers itself and figures out the adress translation himself, but it should work either way.

One thing you can try is to chose other ports. I've heard that DST servers sometimes have issues on some ports because they are reserved by some things.

[13-]

Thanks for taking a look at everything and giving some advice.

Sadly, we have waited a variable amount of time, there were no differences in allowing 3 minutes for the master list to query the server and allowing 3 hours.

I have had a couple of issues when cycling the server too quickly, the server was unable to bind to the assigned IP address. This was resolved by allowing the previous service to shut down correctly and release port bindings for reuse. As such, I can say with 100% certainty that the issue does not lie with those ports being in use or reserved by another service or process.

And again, unfortunately, I have used alternate ports within the given acceptable range. I have used around 3 sets of alternate ports, and updated my WAN forwarding tables accordingly each time. This has yielded no difference in results.

-------------------------------------------------------------------------------------------------------------------

However, I will report that we have reached some developments as of last night. A friend of mine was able to connect using the console via our DNS address (and since DNS resolves into our WAN IP address, our WAN IP address). This begs the question as to why the server is no longer appearing on the master server list. Also, this verifies proper configuration of the forwarding table and the underlying network. To test this phenomenon, you may use the console (typically set to the tilde or ` key by most players) and enter the following:

c_connect("floorchan.ddns.net", 11000, "bastedboarriorlegs")

 

The server is quite resilient. We were testing it and it did not crash until we summoned 50000 shadow meteor at one time. It should work properly as a vanilla DST server with caves, default generation settings. I will post any further developments as they occur, any additional help is appreciated.

-------------------------------------------------------------------------------------------------------------------

Update:

The server is now appearing over WAN. However, the end result is the same. Attempting to join it via the master server list aggregates the usual error message of "server not responding". I have also created a locally hosted server on my gaming PC, forwarded the default port of 10999 (an unnecessary precaution), and discovered the exact same issues. The server displays but no one can join it unless, presumably, they use the console to join it or join it via LAN on the server list.

Could a developer or someone well versed with this issue confirm it for me? This is two separate configurations, one dedicated, one per instance hosted, that are exhibiting the exact same issues. I have hosted many things reliably without issue on both computers, and one is a dedicated server setup. I'm starting to believe the issue is not necessarily one that is laid at my feet any longer. It's a bit inconvenient that I can't have randoms join my group to play, since few, if any people would ever attempt to join a server via the console.

Confirmed as well that the secondary hosted server requires console intervention to join at all. Any help would be greatly appreciated. If the off chance arises that one would attempt to join the Sixteenth Thunderstorm's Madhouse, the password is bastedboarriorlegs.

[Daniel86268]

I just checked with the newest version of the game that it works flawlessly as usual in my Network.

Did you check if it works if you temporarily disable your Firewall to narrow down the issue? It might result from the different bahaviour of the DST server compared to other gameservers. Basicially the DST server connects to klei server lists, where all the logins, etc. are handled. And the clients first only connect to the Klei servers that route the players to the selected DST servers then. That would explain why people can directly join using the join command, and they can't join using the server lists.

[13-]

43 minutes ago, Daniel86268 said:

Did you check if it works if you temporarily disable your Firewall to narrow down the issue?

 

16 hours ago, JSomnia said:

• The firewall on the server in question has the application allowed inbound and outbound.

 

 

Please do not mistake this for a lack of gratuity, but I have allowed the server application through the firewall both inbound and outbound. Therefore, whatever ports the application will open are approved on demand by the firewall, and will be allowed to be WAN facing listening ports. This means that disabling the firewall will be a placebo and have the same literal effect that allowing an application through the firewall does.

To reiterate: Windows firewall is clearly not blocking the traffic inbound & outbound. If this were the case, my TS3 server, which has the same inbound and outbound application based rules configured, would not respond to serverqueries and update itself accordingly via TSviewer, nor would clients be able to reference the DNS name and resolve to the IP address and connect via the listening port.

Here is a visual representation of what I am saying.

Also, as I mentioned, this is null and void because I mentioned I have tested this on other network entities. I have used an alternative host which yielded the same results. The port forwarding table entries are displayed here. The colon obviously signifies a range, which in this case, is a two port range, low and high, respectively.

Also, this server behavior is quite normal and simple, I assure you. This is what I have referred to as the master server list. Information is tabulated about active servers, and is displayed on this active server directory that is periodically updated, either through a challenge or a broadcast. Since I'm not privy to it's inner workings, I can only speculate as to the directive used to achieve this, but the end result is the same. Zandronum is a source port of Doom, and it uses a similar, but truncated and vastly similar methodology. The server broadcasts it's heartbeat to the master server, which will in turn advertise it to any queries that request a server list fetch task.

Regarding your network, mine is otherwise flawless as well. I have over seven active broadcasting servers and services available, three of which are in constant use. Those would be Teamspeak 3, my domain name service, and, intermittently, my Zandronum servers. There are other servers that I run on demand as processes, but these three are my persistent service based servers, as well as my apache and MySQL framework for databases that are required by persistence on Arma 3 & DayZ Standalone servers.

[Daniel86268]

Don't get me wrong, I'm not questioning your knowlege or firewall setup at all. Your setup sounds really solid and imo most network setups should be set up as thoughtfully as yours.

It might just be that the DST server does have some background process that doesn't do what you expect it to do, or the DST server functions somewhat different than you expect. That's why I'd say disabling the Firewall temporarily will help to track down the issue. If it still doesn't work, the issue is somewhere else. If it fixes it, the DST server somehow doesn't like your firewall configuration.

[13-]

Fair enough.

I did as you asked, however the result was the same. There was no change when I disabled the firewall entirely. The exact same behavior was exhibited: no connection via WAN list (it was listed), the server was listed as not responding. The ping was displayed however, and connection via console was possible. LAN connectivity was without a problem.

I'd say it's fair to assume that the issue is somewhere else, now.

[13-]

Bump.

Still the exact same issues with no change. Hoping for either official response or professional log analysis, or just advice.

[Zillvr]

Not official response nor professional log analysis, but just advice. Have you tried disabling any active antivirus on the server or at the very least white listing the server executable? I vaguely remember some connection issues caused by an active antivirus. Again just advice worth a try, if that doesn't work. You might have to wait for a bit longer to get replies from the devs. In the mean time, maybe this Klei Support Article: Network and Performance Troubleshooting Guide can help you. Good luck.

[13-]

I appreciate the response. I only have BitDefender free on the server, I have tried disabling it, and it has no effect, as this suite has no network restrictive components. I checked the logs, and no heuristics have restricted any associated processes. I'll run a more thorough test later on today. But thanks for the reply!

[13-]

Update: I can't believe I missed this, as a networking student and upcoming professional, I am quite ashamed.

Last night, I played a hosted server on my client. Nothing special, just launching it and allowing it to set up preconfigured dedicated binaries in the background, as it usually does when hosting from the GUI inside the game.

I realized that someone had joined my game. The ports were not forwarded. That made me realize that the dedicated servers use UPnP. Idiocy at it's finest.

I then realized the error codes that prevailed lately when I forwarded the ports were UPnP error codes, specifically 718,

AddPortMapping(11000, 11000, 192.168.1.105) failed with code 718 (ConflictInMappingEntry)

Hmm, now why would it fail to map a port that's forwarded...

Because it's utilizing UPnP. It took reading this for my brain to finally process the information.

https://forum.transmissionbt.com/viewtopic.php?t=15621

Upon inspection of the router, I discovered that in the tables and log, the ports are indeed forwarded, but no sessions or traffic has been established because these ports are being reserved.

Upon removing said reservation, UPnP has negotiated successful sessions. Case closed.