I have two VMs, both with firewalld installed. One on machine It this in the
IN_public chain:
Chain IN_public (2 references)
pkts bytes target prot opt in out source destination
81 3423 IN_public_log all -- * * 0.0.0.0/0
0.0.0.0/0
81 3423 IN_public_deny all -- * * 0.0.0.0/0
0.0.0.0/0
81 3423 IN_public_allow all -- * * 0.0.0.0/0
0.0.0.0/0
79 3335 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0
reject-with icmp-host-prohibited
On the other I see:
Chain IN_public (2 references)
pkts bytes target prot opt in out source destination
101 4232 IN_public_log all -- * * 0.0.0.0/0
0.0.0.0/0
101 4232 IN_public_deny all -- * * 0.0.0.0/0
0.0.0.0/0
101 4232 IN_public_allow all -- * * 0.0.0.0/0
0.0.0.0/0
1 84 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
As might be expected, pinging the first VM fails. That is the ping is rejected
with:
[emmett at ws1 ~]$ ping 96.92.106.4
PING 96.92.106.4 (96.92.106.4) 56(84) bytes of data.>From 96.92.106.4 icmp_seq=1 Destination Host Prohibited
>From 96.92.106.4 icmp_seq=2 Destination Host Prohibited
And pinging the second works as expected.
I've searche the firewalld configuration files in /usr/lib/firewalld and
/etc/firewalld and can find no reference to any icmp rule. The two machines
were cloned originally from the same VM. Why are they different?
How can I remove the reject-with icmp rule using firewalld. I can remove it
using "iptables -D [IN_public | FWDO_public | FWDI_public ] 4" and I
can then ping that machine. But of course the rule is returned whenever
firewalld is restarted.
Emmett
On Tue, 2017-12-19 at 15:05 -0800, Emmett Culley wrote:> I have two VMs, both with firewalld installed. One on machine It > this in the IN_public chain: > > Chain IN_public (2 references) > pkts bytes target prot opt > in out source destination > 81 3423 IN_public_log all > -- * * 0.0.0.0/0 0.0.0.0/0 > 81 3423 IN_public_deny all > -- * * 0.0.0.0/0 0.0.0.0/0 > 81 3423 IN_public_allow all > -- * * 0.0.0.0/0 0.0.0.0/0 > 79 3335 REJECT all > -- * * 0.0.0.0/0 0.0.0.0/0 reject- > with icmp-host-prohibited > > On the other I see: > > Chain IN_public (2 references) > pkts bytes target prot opt > in out source destination > 101 4232 IN_public_log all > -- * * 0.0.0.0/0 0.0.0.0/0 > 101 4232 IN_public_deny all > -- * * 0.0.0.0/0 0.0.0.0/0 > 101 4232 IN_public_allow all > -- * * 0.0.0.0/0 0.0.0.0/0 > 1 84 ACCEPT icmp > -- * * 0.0.0.0/0 0.0.0.0/0 > > As might be expected, pinging the first VM fails. That is the ping > is rejected with: > > [emmett at ws1 ~]$ ping 96.92.106.4 > PING 96.92.106.4 (96.92.106.4) 56(84) bytes of data. > From 96.92.106.4 icmp_seq=1 Destination Host Prohibited > From 96.92.106.4 icmp_seq=2 Destination Host Prohibited > > And pinging the second works as expected. > > I've searche the firewalld configuration files in /usr/lib/firewalld > and /etc/firewalld and can find no reference to any icmp rule. The > two machines were cloned originally from the same VM. Why are they > different? > > How can I remove the reject-with icmp rule using firewalld. I can > remove it using "iptables -D [IN_public | FWDO_public | FWDI_public ] > 4" and I can then ping that machine. But of course the rule is > returned whenever firewalld is restarted. > > Emmett > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >What is the output off: firewall-cmd --list-all on the VMs?
On 12/19/2017 03:37 PM, Louis Lagendijk wrote:> On Tue, 2017-12-19 at 15:05 -0800, Emmett Culley wrote: >> I have two VMs, both with firewalld installed. One on machine It >> this in the IN_public chain: >> >> Chain IN_public (2 references) >> pkts bytes target prot opt >> in out source destination >> 81 3423 IN_public_log all >> -- * * 0.0.0.0/0 0.0.0.0/0 >> 81 3423 IN_public_deny all >> -- * * 0.0.0.0/0 0.0.0.0/0 >> 81 3423 IN_public_allow all >> -- * * 0.0.0.0/0 0.0.0.0/0 >> 79 3335 REJECT all >> -- * * 0.0.0.0/0 0.0.0.0/0 reject- >> with icmp-host-prohibited >> >> On the other I see: >> >> Chain IN_public (2 references) >> pkts bytes target prot opt >> in out source destination >> 101 4232 IN_public_log all >> -- * * 0.0.0.0/0 0.0.0.0/0 >> 101 4232 IN_public_deny all >> -- * * 0.0.0.0/0 0.0.0.0/0 >> 101 4232 IN_public_allow all >> -- * * 0.0.0.0/0 0.0.0.0/0 >> 1 84 ACCEPT icmp >> -- * * 0.0.0.0/0 0.0.0.0/0 >> >> As might be expected, pinging the first VM fails. That is the ping >> is rejected with: >> >> [emmett at ws1 ~]$ ping 96.92.106.4 >> PING 96.92.106.4 (96.92.106.4) 56(84) bytes of data. >> From 96.92.106.4 icmp_seq=1 Destination Host Prohibited >> From 96.92.106.4 icmp_seq=2 Destination Host Prohibited >> >> And pinging the second works as expected. >> >> I've searche the firewalld configuration files in /usr/lib/firewalld >> and /etc/firewalld and can find no reference to any icmp rule. The >> two machines were cloned originally from the same VM. Why are they >> different? >> >> How can I remove the reject-with icmp rule using firewalld. I can >> remove it using "iptables -D [IN_public | FWDO_public | FWDI_public ] >> 4" and I can then ping that machine. But of course the rule is >> returned whenever firewalld is restarted. >> >> Emmett >> _______________________________________________ >> CentOS mailing list >> CentOS at centos.org >> https://lists.centos.org/mailman/listinfo/centos >> > What is the output off: > firewall-cmd --list-all > on the VMs? > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >That was the clue I needed. On the first machine: target: %%REJECT%% icmp-block-inversion: no interfaces: eth0 sources: services: ftp_passiv http ssh https ftps ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: And the second: target: default icmp-block-inversion: no interfaces: eth0 sources: services: ftp_passiv http ssh https ftps ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: Changing the target to "default" instead of "%%REJECT%%" by setting the zone policy to default in firewalld-config fixed it. NOt sure whay that would be, but I am happy with the result. Thanks!