Have a problem
On some TCP ports Centos refuse all packets with icmp-host-prohibited, but iptables is empty
Unable to connect to remote host: No route to host when trying to connect to specific ports
Re: Unable to connect to remote host: No route to host when trying to connect to specific ports
There is no netfilter in the CentOS 8's kernel. Kernel filters with nftables now.
The low-level tool is 'nft'. The 'iptables' command is a (not 100%) wrapper-translator for nft.
The default front-end is still firewalld. It does use nft now, like it did use iptables before.
You can:
A. Learn the firewalld
B. Disable the firewalld and learn nft
C. Disable the firewalld and use iptables.service that does not use nftables optimally.
The low-level tool is 'nft'. The 'iptables' command is a (not 100%) wrapper-translator for nft.
Code: Select all
sudo nft list ruleset
You can:
A. Learn the firewalld
B. Disable the firewalld and learn nft
C. Disable the firewalld and use iptables.service that does not use nftables optimally.
Re: Unable to connect to remote host: No route to host when trying to connect to specific ports
There may be no netfilter but the iptables command(s) should still work and list rules. It translates them from nftables.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Re: Unable to connect to remote host: No route to host when trying to connect to specific ports
Alas, the iptables tool lists (at most) a subset of rules from nftables. I can confirm that the shown subset is empty on default install despite the nftables actually containing the sensible ruleset injected by firewalld.
I presume that the ability of iptables to enumerate what is in the kernel is limited. (netfilter had strict structure, nftables is "free for all".)
The main focus is probably in reading existing iptables-rules (from file) and converting them into nft equivalents (into kernel).
I presume that the ability of iptables to enumerate what is in the kernel is limited. (netfilter had strict structure, nftables is "free for all".)
The main focus is probably in reading existing iptables-rules (from file) and converting them into nft equivalents (into kernel).
Re: Unable to connect to remote host: No route to host when trying to connect to specific ports
Odd. It works for me with the default ruleset.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Re: Unable to connect to remote host: No route to host when trying to connect to specific ports
Interesting.
This is from system, where I have not touched the firewall in any way (yet). Base install CentOS 8 (plain @^virtualization-host-environment; had iptables-1.8.2-9.el8_0.1), now updated to CR (iptables-1.8.2-16.el8):
The chain filter_IN_public_allow is in table inet firewalld. There are many tables:
Only the "firewalld"-tables contain any rules.
The chains in other tables are empty and match (by name and type) the builtin chains that netfilter had.
If you see rules with iptables, then where did our installs differentiate?
This is from system, where I have not touched the firewall in any way (yet). Base install CentOS 8 (plain @^virtualization-host-environment; had iptables-1.8.2-9.el8_0.1), now updated to CR (iptables-1.8.2-16.el8):
Code: Select all
# sudo firewall-cmd --get-active-zones
public
interfaces: eno1np0
# sudo firewall-cmd --info-zone=public
public (active)
target: default
icmp-block-inversion: no
interfaces: eno1np0
sources:
services: cockpit dhcpv6-client ssh
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
# sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
# sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P POSTROUTING ACCEPT
-P OUTPUT ACCEPT
# sudo iptables -t mangle -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
# sudo nft list ruleset | grep -B 1 -A 3 ssh
chain filter_IN_public_allow {
tcp dport ssh ct state new,untracked accept
ip6 daddr fe80::/64 udp dport dhcpv6-client ct state new,untracked accept
tcp dport 9090 ct state new,untracked accept
}
Code: Select all
# sudo nft list tables
table ip filter
table ip6 filter
table bridge filter
table ip security
table ip raw
table ip mangle
table ip nat
table ip6 security
table ip6 raw
table ip6 mangle
table ip6 nat
table bridge nat
table inet firewalld
table ip firewalld
table ip6 firewalld
The chains in other tables are empty and match (by name and type) the builtin chains that netfilter had.
If you see rules with iptables, then where did our installs differentiate?