Awaiting Challenge...
Awaiting Connection...
The client retries a few times and then gives up with
Server is not responding or a silent return to the menu.
Cause
The client sent a getchallenge packet to the server and received no reply. The server
process may be perfectly healthy — the packets are not arriving, or the replies are not
getting back.
In rough order of likelihood:
- The game port is not open inbound as UDP on the host firewall or the provider's security group.
- The server is bound to the wrong interface or a different port than you think.
- Port forwarding is missing or wrong on a home router.
- The server is running with
dedicated 1(LAN) instead ofdedicated 2. - The server is genuinely full or the process has hung.
Diagnosis
From a machine outside the network, send a raw Quake3 status query. This bypasses the game entirely and tells you whether UDP reaches the process:
printf '\xff\xff\xff\xffgetstatus' | nc -u -w2 YOUR.IP 28960 | head -c 400
- Configstrings come back — the server is reachable. The problem is on the client side or specific to that player's route.
- Nothing comes back — packets are not reaching the process, or replies are not returning. Keep going.
Check what the server is actually bound to:
ss -ulnp | grep 28960
You want 0.0.0.0:28960. If it shows 127.0.0.1:28960, the server is listening on
loopback only.
Fix
Open the port as UDP:
sudo ufw allow 28960/udp
# or
sudo iptables -A INPUT -p udp --dport 28960 -j ACCEPT
Cloud providers have a second firewall in their console. AWS security groups, Hetzner firewalls and OVH network rules all need the UDP rule added separately from the host firewall. A host-level rule alone is not enough.
Confirm the server is internet-mode:
+set dedicated 2
dedicated 1 is LAN-only and will never accept outside connections or reach the master.
If you run in Docker, use host networking rather than published ports — see Docker setup.
