Iptables Troubleshooting: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
(Created page with "=Internal= * iptables <font color=red>This is because firewalld was running</font> !!!ping and ssh succeed but telnet fails Occurred while setting up an OpenShift DNS...")
 
No edit summary
Line 3: Line 3:
* [[iptables]]
* [[iptables]]


<font color=red>This is because firewalld was running</font>
=ping and ssh succeed but telnet fails=


!!!ping and ssh succeed but telnet fails
It seemed that iptables service was down, <tt>systemctl status iptables</tt> returned "inactive (dead)", but actually the iptable rules were managed by [[firewalld]].


 
The problem went away after <tt>iptables -F</tt>, and was resolved for good by disabling and removing firewalld.
Occurred while setting up an OpenShift DNS server on 172.20.2.10.
 
The dedicated host was clearly listening on port 53 on all interfaces/protocols, but I got:
 
{{{
[root@rhel-test ~]# telnet 172.20.2.10 53
Trying 172.20.2.10...
telnet: connect to address 172.20.2.10: No route to host
}}}
 
from a different machine.
 
Yet, ping and ssh was successful to 172.20.2.10.
 
{{iptables}} seemed down:
 
{{{
[root@ns ~]# systemctl status iptables
iptables.service
  Loaded: not-found (Reason: No such file or directory)
  Active: inactive (dead)
}}}
 
but {{iptables -L -n}} showed some activity.
 
The server started to answer DNS queries after I ran:
 
{{{
iptables -F
}}}
 
After that, I got:
 
{{{
[root@ns ~]#  /sbin/iptables -L -n
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       
 
Chain FORWARD_IN_ZONES (0 references)
target    prot opt source              destination       
 
Chain FORWARD_IN_ZONES_SOURCE (0 references)
target    prot opt source              destination       
 
Chain FORWARD_OUT_ZONES (0 references)
target    prot opt source              destination       
 
Chain FORWARD_OUT_ZONES_SOURCE (0 references)
target    prot opt source              destination       
 
Chain FORWARD_direct (0 references)
target    prot opt source              destination       
 
Chain FWDI_public (0 references)
target    prot opt source              destination       
 
Chain FWDI_public_allow (0 references)
target    prot opt source              destination       
 
Chain FWDI_public_deny (0 references)
target    prot opt source              destination       
 
Chain FWDI_public_log (0 references)
target    prot opt source              destination       
 
Chain FWDO_public (0 references)
target    prot opt source              destination       
 
Chain FWDO_public_allow (0 references)
target    prot opt source              destination       
 
Chain FWDO_public_deny (0 references)
target    prot opt source              destination       
 
Chain FWDO_public_log (0 references)
target    prot opt source              destination       
 
Chain INPUT_ZONES (0 references)
target    prot opt source              destination       
 
Chain INPUT_ZONES_SOURCE (0 references)
target    prot opt source              destination       
 
Chain INPUT_direct (0 references)
target    prot opt source              destination       
 
Chain IN_public (0 references)
target    prot opt source              destination       
 
Chain IN_public_allow (0 references)
target    prot opt source              destination       
 
Chain IN_public_deny (0 references)
target    prot opt source              destination       
 
Chain IN_public_log (0 references)
target    prot opt source              destination       
 
Chain OUTPUT_direct (0 references)
target    prot opt source              destination       
 
}}}

Revision as of 09:09, 7 January 2016

Internal

ping and ssh succeed but telnet fails

It seemed that iptables service was down, systemctl status iptables returned "inactive (dead)", but actually the iptable rules were managed by firewalld.

The problem went away after iptables -F, and was resolved for good by disabling and removing firewalld.