port 25 is reported to be open but no service is listening

Question

OS is Ubuntu 12.04 LTS (server; without GUI). The machine is a virtual server running hundreds of miles away in a remote server farm.

I uninstalled postfix and all of it's components (courier, dovecot) and I even stopped sendmail and uninstalled it.

Now there seems to be no program listening on port 25:

netstat -lnptu | grep :25  

gives no entry (0 lines). I get the same result with

netstat -anp | grep :25  

and also 0 lines result with this command:

fuser -v 25/tcp  

From inside the server port 25 is unreachable for telnet:

> telnet localhost 25  
Trying ::1...  
Trying 127.0.0.1...  
telnet: Unable to connect to remote host: Connection refused

(When I try to connect to port 24 I get exactly the same answer)

Even if I replace 'localhost' by my machines IP-address I am unable to connect to port 25 from inside:

> telnet <IP-address of my server> 25
Trying <IP-address of my server>...  
telnet: Unable to connect to remote host: Connection refused  

But ...

... when I do a portscan with http://www.dnstools.ch/port-scanner.html port 25 is reported to be open.

When I try to connect to port 25 on my server with telnet from outside I get this:

> telnet <IP-address of my server> 25
Trying <address>...
Connected to <resolved name>.
Escape character is '^]'.
Connection closed by foreign host.  

So I get a connection, but it is closed immediately.

When I try to connect to a closed port I get this:

> telnet <IP-address of my server> 24
Trying <address>...
telnet: connect to address <address>: Connection refused
telnet: Unable to connect to remote host

I even did try to add some rules to iptables for port 25, but this had absolutely no effect. Port 25 still seems to be open when looking to it from outside, but no program is listening to it.

Question 1: How can this happen?
Question 2: How can I close port 25 under this circumstances?

Answer 1

You probably have a security device that is answering on behalf of the IP addresses in your network. The "pick up and hang up" behavior is typical. You may be able to confirm this behavior by observing IP TTL values for the port 25 response and comparing them to an actual open-port response from your machine (closed-port responses like port 24 are also likely coming from the security device, so a comparison would not be useful). You can use Nmap for this purpose like so:

sudo nmap -sS -p 25,80 target.example.com -oX - | grep reason_ttl

Assuming that port 80 is open on your target, and port 25 is giving odd responses, you ought to see something like this:

<host starttime="1398878935" endtime="1398878935"><status state="up" reason="reset" reason_ttl="52"/>
<ports><port protocol="tcp" portid="25"><state state="open" reason="syn-ack" reason_ttl="54"/><service name="smtp" method="table" conf="3"/></port>
<port protocol="tcp" portid="80"><state state="open" reason="syn-ack" reason_ttl="52"/><service name="http" method="table" conf="3"/></port>

Pardon the XML eyesore, but if you look at the state element's reason_ttl attribute, you can see that in one case the TTL of the response was lower than the other, indicating that the packet traveled farther into the network before eliciting a response. This is not a foolproof method, since the security device can lie about outbound TTLs, but it may help satisfy your curiosity.

In any case, you can be sure, based on the output of netstat and other tools, that the port is not really listening on your machine.