2

I have a virtualized CentOS machine with a software that is listening on port 8080. I have turned off SELinux and flushed all iptables (so now there are no rules set). I have checked with netstat -nap | grep 8080 that the port is really open and it is. The IP adress is 192.168.1.3.

From my other machine, I would like to connect to that port with a program but it fails. When running nmap -p 8080 192.168.1.3 it says the port is closed!

When I check with Wireshark I can see that the connecting computer is sending the SYN packet but the responding computer (with IP 192.168.1.3) responds with a SYN/RESET and interrupts the connection and do not respond with a SYN/ACK and thereby continues the transmitting. The sequence number is correct, the sending computer sends 0 and the receiving one receives 1.

The strange thing is that other ports can be detected as open by Nmap from the client machine, but not 8080.

What can be wrong?

EDIT:

Ok, i don´t know what to believe on now. This is what I have discovered:
The porgram that is listening on 8080 on the "server machine" (let´s call it so) is a custom-made webservice built in Java (using third party libraries as EclipseLink etc). When doing nmap localhost on the "server machine", it can find the port open. When doing nmap 192.168.1.3 from the "client machine" it finds the port closed (as described above).
And the new discover: i just made a simple java app that just uses the ServerSocket class to listen on 8080 and THEN the port is discoverable from the "client machine". So, is it something with the webservice app? Why is the port discoverable from the "server machine" (when scanning itself, localhost) but not from the "client machine" when running the webservice? And why is port 8080 discoverable from BOTH machines when running the simple java app that listens on 8080?

netstat -ntpl
tcp    0    0 ::ffff:127.0.0.1:8080    :::*    LISTEN 3481/java



EDIT 2:
Stupid me! Now I see, ::ffff:127.0.0.1:8080 means that the program is only reachable from localhost! :-D
Where do I change so it listens from all?

7
  • Is the "other machine" you're trying to connect from the host machine, another virtual machine, a different real machine on the same network, or a virtual machine on a different host?
    – regularfry
    Feb 21, 2012 at 15:10
  • The "other machine" (client machine that tries to connect to port 8080 on 192.168.1.3) is another virtual machine. They are both in the same network.
    – Rox
    Feb 22, 2012 at 7:03
  • On machine B, telnet localhost 8080 and telnet machineb 8080 and post the results. Check the logs and configuration for your daemon listening on that port. Some applications listen on localhost only by default. Show the netstat -ntpl output.
    – dmourati
    Feb 22, 2012 at 7:15
  • you are you doing the scan from outside the network? Feb 22, 2012 at 7:44
  • @ElzoValugi: No, the network is local so I made the scan from inside the network. I made en edit to the post above. Really strange stuff =/
    – Rox
    Feb 22, 2012 at 8:38

2 Answers 2

0

May be 8080 port is binded somewhere else?

On a host machine?

Anyway, show you network config, virual machines in a bridge?

2
  • That was correct, 8080 was binded to localhost. Is it possible to bind it to everyone in EclipeLink?
    – Rox
    Feb 22, 2012 at 9:01
  • The solution is to se the binding address to 0.0.0.0
    – Rox
    Feb 22, 2012 at 9:27
0

If it's an old version of centos it could be a problem with "/etc/hosts.{allow,deny}", but if it's got iptables it's probably not using those. Check if those files exist.

2
  • hosts.allow and hosts.deny can still exist and be used on recent linux releases. I doubt tcpwrappers will ever die.
    – phemmer
    Feb 22, 2012 at 3:11
  • Yes, I have those files but all the lines in them are commented out in both of them. I tried to set "ALL: ALL" in /etc/hosts.allow and then rebooted the system but it didn´t help. What else can I try?
    – Rox
    Feb 22, 2012 at 7:05

You must log in to answer this question.

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