2

Ubuntu server 16.04.1 . I used ufw to open port 27015 (without specifying protocol, so both TCP and UDP), which is required for RCON access on Source servers. According to both ufw and iptables, port 27015 is open.

$ iptables -L -v -n

{snipping other unimportant rules}

 0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:27015
85  4505 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:27015


$ ufw status
Status: active

To                         Action      From
--                         ------      ----

{snipping other unimportant rules}

27015                      ALLOW       Anywhere

So according to my firewall, both tcp and udp, port 27015 is open.

However, every other application does not agree with this.

$ nmap localhost -p 27015

Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-06 16:09 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00033s latency).
PORT      STATE  SERVICE
27015/tcp closed unknown

Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds

Why is port 27015 closed on TCP? What can I do to actually open the port?

The server is hosted on DigitalOcean if that changes anything.

Improve this question
  • 2
    Do you have something actually listening on that port? If not then it can appear to be closed because there's nothing that is responding – Thomas Ward♦ Oct 6 '16 at 16:20
  • I should have the Source server's Remote Console listening on that port, and since the server's running it should just work alright. UDP works on the port, as the server's running and people can connect to it. – Nick Versteeg Oct 6 '16 at 16:27
  • The nmap scan used TCP connection attempts which would likely not work as expected if UDP is all that is accepted. UDP port scanning is not as accurately representative of things being open either, but you could try passing the option to do a UDP scan instead. – Thomas Ward♦ Oct 6 '16 at 17:05
  • I did that, and it gave an open|filtered . However, I have fixed the issue, and I'll add that as an answer now. Pretty amazing how I always turn out to find the answer in plain sight an hour after asking on communities! – Nick Versteeg Oct 6 '16 at 17:07
2

As it turns out, Source servers use local addresses by default when you do not specify your IP when launching the server. However, this behaviour causes the remote console to break for a reason that is beyond me.

If you launch your Source server, make sure to launch it like so:

./srcds_run +ip <your IP here> +port 27015

By specifying your IP address, it'll actually work. By not specifying the IP address, I assume it'll try to bind 27015/tcp to localhost, which is not reachable from the outside. So, nothing is listening on port 27015/tcp on the outside, which is why the port appears closed.

Improve this answer
  • 1
    Its a little more fun than that. The output by srcds is: Server is hibernating Connection to Steam servers successful. Public IP is 99.99.99.1. Assigned anonymous gameserver Steam ID [A:1:123456789106:1234]. VAC secure mode is activated. ... Making the rcon bind to the non-existant (locally) ip address 99.99.99.1. You can actually program your router to bounce that back to your server (sometimes) – ppostma1 Jun 1 '17 at 1:03
  • unix.stackexchange.com/questions/119269/… shows me to try this: SERVERIP="$(ip addr | grep 'state UP' -A2 | tail -n1 | awk '{print $2}' | cut -f1 -d'/') ; ./srcds_run +ip "$(SERVERIP)" +port 27015 – ppostma1 Jun 1 '17 at 1:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.