Reoccuring Problem no access to internet

So I have been having a problem since Saturday. I originally thought that I was being attacked, but it seems that it is due to updates.

I have been able to reinstall and get the system going, but after a few minutes or hours, the system breaks.

Sometimes SSH fails and then fail2ban fails. Sometimes I just am no longer able to load a website.

I am able to ping through the firewall and DNS resolves the ip address but no packets are returned.

I have reinstalled several times this week, updates seem to break SSH. Not updating leads to just simply loosing the ability of anything inside of the firewall connecting to the internet.

I tried testing, but it immediately stopped traffic from the inside.

Not sure what I can look for or do.

Could this be related? Cannot access/log in to FreedomBox

So I have been struggling here and not getting it to work.

8:19 AM Failed to start firewalld.service - firewalld - dynamic firewall daemon.

8:19 AM firewalld.service: Failed with result ‘exit-code’.

8:19 AM firewalld.service: Main process exited, code=exited, status=1/FAILURE

8:19 AM Starting firewalld.service - firewalld - dynamic firewall daemon…

I have reinstalled several times. If I update the system, then this starts happening and goes on for a while, then I have no internet access from inside.
If I disable firewall, then I have access.
My computer is acting as a router with 2 network cards. I have seen some talk of microcode in the kernal being an issue.
Any suggestions?

Several of us have had problems with firewalld. Apparently, the configuration file for the service has a line that sets the firewall zone to “public” and should be “external”.

SSH into your box and manually edit /etc/firewalld/firewalld.conf. Change the line:

then reload the firewalld service.

See: Debian 12 (Bookworm) release and upgrading - #7 by Avron

1 Like

Thanks, but it was already set to external

Here is my etc/firewalld/firewalld.conf

firewalld config file

default zone

The default zone used if an empty zone string is used.

Default: public


Clean up on exit

If set to no or false the firewall configuration will not get cleaned up

on exit or stop of firewalld

Default: yes



If set to enabled, firewall changes with the D-Bus interface will be limited

to applications that are listed in the lockdown whitelist.

The lockdown whitelist file is lockdown-whitelist.xml

Default: no



Performs a reverse path filter test on a packet for IPv6. If a reply to the

packet would be sent via the same interface that the packet arrived on, the

packet will match and be accepted, otherwise dropped.

The rp_filter for IPv4 is controlled using sysctl.

Default: yes



Do not use combined -restore calls, but individual calls. This increases the

time that is needed to apply changes and to start the daemon, but is good for


Default: no



Add logging rules right before reject and drop rules in the INPUT, FORWARD

and OUTPUT chains for the default rules and also final reject and drop rules

in zones. Possible values are: all, unicast, broadcast, multicast and off.

Default: off



Selects the firewall backend implementation.

Choices are:

- nftables (default)

- iptables (iptables, ip6tables, ebtables and ipset)



Flush all runtime rules on a reload. In previous releases some runtime

configuration was retained during a reload, namely; interface to zone

assignment, and direct rules. This was confusing to users. To get the old

behavior set this to “no”.

Default: yes



As per RFC 3964, filter IPv6 traffic with 6to4 destination addresses that

correspond to IPv4 addresses that should not be routed over the public


Defaults to “yes”.



Older versions of firewalld had undocumented behavior known as "zone

drifting". This allowed packets to ingress multiple zones - this is a

violation of zone based firewalls. However, some users rely on this behavior

to have a “catch-all” zone, e.g. the default zone. You can enable this if you

desire such behavior. It’s disabled by default for security reasons.

Note: If “yes” packets will only drift from source based zones to interface

based zones (including the default zone). Packets never drift from interface

based zones to other interfaces based zones (including the default zone).

Possible values; “yes”, “no”. Defaults to “no”.


I am not sure, but it might be case sensitive. Have you tried the following?


Great idea. Thanks.

It did not fix it, but I’m really thinking that the problem is here.

Don’t want to state the obvious, but just to cover all bases, did you restart the firewalld service after saving your changes? If you haven’t, you can do it with this command: sudo systemctl restart firewalld . Hope that helps!

Tried that. It immediately shuts down access to the internet.
I really want it to be something simple that I am overlooking.

So I have tried to change several options, but as soon as I start firewalld, internet access stops.

Thanks for trying to help

Did you give control of your network interfaces to NetworkManager by commenting the entries in /etc/network/interfaces?

Could this be related to a power save timer, maybe on a single network interface? (Is this a laptop with a GUI installed? Related)

Do you have another DHCP server on your network giving a lease to your FreedomBox?

I was able to get it working, well it is working now, and we will see if it works for more than a few days.

I found reference to a problem on RedHat at this forum

and did this,

Hubert Kario 2022-04-30 09:10:46 UTC

Actually, just setting forward on the internal zone is not sufficient, there’s also a need to create a policy that allows the forwarding between zones:

// create new policy
firewall-cmd --permanent --new-policy int_to_ext_fwd
firewall-cmd --permanent --policy int_to_ext_fwd --add-ingress-zone internal
firewall-cmd --permanent --policy int_to_ext_fwd --add-egress-zone external
firewall-cmd --permanent --policy int_to_ext_fwd --set-priority 100
firewall-cmd --permanent --policy int_to_ext_fwd --set-target ACCEPT

// Enable masquerade on external (this should already be the case if the setup worked on F34); ‘forward’ does not need to be set
firewall-cmd --permanent --zone=external --add-masquerade

// Enable forward on internal (this is a new setting)
firewall-cmd --permanent --zone=internal --add-forward

// restart firewalld
systemctl restart firewalld.service

Then I was able to see that it was already here on the forum at

So I don’t know what I did, well I almost understand, but it made it so I can access the internet with the firewall enabled.

I really think that there is something else going on, but I will take a win.