vittorioromeo/quakevr

"Connection accepted" but multiplayer does not connect

cplemaster opened this issue · 4 comments

cplemaster commented

I'm attempting to host a server and I can confirm that the NAT is working, but my clients connecting to my server get no further than the console stating "Connection Accepted". (The port says 65000 because I was testing other ports than 26000 for luck)

image

cplemaster commented

Adding to my findings here as I go:

Connecting via a direct LAN IP works. For example, in my case 192.168.25.150:26001 works on a local PC on my network. I get Connection Accepted and then it immediately spawns the player.

If I try the same thing on the other machine but this time I specify the NAT (my public IP with NAT rule for 26001 to the destination machine [192.168.25.150] ) it just sits on Connection Accepted.

https://sourceforge.net/p/quakespasm/bugs/3/

This was posted way back in 2012. Maybe related? Seems really old though. Anything I can do to help test I'll freely do.

EDIT: Looking at my Pfsense logs, it appears that outside IPs that request to join the server are using a new destination port each time, however specifying a massive port range to NAT (avg. 40000 to 65535) doesn't actually successfully let the user connect still. Kinda odd. I'll test with a VPN connection from outside tomorrow morning and see if it alleviates the issue.

vittorioromeo commented

Please keep me updated on this - I have played online with a few people from our Discord so it can definitely work. There must be some issue with certain configurations. I will try to merge the networking improvements made in quakespasm-spiked for the next version.

cplemaster commented

image

Here's a packet capture for example; Each time a new connection is initiated, UDP packets are sent to the intended server port (in my case 26001, but regardless of port the behavior is the same), but then additional UDP packets are sent to a seemingly random destination port.

In this example, you can see in the log that one of my attempts sent 2 packets to the server port, and then immediately started sending packets to port 50707 behind my NAT. In the middle of the image was a packet from another attempt, which ended up with UDP packets going to port 60563.

I'll be testing outside my own environment to confirm whether or not this is just a firewall problem. If I simply try to NAT the entire port range I get "Forged Packet" on my server log, so that's getting somewhere I guess.

  • 👍1
cplemaster commented

I managed to get someone to connect.

  1. Watched TCPView/Netstat
  2. New ports for the executable would appear in the list of listening ports (the random UDP ports I described) when someone received "Connection Accepted"
  3. Forwarded each new port as they appeared
  4. User connected and spawned as soon as NAT was applied

This issue was not present on a dedicated server that did not use any NAT. I assume what is supposed to be happening is UPnP opening these ports by itself as they are generated, but they don't seem to be for some reason... Let alone if someone has UPnP turned off which is more common nowadays :(

Hey at least I got it working somewhat!