Normally, firewalld only blocks incoming requests, meaning that if you have a web servers with a listening port of 443 you need to open 443 for incoming requests.
However, the issue is with forwarding as indicated by “filter_FWD_FedoraWorkstation_REJECT”. That should be allowed, but there might have been some change or perhaps regression. Your host system should have no problem connecting to remote port 443 which is the https port.
That is all I can say as I don’t know how winboat does networking.
It looks like you need some interfaces on that zone. You may find that you allow one zone to do its job, and it still will not work after that.
Keep a log of these changes so you can revert them later as needed, but I would leave all these changes enabled. Once you get it working you can start taking things away to determine what breaks it again. That way you will know but not be working against yourself.
You may have to run that check again systematically if the below changes do not work to see where breaks may still be located.
Again, “remove” can be still be substituted where add is in these commands to get to the reverted state.
Add the machine’s interface to FedoraWorkstation
(It may be this simple!) sudo firewall-cmd --zone=FedoraWorkstation --permanent --add-interface=wlp192s0
*Reload and try Winboat. If it does not work, please continue below.
Add the Winboat interface to FedoraWorkstation
(FYI - It is completely possible that this should be going to the “docker” zone and not the “FedoraWorkstation” zone. Keep that in mind.) sudo firewall-cmd --zone=FedoraWorkstation --permanent --add-interface=br-75bfbe7658f3
*Reload and try Winboat. If it does not work, please continue below.
Add the https service to FedoraWorkstation
(I do not think this will be required.) sudo firewall-cmd --zone=FedoraWorkstation --permanent --add-service=https
*Reload and try Winboat.
*If this does not do it, stop here and run that check again to see what else might be blocked. One zone may open up for you to find a different block somewhere else downstream in the dependencies.
Virtualization and containers make this a bit more convoluted since some of these things appear unsolicited from the machine’s perspective.
It could be something simple like the machine’s active zone is incorrectly set to “home” in NetworkManager, too. Mine is FedoraWorkstation, but it looks like 'home" is in use from the listed outputs from all zones.
I was also hoping that the docker zone would active when Winboat gets launched.
At this point it may be simpler to see the verbose outputs after the blocks (or what we assume to be the blocks) are removed, so we can continue systematically identifying blocks as things get opened up.
Splinter and others, have a look at this.
This is where I believe our main problem is:
Firewall config LHS…
You see docker assigned to default zone “FedoraWorkstation”
Then “br-c8478f2ec197” is assigned to “FedoraWorkstation” This is the virtual ethernet card that is used by Winboat/docker.
This virtual card has got all the dns/dhcp/ssh services assigned and a bunch more.
I am assuming its Docker that keeps changing the name of the vrtual ethernet card, never matching what is setup in the firewall.
I could be wrong. Lets see what everybody things.
Your home zone does not allow any of them in. My physical interface is FedoraWorkstation by default, but yours might be in home from a previous change you made.
I would also wonder why docker0 and the other bridge interface that changes is not in the docker zone, but I guess it should not matter for your case if the physical wlp192s0 is in the same zone as the others.
Edit: Also, those “Services” in the tab list you show do not mean they are enabled in the zone under the Zones tab. It is just showing you the ones available to use in each zone.
I didn’t make any changes to the firewall or docker etc.
At the time I took a snapshot of the settings at the time as you suggested and saved them to a text file to be able to revert it back to its default state. Firewall was never touched beforehand.
Then as we made changes and they had no effect, I reversed them, took another snapshot and compared them with the original to make sure that I hadn’t missed anything.
Right now, all settings are back to original.
sudo busctl --no-pager introspect org.fedoraproject.FirewallD1 \
/org/fedoraproject/FirewallD1/config org.fedoraproject.FirewallD1.config
Place your finger on the fingerprint reader
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
.addHelper method s(sssssa(ss)) o -
.addIPSet method s(ssssa{ss}as) o -
.addIcmpType method s(sssas) o -
.addPolicy method sa{sv} o -
.addService method s(sssa(ss)asa{ss}asa(ss)) o -
.addService2 method sa{sv} o -
.addZone method s(sssbsasa(ss)asba(ssss)asasasasa(ss)b) o -
.addZone2 method sa{sv} o -
.getHelperByName method s o -
.getHelperNames method - as -
.getIPSetByName method s o -
.getIPSetNames method - as -
.getIcmpTypeByName method s o -
.getIcmpTypeNames method - as -
.getPolicyByName method s o -
.getPolicyNames method - as -
.getServiceByName method s o -
.getServiceNames method - as -
.getZoneByName method s o -
.getZoneNames method - as -
.getZoneOfInterface method s s -
.getZoneOfSource method s s -
.listHelpers method - ao -
.listIPSets method - ao -
.listIcmpTypes method - ao -
.listPolicies method - ao -
.listServices method - ao -
.listZones method - ao -
.AllowZoneDrifting property s "no" emits-change writable
.AutomaticHelpers property s "no" emits-change writable
.CleanupModulesOnExit property s "no" emits-change writable
.CleanupOnExit property s "yes" emits-change writable
.DefaultZone property s "FedoraWorkstation" emits-change
.FirewallBackend property s "nftables" emits-change writable
.FlushAllOnReload property s "yes" emits-change writable
.IPv6_rpfilter property s "yes" emits-change writable
.IPv6_rpfilter2 property s "loose" emits-change writable
.IndividualCalls property s "no" emits-change writable
.Lockdown property s "no" emits-change writable
.LogDenied property s "all" emits-change writable
.MinimalMark property i 100 emits-change writable
.NftablesCounters property s "no" emits-change writable
.NftablesFlowtable property s "off" emits-change writable
.NftablesTableOwner property s "yes" emits-change writable
.RFC3964_IPv4 property s "yes" emits-change writable
.StrictForwardPorts property s "no" emits-change writable
.HelperAdded signal s - -
.IPSetAdded signal s - -
.IcmpTypeAdded signal s - -
.PolicyAdded signal s - -
.ServiceAdded signal s - -
.ZoneAdded signal s - -
This worked !!!
So Vladislav…apart from being the hero here in the end (and not diminishing the help from MSplinter) thank you all so much…can you give us a short explanation, which service is at fault.
If it is firewalld causing the issue, then I need to log a fault with Fedora. If its Docker…then I might have to update to their official latest version?, via adding the repo download docker.com, removing the current one and adding their latest.
sudo systemctl disable docker.service
sudo systemctl enable docker.socket
sudo systemctl restart docker.socket
docker network ls
firewall-cmd --get-active-zones
Place your finger on the fingerprint reader
Removed '/etc/systemd/system/multi-user.target.wants/docker.service'.
Disabling 'docker.service', but its triggering units are still active:
docker.socket
NETWORK ID NAME DRIVER SCOPE
59121a216536 bridge bridge local
70f09322e6ab host host local
de83b9b8e502 none null local
c8478f2ec197 winboat_default bridge local
docker
interfaces: br-c8478f2ec197 docker0
home
interfaces: wlp192s0
FedoraWorkstation (default)
Some quick update info.
The fix holds after shutting down Winboat and then restarting it. So for the time being the fix only has to be run after a reboot.
I have added the commands into my “Quick Command” table in Konsole.
Hopefully Vladislav can get back to us when he has some time and explain to us mere mortals which service is at fault, so I can log a fault with the appropriate side Winboat or Fedora.
It was definitely the root cause analysis for me and why I say that, haha! It always funny when things go back to “Did you try turning it off and back on again?”
@alinausssieland - he stated he was able to repro this problem and thinks it is a race condition. That can be identified when a particular sequence of events leads to an unexpected outcome like this. Sometimes it results in data loss, and that can be intentionally exploited in some cases. It probably needs a bug opened, but I am not sure if it is for firewalld or docker. Too much sorcery!
