Today my CentOS 7.5 system upgraded itself to 7.6.1810. And most of the zones in firewalld 0.5.3-5 disappeared. I now have only a "public" zone in the iptables chains, meaning no rules exist for trusted, which for example breaks all outbound connections. Which is kind of inconvenient for a firewall device.

Checking my 4 CentOS 7 systems, I was lucky. The first to upgrade was my local, and by breaking my Internet connectivity entirely, I had time to turn off the automated updates on two of the other 3 (one was off) before they upgraded. All the three 7.5 systems are still running 0.4.4.4, although two are release 14.el7, one is strangely 15.el7_5.

The broken system has not altered the firewalld config files under /etc/firewalld. I am aware of the ipset changes, which may affect if/how fail2ban works, but this is not my current concern. There is no sign of this issue in upstream known issues, or errata. To be clear, my un-updated systems have iptables chains in the filter table with "trusted" in the name, 24 times. such as IN_trusted_allow. My updated system has 0 - none. The zones themselves still exist, my internal interface is still in the "trusted" zone, but there are no chains for "trusted", so no firewall rules, all "trusted" traffic falls through to log and drop defaults.

Any assistance would be appreciated. For the first time I can recall, I have no idea how to troubleshoot this. Since it is a rebase, not just an upgrade, I can't even downgrade to 0.4.4.4, as it is no longer visible to yum. (Yes, I intend to find my way around that, although with unknown possible repurcussions).

I have confirmed that downgrading three packages associated with firewalld 0.4.4.4-14.el7 restores normal functionality, although I'm not familiar enough with firewalld internals to have any idea what within firewalld might be causing this issue.

And one of my other systems was in the process of upgrading, as I logged in to check (using rpm, alas) and disable yum-cron. So it will be the next to face a downgrade. Although, as a VM on public hosting, it's zones are unlikely to be significantly impacted.

Summary:
* I have not "lost zones"
* I don't have default zone in use
* 0.4.4.4-14 was released with CentOS-7.5
* 0.4.4.4-15 was released last September (for 7.5)
* 0.5.3-5 was released with CentOS-7.6

You must have something additional that affects your setups.

Thank's for the heads-up though; it is good to be aware of potential issues.

We hit this issue, or something similar. In CentOS 7.5 the setting of the zone for an interface is broken - see https://bugzilla.redhat.com/show_bug.cgi?id=1588456 - but CentOS 7.6 includes a workaround (ifup-post uses dbus-send --print-reply). So in 7.5, the interface zone is never set, and `firewall-cmd --get-zone-of-interface=eth0` returns "no zone", but in 7.6 the zone will be correctly set to whatever is configured in /etc/firewalld/firewalld.conf. The result is that configs that are working in 7.5 will break in 7.6. (In our case, firewalld.conf had "DefaultZone=drop" so the interface was now dropping all traffic, which did not happen in 7.5.)