- Home /
server connecting issue
I have a multiplayer game set up with 2 computers, one hosting a master server and another connecting to it. There's no issue when I try starting the server on PC1 and connecting PC2 to it. But when I start the server on PC2 and have PC1 try to connecting to it, the error "The connection request to 192.168.0.101: 25000 failed. Are you sure the server can be connected to?" comes up.
I've tried turning off the firewall on both computers and disabling any anti-virus programs but still no luck.
Has anybody run into this issue?
Answer by syscrusher · Oct 12, 2015 at 12:51 AM
Greetings
I'm not a Unity expert yet, but I am a network professional so I thought I'd weigh in with the fundamental network things to check.
The first thing to figure out is whether the server is listening on the port you think it is (port 25000 in this case). Ports below 1024 are "privileged ports", and opening a socket on those requires admin privileges on the server. Since you are using port 25000, that's not an issue here but I mention it for completeness.
The server could fail to listen on a port because it isn't configured to do so, but I assume you've checked that. Where are you specifying your port choice, and does that config setting exist on both of your test servers?
It could also fail to listen on a port because the port is already in use by another process. If you are on Linux or Mac, there is a "netstat" command line utility to query what processes are listening on what ports, for both UDP and TCP protocols. The "netstat" utility exists on Windows also, but I know it has slightly different syntax there so I can't tell you exactly what command to enter. The point here is that if another process -- such as a still-running previous test instance of your game! -- is still listening on the port, the new one will not be able to listen, and you may not have seen the error message in the log yet. In some cases, a process may end but there may be a time delay before the operating system figures out that its IP ports have become available to another process. This usually happens if the first process crashed rather than exiting cleanly.
Check also the IP address setting for the server's socket listen. If you listen on IP 127.0.0.1 (or, actually, anything 127.x.y.z), you are listening only for the "loopback interface" which is invisible outside the local machine or even to virtual systems within that physical context. The loopback is provided to allow network software to interact across process boundaries without the security risk of listening on an externally-visible interface. If you want to listen on a real interface, you need to listen on port 0.0.0.0 (which means "all" interfaces) or the specific IP of the interface desired. References to "localhost" imply the loopback interface on most systems.
Assuming you are listening on the desired external interface and port, the next thing to check is the firewall configuration. Again, I'm not a Windows person so if that's what you're running I am not going to be very helpful. If you're running Linux, write back and I can go much deeper.
Finally, check the client system(s) to make sure they are pointed at the IP of the server and that you didn't accidentally copy the IP of the client onto the server or vice-versa. It's a common error in networking if you're configuring both at once.
It's also possible -- though rare -- for firewall settings to be such that system A can contact system B to open the connection, but system A's own firewall is rejecting the replies. Most workstation firewalls automatically track and map "related" and "established" connection traffic, so this situation typically occurs only in more complex network setups such as VPNs and multi-site corporate environments.
I realize this isn't a direct answer to your question, but I hope this gives you some background to check.
Hi @syscrusher. I have a unity networking game that I got working twice in two locations without changing the game code. I've recently moved once again and am using a new router and the game will not connect remote clients, only local clients using localhost as the Network Address. I'm using No-IP for my dynamic DNS and have ensured that is working properly and updating my external IP address. The address for No-IP is what I place in the Network Address field (mmoerpg.ddns.net in this case.) I went in to my router and forward the port that the game uses which is 4444 allowing both TCP and UDP connections to the internal IP address of my server which was set to static. Still, when I try to connect a remote client using these settings, it does not connect although it used to using these same settings. I began to think it was the new router (I would use my old router for trouble shooting but the new router is modem/router combo and is designed for DSL whereas my old modem is for Cable.) To test that the router had in fact forward the ports correctly, I went to www.portchecktool.com and test port 4444. First, it said that the connection was ti$$anonymous$$g out. I tried disabling the firewall on my server and tried again. This time it, much more quickly, it said Connection refused. I then tried running the game on the server with the firewall disabled and still, the port check tool said Connection refused. So it now seemed that the port was forwarded properly as it was trying to get into my server but the server was refusing it. The next thing I checked was whether my game was actually listening on the right port after starting and that that port wasn't already being used by another program for some reason. I opened cmd with ad$$anonymous$$ rights and used the netstat -a command which shows all ports currently being listened to. Port 4444 was not on the list. Great, nothing is using the port. I launch the game and start server then check netstat again. This time it shows two UDP instances listening to port 4444. What is strange is that the prefix for the port is not my servers internal IP address which I thought it should be but then again I don't really know. The prefix for one was 0.0.0.0:4444 and the other was [::]:4444. Could this be my problem? or is this normal when a program is listening on a UDP port.
First of all when you have a question why do you post an answer on a foreign question?
Anyways, 0.0.0.0:4444 is correct. "0.0.0.0" is the local binding address for the socket. As you might know IP communication uses IP addresses inside of a packet to specify the target location. In order to receive packets one has to "open" a port first. In addition to specifying the port you can also specify what local address you want to bind to. That means only packets which are sent at that specific IP address are actually received. One computer / peer can own multiple IP addresses at the same time. You usually have a local network address as well as the local loopback address which however is only valid within your own system. The address 0.0.0.0 is a special address which simply means "all addresses". So there's no restriction which the actual target IP is, you will get any packet on that port that arrives at your NIC.
Note: some routers have their own firewalls built-in so make sure you check that. Also keep in $$anonymous$$d when you forward ports to choose the right protocol. When in doubt you can forward both (TCP and UDP).
Some other routers (i have such a crap :|) don't allow local loopbacks on the public IP of the router, That means the whole world can connect to your router, except you how sits behind this router. All routers i had before had no problems going out and co$$anonymous$$g straight back in using the public IP. However if you use an external site to test the connectivity that shouldn't be the problem.
I suggest you install a packet monitoring software on your server (something like WireShark) to see if you receive anything. You can do the same on your client to see what goes out and what comes back. If you get a connection refused you should receive an IC$$anonymous$$P message with "delivery failure".
Thanks @Bunny83
I created a new forum question that can be accessed here: https://forum.unity3d.com/threads/remote-clients-can-no-longer-connect-with-new-modem-router.443153/
Thank you for the confirmation, information, and recommendation. I'll download the monitoring software and see what it exposes.