search for: input_zone

I just noticed that when rebooting a CentOS 7 server the firewall comes back up with both interfaces set to REJECT, instead of the eth1 interface set to ACCEPT as defined in 'permanent' firewalld configuration files. All servers are up to date. By "just noticed" I mean that I finally investigated why a newly rebooted VM failed to allow NFS connections. Prior to doing that.

...ce set to ACCEPT as defined in 'permanent' firewalld configuration files. > > Rather than paraphrasing, could you show the specific rules, chains, or policies you're talking about? A standard firewalld rule set has the INPUT policy set to ACCEPT, with a terminal REJECT rule. An INPUT_ZONES table will direct to an IN_public table, with log, deny, and accept rules. > > Typically, the only rule that references an interface is the one in INPUT_ZONES that "goto"s IN_public_allow. It is neither REJECT nor ACCEPT, so it's really hard to guess what you're seeing th...

...B: Bring up/down networking. Aug 19 11:23:43 master firewalld: 2015-08-19 11:23:43 ERROR: Failed to apply rules. A firewall reload might solve the issue if the firewall has been modified using ip*tables or ebtables. Aug 19 11:23:43 master firewalld: 2015-08-19 11:23:43 ERROR: '/sbin/iptables -D INPUT_ZONES -t filter -i eth0 -g IN_public' failed: iptables: No chain/target/match by that name. Aug 19 11:23:43 master firewalld: 2015-08-19 11:23:43 ERROR: COMMAND_FAILED: '/sbin/iptables -D INPUT_ZONES -t filter -i eth0 -g IN_public' failed: iptables: No chain/target/match by that name. Aug 19...

Hi I would like to add rules into the iptables of the Hosted Engine VM in Ovirt. the version is oVirt Engine Version: 4.1.1.8-1.el7.centos I have tried using the normal process for iptables (iptables-save etc), but it seems that the file /etc/sysconfig/iptables this is ignored in the Ovirt Engine VM. How can I add permanent rules into the Engine VM? Kind regards Andrew

...interface set to ACCEPT as defined in 'permanent' firewalld configuration files. Rather than paraphrasing, could you show the specific rules, chains, or policies you're talking about? A standard firewalld rule set has the INPUT policy set to ACCEPT, with a terminal REJECT rule. An INPUT_ZONES table will direct to an IN_public table, with log, deny, and accept rules. Typically, the only rule that references an interface is the one in INPUT_ZONES that "goto"s IN_public_allow. It is neither REJECT nor ACCEPT, so it's really hard to guess what you're seeing that you...

...prot opt in out source destination 799 156K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 22 1592 INPUT_direct all -- * * 0.0.0.0/0 0.0.0.0/0 22 1592 INPUT_ZONES_SOURCE all -- * * 0.0.0.0/0 0.0.0.0/0 22 1592 INPUT_ZONES all -- * * 0.0.0.0/0 0.0.0.0/0 2 224 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID 17 1140 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 rej...

Hello Julien, Am Tue, 15 Jan 2019 09:30:23 +0100 schrieb Julien dupont <marcelvierzon at gmail.com>: > In that case I see: > IP 172.16.0.3 > 192.168.1.1: ICMP echo request, id2135, seq1, length 64 > IP 172.16.0.3 > 192.168.1.1: ICMP echo request, id2135, seq2, length 64 > IP 172.16.0.3 > 192.168.1.1: ICMP echo request, id2135, seq3, length 64 > > Packet goes

Yesterday I noticed that I was not able to ping one of our development servers so I logged in via VNC and ran the Firewalld GUI. To my surprise, except for the interface definition for public and trusted zones, nothing seemed to be configured. That is, none of the services were checked off that we want open at the firewall. Also, this server is a gateway and masquerading and forwarding appears