Why can I access nginx but not a C server socket in my server at home?

Question

I have a Debian server machine at home with NGINX. Right now it is only serving the default index.html that installs along with nginx. I got myself a hostname in Dynu and got TLS certificates with Let's Encrypt

I can perfectly access my default nginx website on the web browser using my hostname and everything is working fine.

But I need to implement a simple server socket in C in this Debian server listening on port 8080 and connect to it with a client socket in C from any a computer via the internet.

My problem here is that despite having already forwarded port 8080 in my home router and having added port 8888 to the Debian server firewall (sudo ufw allow 8888/tcp and sudo ufw allow 8888/udp), I still can't connect to the server socket.

If I run both server and client socket programs on the same machine, they work just fine when connecting the client to localhost so I know the code is working fine. The problem is when I run the server socket program in the Debian server and the client socket program in my laptop they don't connect whether I use the Debian local address or the dynu hostname.

When I run the client it finishes with the error Connection refused and the server socket program doesn't even blink, it just stays on Waiting for connection on port 8888.

I mentioned at the beginning the nginx, the hostname, and the certificates because I don't know if this could be conflicting with a nginx-independent c server socket, I mean, I don't know if that is a restriction of nginx. I don't think it is because I'm using a port different than the ones nginx is configured with, but I'm not sure. I have even sudo systemctl stop nginx'ed the nginx server but that doesn't help.

What am I missing?

UPDATE: ok, I ran my server socket and put it to listen, then I ran netstat -ntlp and now I can see my server socket application as:

tcp        0      0 127.0.0.1:8888          0.0.0.0:*               LISTEN      8959/socket-server/

I had to change to port 8888 because port 8080 is being used by "WWW Cache" (whatever that is), but the client still doesn't connect.

My socket server is binding to an address obtained by getaddrinfo(NULL, port, &hints, &server_info)

Answer 1

Your netstat output explains what is happening:

$ netstat -ntlp | grep 8888
tcp        0      0 127.0.0.1:8888          0.0.0.0:*               LISTEN      8959/socket-server/

The 127.0.0.1 address is the "localhost" address and what this line indicates is that your server is listening on "localhost" only!

You should reconfigure or patch your server so that it's listening on an address that can be reached outside of the machine where it's running. Typically 0.0.0.0 (which means it's reachable at "any" address attached to the local machine.)

If you have the C code for it, look at whether it's binding its socket to INADDR_LOOPBACK, that would mean the 127.0.0.1 address, in other words "localhost". You can try to change that to INADDR_ANY, which means the 0.0.0.0 address, which will be accessible through the network (assuming a connection isn't blocked by a firewall or other kind of filtering.)

---

UPDATE: The man page of getaddrinfo(3) explains the behavior when the passed node address is NULL:

If the AI_PASSIVE flag is specified in hints.ai_flags, and node is NULL, then the returned socket addresses will be suitable for binding a socket that will accept connections. The returned socket address will contain the "wildcard address" (INADDR_ANY for IPv4 addresses). The wildcard address is used by applications (typically servers) that intend to accept connections on any of the host's network addresses. If node is not NULL, then the AI_PASSIVE flag is ignored.

If the AI_PASSIVE flag is not set in hints.ai_flags, then the returned socket addresses will be suitable for use with connect(2), sendto(2), or sendmsg(2). If node is NULL, then the network address will be set to the loopback interface address (INADDR_LOOPBACK for IPv4 addresses); this is used by applications that intend to communicate with peers running on the same host.

While one possible way to fix your problem is to pass a "0.0.0.0" address to the function:

getaddrinfo("0.0.0.0", port, &hints, &server_info)

Another possible solution is to update hints.ai_flags to include AI_PASSIVE.

Answer 2

If it's working on the local machine with localhost then it's likely a firewall issue on the Debian server. Those ufw commands you used look like they should have worked, but maybe try sudo ufw allow 8080 instead of specifying the protocol with the /. You can always check your firewall's open ports with iptables -L to see if your commands got set properly.

Here's more data on ufw if you want to play around with different syntax. If you want a more direct approach, you can set the firewall settings directly with iptables, using a command like this:

$ sudo iptables -A INPUT -p tcp --dport 8080 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
$ sudo iptables -A OUTPUT -p tcp --sport 8080 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Hope this helps.