I have a Quake 3 server. And it's launched successfully.

The problem is that no one can connect to that server.

I am running: nmap -sU -p 27960 hostname and it's showing me that it's state open|filtered

if I am running that command right from the server it is open.

Also, I am making sure that it's binding to the right iface

I checked the iptables rules and couldn't find any filters related to it. Furthermore, I tried to open the port explicitly via iptables -A INPUT -p udp --dport 27960 -j ACCEPT

but this didn't help.

What it could be?

I called to ISP support center and they said they are not filtering anything.

  • Whether the iface in which you are hosting the server is having public or private IP ? Nov 4, 2012 at 14:34
  • @pradeepchhetri it has only one, public IP
    – bakytn
    Nov 4, 2012 at 14:34
  • If you are using linux machine, can you try connecting using nc <ipaddress> 27960 from some other machine. Nov 4, 2012 at 14:41
  • Which Linux Distro you are using ? Nov 4, 2012 at 14:48
  • I run that comment from my laptop to that server. it's just stuck. nothing is shown. The distro is Ubuntu 12.04
    – bakytn
    Nov 4, 2012 at 14:57

1 Answer 1


Getting different nmap results from local machine and remote machines means there is some kind of firewall(whether running locally or some remote machine) which is blocking. According to the nmap documentation,


Nmap places ports in this state when it is unable to determine whether  
a port is open or filtered. This occurs for scan types in which open
ports give no response. The lack of response could also mean that a 
packet filter dropped the probe or any response it elicited. So Nmap 
does not know for sure whether the port is open or being filtered. The
UDP, IP protocol, FIN, NULL, and Xmas scans classify ports this way.

I would recommend you to try out following tools to find out whether exactly the problem exists:

  1. To capture the UDP packets destined to port 27960 using tcpdump and . Check whether the packets are reaching your machine or not.

Run the following command to capture the udp packets destined to port 27960 in a file tcpdump.out

$ sudo tcpdump -A 'udp and port 27960' -w tcpdump.out`

Try connecting from other machine to port using netcat

$ nc <server-ip-address> -u 27960

Now stop the dump and check whether any packet got captured in the tcpdump.out or not using wireshark.

$ wireshark tcpdump.out

If no packet got captured, this means some intermediate device(firewall) is preventing the communication. Else, if captured check the reply which the server is giving in return of the request. If it is any kind of ICMP reply with some error code, it means there is some local firewall which is blocking.

  • This is cool! I see that packets are really coming. But client can't connect and no error msgs in the client side for some reasons. I also couldn't find any ICMP packets. But I think the question is actually answered. Other things are not quite related to my issue.
    – bakytn
    Nov 4, 2012 at 16:11
  • There is some problem, which we are still not able to figure out. Nov 4, 2012 at 16:13
  • I am making some local tests. Will keep updated here
    – bakytn
    Nov 4, 2012 at 16:36
  • @casey_miller: Awesome !! That would be really helpful. Nov 4, 2012 at 16:51
  • This is still strange. I tried another server but before testing on a remote server I tested on the LAN just to make sure client and the server are fine. So it worked! But after I moved the q3 server to the remote server and launched - no luck. "Awaiting connection ...<nn>"
    – bakytn
    Nov 4, 2012 at 17:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .