Server Has Port 16262 Closed

[Manric Hock]

Theport 16262 closed" error is specifically caused by the 16262 UDP port not being correctly opened either on your router or in your firewall. I can only recommend making sure that you correctly port forward the UDP protocol 16261 and 16262 ports to your Local IP. Alternatively, it will show up if you use the "Use Steam Relay" option when connecting to a dedicated server. In which case it can be ignored, if the Steam Relay provides better stability over the direct connection.

If doing that still does not work, I can only recommend contacting your Internet Service provider to make sure that they allow hosting a server on your IP and that they do not block the 16262 port themselves.

So I've been playing with friends via Steam hosting for months, but all of the sudden this error started coming up and our latency is horrible.

I never forwarded any ports and it seemed to work okay, but now this error is a thing. Nothing changed with my system/router. Two of us have this error when trying to host, but one of us can host normally and this error doesn't happen for this person.

Happens without any mods too.

Game files integrity verification did nothing.

I've been trying to resolve this for weeks, but all of the information in the internet seems to have nothing to do with Steam server hosting, plus we've been playing just okay for months, this error occured out of nowhere.

What might cause this?

Most rational thesis seems to be "just forward the ports", but it worked just fine for months and the person who hosts for us now doesn't have them forwarded and it works fine for them. Seems like the issue lies elsewhere.

This update should answer that question, the port was added there, your latency is likely a placebo, or a network issue, because if you do not use the port, you basically use the exact same protocol as you did before the update.

So I seem to be getting the port 16262 is closed, performance might be severely affected warning when connecting to my server.

The server is installed through steam cmd and I try to connect from a client started through steam (using the ingame server browser/entering the IP manually).

Port 16262 is opened for UDP connections and I have verified that it is indeed open by shutting down the server and listening 16262 UDP through netcat, then connecting from my local machine to the server (Hosted with an dedicated IPv4 address) and I can see my packets arriving meaning that server-side configuration (firewall) must be correct.

I tried with UPnP enabled and disabled but always get the same errors.

Is there some way to debug the client and check if its actually trying to connect to 16262 or using some different port since online youll find ambiguous reports that it actually uses some range instead of this specific port or similar.

I am not familiar with any specific service that checks for UDP ports, though if the game tells you that it is closed then it would indeed be likely closed. Did you make sure to port forward the port through your firewall and router? Specifically the UDP protocol. Preferably do not use ranges, as some routers might have issues with those.

Well, the server is a hosted root-server with a dedicated IP in a server-cluster. There are no real firewalls in that sense, all traffic is routed to my server.

Then, theres the UFW firewall running inside my Ubuntu distro where I host the server. The UFW firewall is open for 16262 on UDP (as well as 16261).

NMAP or NetCat can be used to test UDP packets. You basically install it on the host that youre trying to test, let it bind to port 16262 (thats why the PZ server must be shut down) and then you try to send an udp packet using another netcat instance towards the server from a remote machine. If you see some inbound traffic you can be sure that the port is forwarded.

Anyways, Ill try to disable the firewall completely on this host and check if the connection works then.

Thanks so far, if I have some finding Ill report back, maybe it helps some other users.

I disabled the firewall completely meaning that all ports are fully exposed but the warning message was still shown.

This looked very suspicious so I had a closer look at the client and I found that in the server browser/connection profile I had the steam relay enabled.

I wonder why this is the case since when I add a new server the option is disabled by default it seems. However some other people playing on my server also reported to me that the steam relay option is enabled in the connection profile of their clients and they see the message. Neither them or myself remember enabling this option manually.

Anyhow, once I unticked the checkbox the warning disappeared. Furthermore, I was able to limit the firewall to 16261 UDP and 16262 UDP only and everything works fine.

Just want to add that my ports appeared to be open on my setup, but when I checked it remotely my 16262 was actually closed. It turned out the router my internet provider had given me is full of issues regarding this.

I am not personally aware of any reputable UDP checker tool. Since the game uses UDP and not TCP, then the standard port checkers will not work.

I would only suggest just using the connection to the server as a test itself, if the port shows up as closed, then it is closed.

In our travels fixing the issues, the networking has been changed so as to more directly communicate between server and client. The server now has 2 ports to connect to. The game port (16261 by default) is used to handle Steam queries. The additional port (16262 by default) is used to handle the direct connection, and thus circumnavigate the data travelling through the steam network which was impacting latency and throughput significantly. These ports can be configured through the server options.

The two new entries are in fact in the list, but when I checked to see if the two ports are open it said that both ports (16261/26262) are still closed. What am I doing wrong? A Teamspeak 3 and CS:GO server are already running without problems...

Actions taken to resolve so far: I have port forwarded the following ports: 19132, 16262, 8766, 8767.

I have connecting though those ports externally but nothing.

I have adjusted the firewall rules to allow the connections but nothing.

Is there something im missing in configuring the server?

And it waits and waits, nothin happens. I'm pretty sure it's because no connection has been requested from the outsite of the network on that specific port (16262) that the outgoing traffic can't be sent, but I was wondering if anyone else has tried to make it work.

If the client's public ip address is known, you can perform a basic troubleshooting whitin Google Compute Engine using Cloud Logging. A basic query returning all the logs containing that ip address as source or destination would be:

Note: If the traffic hitting the firewall rule(s) is too much, it can lead to unanticipated storage costs. Please enable the firewall rules logging just for troubleshooting purposes, don't forget to disable it after you're done.

Is there a maximum number of forwarders that a single indexer can support, or is the limiting factor on the indexer just the amount of data sent by the forwarders? If there is a maximum # of forwarders per indexer, how does that scale in an auto-lb environment with multiple indexers?

I don't know of a theoretical limit. The highest I've seen is 6,000 forwarders reporting to a single indexer. It was a subset of WinEventLogs, so in aggregate the volume was low - about 150GB/day. Splunk does a good job of managing connections, and the overhead is low so long as you don't require SSL. You will have to increase the file descriptor limit (ulimit -n) to allow for all those sockets to be referenced.

Assuming there is a limit somewhere, you make a good point that auto-lb would not help. I'd recommend an intermediate forwarding tier. You would explicitly assign each client forwarder to one of multiple intermediate forwarders, and then have the intermediate forwarders LB amongst the indexing tier. Keep in mind that a forwarder will only be able to LB about 200GB/day of data. You'll also have to be careful which forwarders execute which parts of the parsing pipeline, which can get tricky.

There will be a practical limit imposed by the TCP/IP network stack implementation on the indexer. At a very minimum, there will be a limit on the number of available ports that other servers can connect to, something less than 65,535. There will be lower limits because of reserved ranges, and there may be even lower limits simply because of limitation on the operating system to track a number of connections.

3a8082e126