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.