On Thu, Mar 3, 2022 at 5:01 PM Rob Marshall <rob.marshall17(a)gmail.com&gt; wrote: Sounds like a race between firewalld and your network management program. If firewalld is not fully ready when interfaces are configured, they are not added to firewalld. Just a guess. Check startup order and dependencies. What network management are you using?

On 04.03.2022 00:44, Rob Marshall wrote: You could start with answering my question about network management you are using. Logs for the boot when interfaces were assigned to the wrong zone would be interesting. If your distribution is using systemd and you have configured persistent journal, you can use "journalctl -b NN" to indicate logs from the specific boot. Or simply "journalctl -b" for the current boot when this problem happens. Services definition for systemd and network startup service would be helpful too. systemctl cat firewalld.service systemctl cat <your-network-startup>.service

Hi, In checking the /var/log/firewalld I see a bunch of fails to iptables. Most of those are for docker, which isn't running on the system but the interface is there. There are a couple of other fails about bad rules for: /usr/sbin/iptables -w10 -t nat -D PREROUTING /usr/sbin/iptables -w10 -t nat -D OUTPUT something about "does a matching rule exist in that chain?" I checked both /etc/firewalld and /usr/lib/firewalld zones and the interfaces that it tries to add to zone 'public' are not in the public.xml in either place. How do I figure out where that is being defined? How would I tell if I'm using NetworkManager? Thanks, Rob On Fri, Mar 4, 2022 at 10:16 AM Eric Garver <egarver(a)redhat.com&gt; wrote:

Hi, Found out that the problem was the ZONE setting in the ifcfg-xxx files. Thanks for the help, Rob > On Mar 10, 2022, at 9:16 AM, Eric Garver <egarver(a)redhat.com&gt; wrote: > > On Thu, Mar 10, 2022 at 07:32:33AM -0500, Rob Marshall wrote: >> Hi, >> >> In checking the /var/log/firewalld I see a bunch of fails to iptables. Most >> of those are for docker, which isn't running on the system but the >> interface is there. There are a couple of other fails about bad rules for: >> >> /usr/sbin/iptables -w10 -t nat -D PREROUTING >> /usr/sbin/iptables -w10 -t nat -D OUTPUT >> >> something about "does a matching rule exist in that chain?" > > The above could all be related to docker. Perhaps these are stale logs. > I suggest truncating the log file and reproducing. > > # truncate -s 0 /var/log/firewalld > >> I checked both /etc/firewalld and /usr/lib/firewalld zones and the >> interfaces that it tries to add to zone 'public' are not in the public.xml >> in either place. How do I figure out where that is being defined? > > If interfaces are not assigned in the XML, then the assignments are > coming from something else, likely NetworkManager. > >> How would I tell if I'm using NetworkManager? > > How did you configure your interfaces? > > You can see if it's running: > > $ systemctl status NetworkManager > or > $ ps aux |grep NetworkManager > >> Thanks, >> >> Rob >> >>> On Fri, Mar 4, 2022 at 10:16 AM Eric Garver <egarver(a)redhat.com&gt; wrote: >>> >>> On Thu, Mar 03, 2022 at 02:00:19PM -0000, Rob Marshall wrote: >>>> Hi, >>>> >>>> I have an issue where, after a system reboot (Oracle Linux 7), >>>> communications to the node are not working correctly. If i stop and >>>> start (often a restart doesn't work) the firewalld service the network >>>> will work correctly. While things were broken I did a: 'firewall-cmd >>>> --list-all' and noticed that two of the interfaces were missing. Where >>>> can I look to determine what may be going wrong when firewalld starts >>>> after a reboot? >>> >>> You can check /var/log/firewalld for errors. That will give clues about >>> what's going on. >>> >>> Are you using NetworkManager? >>> >>> >