Unable To Open Linode Custom Port

Ultimately, this question delves into the difference between allowing traffic along a certain port via your firewall settings and whether or not there are any programs actively listening on that port.

In this instance, while you may have created rules to prevent a custom port from being closed/traffic blocked, you will still need to map a program to use that port and that program actively be running to listen for in-bound traffic. You can check to make sure your program is running by using the command: (sudo) systemctl status $PROGRAM_NAME.

If your program is not running, the port will not report as OPEN even if you have made the necessary rules to allow access along that port. To start (or restart) your program, run the command: (sudo) systemctl start (restart) $PROGRAM_NAME.

Once you've ensured that the program is actively running, you can verify which ports are currently open through the use of netstat and ss:

• Check Open and Listening Ports on Linux Using netstat and ss | Linode

You can also use the scanning tool NMAP determine if your Linode's ports are open, closed, or filtered. That said, you need to be careful since our Terms of Service - Acceptable Use Policy (AUP) prohibits scanning of servers without the owner's pre-approved consent. In this case, you are the owner of your server, so you should be fine as long as you do not place abuse reports against your own actions.

In Linux what usually happens if the port itself is open:

If a tcp SYN (first tcp) packet is sent Linux replies with a tcp RST packet. Had a firewall dropped, not rejected, the SYN packet then Linux wouldn't even reply, the SYN packet just gets dropped. If a firewall REJECTs the packet then instead of RST there is an icmp reply.

If a udp packet is sent to the port then Linux will typically reply with a icmp destination port unreachable packet if nothing is listening on the port. An iptables REJECT rule will send an icmp packet too. If the packet is simply dropped there is no icmp reply just like with a tcp drop.

So a packet capture tool like tshark or tcpdump will reveal if Linux responds (port is probably open) or if Linux does not (the packet is seen but there is no response to it, which is definitely a firewall drop assuming other networking like apt/yum update works on the vps). For example:

tshark -i eth0

then try nmap or a port checker to send some packets to the port.

Finally nothing about what I said is absolute. I'm just describing what "usually" happens if the port is open but no application is listening on it and networking otherwise works. And if the Linode firewall is dropping the packet you will not even see the packet in a packet capture on the vps because that's "outside" or "before" your server for incoming packets.