-1

Today I'm facing a strange problem. Some days ago I configured Iptables. I opened port 80,1000 and some others port. Today I need to open port 25 for mail system. I have added the rule in configuration file of iptables, but for some reason the port stay closed. I also tried to restart the system, but still port 25 remains closed. I also tried to disable iptables... and port 25 remains closed. I have no idea of what's happening...

I'm on Centos 7

EDIT: Of course, the port I opened some days ago are still opened

EDIT 2: Here's the result of the command iptables -L -n -v

    Chain INPUT (policy DROP 1173 packets, 75761 bytes)
 pkts bytes target     prot opt in     out     source               destination         
19620 3555K f2b-default  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           
19620 3555K f2b-default  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           
19620 3555K f2b-default  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           
19633 3555K f2b-default  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           
19633 3555K f2b-default  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           
19633 3555K f2b-default  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           
19633 3555K f2b-default  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           
19633 3555K f2b-default  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           
19633 3555K f2b-default  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           
19633 3555K f2b-default  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           
19633 3555K f2b-default  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           
15679 3181K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
 2849  353K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:20
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:21
   61  3524 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:25
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:50492
  140  7600 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
    2   104 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:110
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:995
    2   104 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:143
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:993
  183  9889 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:10000
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp spts:1024:65535 dpts:1024:65535 state ESTABLISHED
18543  597K ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 35337 packets, 4328K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1824  797K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp spts:1024:65535 dpts:1024:65535 state RELATED,ESTABLISHED

Chain f2b-default (11 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REJECT     all  --  *      *       111.200.39.31        0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      *       51.254.203.77        0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      *       223.100.157.212      0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      *       203.162.15.233       0.0.0.0/0            reject-with icmp-port-unreachable
 216K   39M RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0          
5
  • 1
    Post the output of 'iptables -L -n' Nov 8, 2015 at 2:48
  • Actually, post the output of iptables -L -n -v - @ArulSelvan, -v includes vital information like restrictions on interface, without which rules cannot be meaningfully examined.
    – MadHatter
    Nov 8, 2015 at 10:09
  • @MadHatter I am not the OP. I am responding to your -v comment above. I allow port 80,443 from anywhere to my host. Here is the output of iptables -L -n |egrep '80|443' where you can see the rule. I agree adding -v is good but not necessary in this case. # iptables -L -n |egrep '80|443' ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 Nov 8, 2015 at 12:29
  • @ArulSelvan I apologise for my confusion, but you are wrong about not needing -v. Consider the rule iptables -I INPUT -i tun+ -p tcp --dport 80 -j ACCEPT. Without -v, this will look identical to your blanket permit on inbound HTTP traffic; but it won't work like that in practice (it permits only inbound HTTP traffic from logical interfaces normally associated with established routed OpenVPN connections). When analysing possible rule failures, -v is always needed.
    – MadHatter
    Nov 8, 2015 at 12:59
  • I edited the first post adding the output of iptables -L -n -v
    – ababba
    Nov 8, 2015 at 16:38

2 Answers 2

2

The evidence is strong that your rule is taking effect; see the non-zero packet counts on the rule:

 61  3524 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:25

So if you find you still can't connect, it would be useful to see the evidence. It'd also be worth checking that your MTA is listening on the external address. Could you add into your question the output of netstat -apn|grep -w 25 (needs to run as root)?

If it looks like

tcp        0      0 :::25                       :::*                        LISTEN      1813/sendmail

then I'm wrong, and all is well on that front. But if it looks like

tcp        0      0 127.0.0.1:25                0.0.0.0:*                   LISTEN      1814/sendmail    

then your MTA is configured to listen only on the loopback address (127.0.0.1:25), and you need to fix that.

0
0

Just a little question - is there anything what is listening on port 25? Is your mailserver running? Port is closed if firewall block it OR when nothing is running on that port.

You must log in to answer this question.

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