Score:0

iptables - port 25 not getting traffic even though default policy is ACCEPT and all rules are flushed

br flag

I am having a problem that's driving me up the wall. I have a server, where after several attempts at various iptable rules, I have flushed iptable rules and set default policy to accept.

The output of $ sudo iptables -L:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

I do have postfix listening on the port as can be found on $ sudo netstat -tulnp:

tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      9639/master

When I run nmap from my local machine $ sudo nmap -p 25 <server-ip>:

PORT   STATE    SERVICE
25/tcp filtered smtp

When I run nmap from the server itself $ sudo nmap -p 25 localhost:

PORT   STATE SERVICE
25/tcp open  smtp

When I telnet to the server from my local machine, the connection timesout. But if I telnet on the server itself $ telnet localhost 25 then I see:

Connected to localhost.
Escape character is '^]'.
220 <server-domain> ESMTP Postfix

I'm really at my wits end. I found some other posts on this site and other stack-exchange ones about similar issues, but the problem there seemed to be that the service was not running and listening on port 25. But as you can see from the netstat command, the postfix process is listening to port 25 on this server.

Can anyone please give me pointers on what to try next?

Oh also tried $ sudo tcpdump -n port 25 while the connection attempt was made. But there were no packets captured. But tcpdump captured packets when I connected from the server itself $ telnet localhost 25.

Nikita Kipriyanov avatar
za flag
Traffic can be dropped not only in the filter table. Your `iptables -L` does not prove nothing is filtered, and there is also nftables in the Linux, which is controlled elsewhere. Please check `iptables-save` and `nft list ruleset`.
AnFi avatar
fi flag
Try tools like `tcptraceroute` to check if connection is blocked **before** your host.
arunkumar avatar
br flag
@NikitaKipriyanov `iptables-save` and `nft list ruleset` looks ok to me, in that I see port 25 being allowed in input. And I don't see anything else. Should I post the results in my question?
arunkumar avatar
br flag
@AnFi I tried `tcptraceroute <server-ip> 25` and got a couple of responses between my machine and my router, but after that it was all `* * *`. No responses for 30 hops
AnFi avatar
fi flag
It is quite likely that **outgoing** connections to port 25 are blocked by the ISP. Check if your postfix accepts connections at port 587 and try to telnet it from test host.
Score:0
us flag

Many ISPs don’t allow SMTP traffic. They block or drop all such traffic.

Contact your ISP or hosting provider to ask whether they allow port 25 traffic.

Nikita Kipriyanov avatar
za flag
While this could be true, reasonable is to block traffic only in outgoing direction: they don't allow *outgoing to tcp/25*, but don't do anything particular in incoming direction. There is no reason to block incoming, since it could do no harm. I'd rather suspect that blockage occurs on the *local* provider from which attempts to test were made.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.