Opened Port in Yast Firewall Settings Refuses Connections

English Network/Internet
1

Hello All,

Firstly, my apologies if this has been a repeated topic but I haven’t had much luck.

We are setting up a custom TCP sockets server application on Open SuSE 11.1 for our online product and we’ve tried to poke a hole through the built in firewall but socket connections from clients on the local network are still refused on the port we opened. If we run the client locally on the same box it’s ok; it used the loopback address of course when the host name was looked up.

From what I’ve learned from other threads, the firewall configuration found in Yast serves 2 purposes. It not only keeps people out but it also manages port forwarding. So turning off the firewall doesn’t fix the problem because it disables even having the open port.

Is there an easy way to determine if the port we opened actually truly is opened up?

I have not configured our server yet as a background service, we are just running it from the command line to do intranet only testing at the moment and generate logs and debug.

Source code checks out, same source runs under OS X and Win32 socket environments without connection refusals so I am pretty sure its got something to do with our Linux boxes’ setup.

I’d appreciate any Linux guru advice on the matter.

Thanks,

Lyndon

2

Can you be more descriptive/informative about the devices between the application (that you want others to link to) and the outside internet. For example it might go something like this:
“application in openSUSE” → SuSEfirewall2 → LAN → router (what kind of router) → broadband wireless link → Internet
Or something else.

3

When a firewall is not running, and the port is not responding, it’s simply because nothing is listening on it. Does your server process actually listen to all interfaces? You can check if a process is listening on port N by doing:

netstat -atnp

and then looking for a line like this:

0.0.0.0:N … <name of process>

under the column local address. If however that column says

127.0.0.1:N

then it’s only listening on the localhost address and unavailable to other machines on the LAN. It all depends on how your server process is written and started.

4

Thanks for the info on the netstat command. Yes, we invoke our server program in the console by hand at the moment and I can see that it is running because when the listening socket fails to receive a connection I print out a text message and then sleep(1); the listening socket is non-blocking type.

The result I see from netstat is the following:

tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN 4626/server

Our program is intended to listen for any incomming TCP from any IP on port 6000.

In the C source, before we call bind() our socket descriptor is setup as:

memset( &serverAddress, 0, sizeof(serverAddress) );
serverAddress.sin_family = AF_INET;
serverAddress.sin_port = htons( listenPort );
serverAddress.sin_addr.s_addr = htonl( INADDR_ANY );

I see from netstat that the IP it is listening for is 0.0.0.0? Is this the correct value resulting from INADDR_ANY?

When compiled and the program is invoked on OS X, our server program does connect to all clients correctly from anywhere on the network. This was the reason I suspected there was port blocking issue or we need to set something explicit perhaps when we create the socket under Linux?

I tested again, and double checked that the port was open on both the server and the client (both machines are OpenSUSE 11.1), saved settings in Yast Firewall panel, rebooted, connection refused again. All clients fail to connect to our OpenSUSE box but do connect when our server program is running on OS X or Win32.

When I added the open port for the Yast Firewall panel it was the field I discovered from another previous thread. YaST -> Security and Users -> Firewall -> Allowed Services -> Advanced -> TCP Ports -> 6000 -> OK. The other fields are left empty because I only care about TCP port 6000.

Then I save & restart the firewall, I double checked that under YaST -> etc/sysconfig/ Editor panel that the port is still 6000. It checks out.

So I guess if the YaST tool is reporting the correct values then it has to be either in our code or its a Linux related sockets API implementation issue that I am not aware of.

5

6000 is a very unfortunate choice for port number. It is the port that the X Windowing server listens to. If you had checked the return status from the bind call you would probably have found that it failed because the port was in use. OS/X doesn’t use X so there is no problem with using 6000 there.

6

Today after I found some information here specific to Linux boxes and sockets programming:

Socket Programming

I moved it from port 6000 to something higher like 33333 which I confirmed wasn’t being used by anything under OpenSuSE 11.1.

Port 6000 was a poor choice. Moving the higher port to a different number isn’t working either. Something is still blocking the port, I double checked the firewall is also opened up at TCP 33333.

I saw in the above site, that I might have to configure manually a port via xinetd? Eventually I will need to run this application automatically in the background but right now all I want to achive is letting the TCP port receive anything at all.

7

xinetd doesn’t come into it at all.

Does netstat -atpn show a process listening on 33333?

Can you telnet to it? telnet localhost 33333, also telnet yourhost 33333, from another machine?

How exactly have you unblocked the port in the firewall? The terms in SUSE firewall are a bit confusing. IIRC If your machine is not a gateway, everything is external, there is no internal network.

You should disable the firewall to check that you can reach the port. If you can, then you have to work on your firewall config.

8

Yes netstat was showing the port was actively listening for TCP on 33333.

Last night I tried 2 other distros of Linux. I downloaded the 64-bit edition of OpenSuSE 11.1 and I downloaded Fedora 10. I have had success with both these distributions working when I configured the firewall to open port 33333.

The only thing I could think of is that something went foul on my OpenSuSE 11.1 32-bit installation or it broke when I joined the workstation to a Windows 2003 domain server.

I am going to try to install the 64-bit edition of OpenSuSE 11.1 on the trouble machine and verify.

Thanks for the community effort to answer my questions, I did learn a lot and now I know to use netstat to double check things.

9

You gave up too easily. You didn’t answer the questions. Did telnet localhost 33333 work? Did telnet myhost 33333 from another machine work? If the former worked but not the latter, then either the firewall is blocking it, or the app is not listening on all interfaces. What was the error message? If no response, that’s usually a firewall block. If connection refused that’s no application listening on that port. Did you turn the firewall off? You can also watch for packets on that port with wireshark.

Reinstalling is simply too blunt a response as troubleshooting.