I had Winboat working really well, but since the latest firewalld updates it has no internet connection.
It does get to the laptop /linux via the virtual ethernet connection, but that’s where it stops.
This could be some type of service related block in a firewalld zone.
Can you run this to check your firewall zones and their configurations?
firewall-cmd --list-all-zones
There should be a zone for it. I use virt-manager and had to open dhcp (to pull an IP from the dhcp scope) and dns (to resolve URLs in my VM to an IP / the IP pings worked fine though), for instance.
A bit more info…
Note, this was a working system.
From Winboat/Windows Desktop, I used cmd to ping the router..no go. In Windows, the Network connection showed to be UP.
Then I pinged the Latop itself and the pings returned..OK.
I stopped the Laptop firewall using: “sudo systemctl stop firewalld”
Then pinged the router…OK.
Then used the Window’s application that I need to access the Server on the Internet…OK
So definitly a Laptop firewall issue. By the way…I use Docker for Winboat.
Below is the info as requested…and thanks for having a look.
sudo firewall-cmd --list-all-zones
Place your finger on the fingerprint reader
FedoraServer
target: default
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces:
sources:
services: cockpit dhcpv6-client ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
FedoraWorkstation (default, active)
target: default
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces:
sources:
services: dhcpv6-client samba-client ssh
ports: 1025-65535/udp 1025-65535/tcp
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
P2P-WiFi-Display
target: ACCEPT
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces:
sources:
services: dhcp dns
ports: 7236/tcp
protocols: icmp ipv6-icmp
forward: no
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule priority="32767" reject
block
target: %%REJECT%%
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces:
sources:
services:
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
dmz
target: default
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces:
sources:
services: ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
docker
target: ACCEPT
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces:
sources:
services:
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
drop
target: DROP
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces:
sources:
services:
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
external
target: default
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces:
sources:
services: ssh
ports:
protocols:
forward: yes
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:
home (active)
target: default
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces: wlp192s0
sources:
services: dhcpv6-client kdeconnect mdns samba-client ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
internal
target: default
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces:
sources:
services: dhcpv6-client mdns samba-client ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
nm-shared
target: ACCEPT
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces:
sources:
services: dhcp dns ssh
ports:
protocols: icmp ipv6-icmp
forward: no
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
rule priority="32767" reject
public
target: default
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces:
sources:
services: dhcpv6-client mdns ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
trusted
target: ACCEPT
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces:
sources:
services:
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
work
target: default
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces:
sources:
services: dhcpv6-client mdns ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
These zones look mostly default and wide open. You should consider locking everything down and allowing only what you need for security purposes, and it is something most people do not think about because they think Fedora just has them covered. Fedora is awesome, but it can only be as awesome as end users allow it to be!
- Only allow what you need. (Most things can be closed off without issue, but some zones and items may be required for your daily machine use in order to function properly.)
- Only open new items you need as you determine you need them.
I have to assume that the docker zone is what you must add some services to based on the requirement for that with Winboat.
If you cannot ping the router, you likely need DHCP opened to accept an IP in your range:
sudo firewall-cmd --zone=docker --permanent --add-service=dhcp
sudo firewall-cmd --reload
Now try your Winboat stuff to determine if you need something more like DNS later.
If you need this:
If you need to ping URLs beyond the routing hardware etc., you will need DNS open to resolve those URLs into a usable IPs:
sudo firewall-cmd --zone=docker --permanent --add-service=dns
sudo firewall-cmd --reload
Now try whatever you need Winboat for again.
These can be a start, but let me know if you need more or if you experience more nuanced problems with Winboat. I do not know all of the ports and services etc. that you are using to meet your goals.
Edit: Oh yeah, always keep a log of your firewalld changes in a text file or something in case you need to go back to them to revert them. It helps know what things might be breaking your builds instead of guessing what you did a day or a year ago. This is especially useful if you go on a firewalld hardening adventure that I recommended at the beginning.
Lots of info, thanks Splinter 
I will have a play with your info a bit later, but will certainly come back with what didn’t work and what might have worked in the end. thanks.
One caveat. I have done some quick reading up on Fedora firewall and it appears I can make changes on the fly without making the change permanent. When I will try the different options, I will add a timer to it so that in case I break something, it will revert to its previous state.
Saving current settings to a text file…I will do this right now before doing anything else..thanks.
Sounds good! I hope the dhcp and/or dns services allow it to work.
- You can definitely take off the --permanent on those so they can be temporary until you reboot, but there is no harm in leaving --permanent on. You can always go back and run those with “remove” where “add” currently is, and that will make the revert instantly if you use that --reload after changes.
The hardening can be a long term thing you do as you learn firewalld and what your tools are using in their operations. That will not happen overnight!
For anyone that has a mostly vanilla install of Fedora and wants stuff hardened, I will leave my commands list here I use on Fedora 44 with virt-manager in use. If you use the machine as a regular desktop, these settings I list are usually 100% fine.
If you do not use virt-manager, you can just put a # in front of everything under the libvirt section. I have already done this on dhcp and dns services for libvirt
For awareness, this will be best used on mostly new Fedora installs. You may also run into firewalld blocks where you have to open something later that will be getting used by future intentions and integrations on your machine. So if you use these, you have been forewarned with considerations!
#Lockdown FedoraServer
sudo firewall-cmd --zone=FedoraServer --permanent --remove-service=cockpit
sudo firewall-cmd --zone=FedoraServer --permanent --remove-service=dhcpv6-client
sudo firewall-cmd --zone=FedoraServer --permanent --remove-service=ssh
sudo firewall-cmd --zone=FedoraServer --permanent --remove-forward
#Lockdown FedoraWorkstation
sudo firewall-cmd --zone=FedoraWorkstation --permanent --remove-service=dhcpv6-client
sudo firewall-cmd --zone=FedoraWorkstation --permanent --remove-service=samba-client
sudo firewall-cmd --zone=FedoraWorkstation --permanent --remove-service=ssh
sudo firewall-cmd --zone=FedoraWorkstation --permanent --remove-port=1025-65535/udp
sudo firewall-cmd --zone=FedoraWorkstation --permanent --remove-port=1025-65535/tcp
sudo firewall-cmd --zone=FedoraWorkstation --permanent --remove-forward
#Lockdown block
sudo firewall-cmd --zone=block --permanent --remove-forward
#Lockdown dmz
sudo firewall-cmd --zone=dmz --permanent --remove-service=ssh
sudo firewall-cmd --zone=dmz --permanent --remove-forward
#Lockdown drop
sudo firewall-cmd --zone=drop --permanent --remove-forward
#Lockdown external
sudo firewall-cmd --zone=external --permanent --remove-service=ssh
sudo firewall-cmd --zone=external --permanent --remove-forward
sudo firewall-cmd --zone=external --permanent --remove-masquerade
#Lockdown home
sudo firewall-cmd --zone=home --permanent --remove-service=dhcpv6-client
sudo firewall-cmd --zone=home --permanent --remove-service=mdns
sudo firewall-cmd --zone=home --permanent --remove-service=samba-client
sudo firewall-cmd --zone=home --permanent --remove-service=ssh
sudo firewall-cmd --zone=home --permanent --remove-forward
#Lockdown internal
sudo firewall-cmd --zone=internal --permanent --remove-service=dhcpv6-client
sudo firewall-cmd --zone=internal --permanent --remove-service=mdns
sudo firewall-cmd --zone=internal --permanent --remove-service=samba-client
sudo firewall-cmd --zone=internal --permanent --remove-service=ssh
sudo firewall-cmd --zone=internal --permanent --remove-forward
#Lockdown libvirt
#This allows the VM to obtain an IP for general connectivity.
# sudo firewall-cmd --zone=libvirt --permanent --remove-service=dhcp
sudo firewall-cmd --zone=libvirt --permanent --remove-service=dhcpv6
#This allows that connectivity to properly reach out to webpages. Without it, DNS resolution does not occur.
# sudo firewall-cmd --zone=libvirt --permanent --remove-service=dns
sudo firewall-cmd --zone=libvirt --permanent --remove-service=ssh
sudo firewall-cmd --zone=libvirt --permanent --remove-service=tftp
sudo firewall-cmd --zone=libvirt --permanent --remove-protocol=icmp
sudo firewall-cmd --zone=libvirt --permanent --remove-protocol=ipv6-icmp
sudo firewall-cmd --zone=libvirt --permanent --remove-forward
#Lockdown nm-shared
sudo firewall-cmd --zone=nm-shared --permanent --remove-service=dhcp
sudo firewall-cmd --zone=nm-shared --permanent --remove-service=dns
sudo firewall-cmd --zone=nm-shared --permanent --remove-service=ssh
sudo firewall-cmd --zone=nm-shared --permanent --remove-protocol=icmp
sudo firewall-cmd --zone=nm-shared --permanent --remove-protocol=ipv6-icmp
#Lockdown public
sudo firewall-cmd --zone=public --permanent --remove-service=dhcpv6-client
sudo firewall-cmd --zone=public --permanent --remove-service=mdns
sudo firewall-cmd --zone=public --permanent --remove-service=ssh
sudo firewall-cmd --zone=public --permanent --remove-forward
#Lockdown trusted
sudo firewall-cmd --zone=trusted --permanent --remove-forward
#Lockdown work
sudo firewall-cmd --zone=work --permanent --remove-service=dhcpv6-client
sudo firewall-cmd --zone=work --permanent --remove-service=mdns
sudo firewall-cmd --zone=work --permanent --remove-service=ssh
sudo firewall-cmd --zone=work --permanent --remove-forward
I am always open to constructive criticism. For anyone, if you are experienced in firewalld and see something wrong in my suggestions or configuration, please point it out and say something
It looks like you just could make “drop” or “block” the default zone and the zone for all interfaces.
The problem for the default firewall setup is that it makes no difference between connecting from another system on the local network or from the external internet. Thus it depends on the proper firewall configuration on your modem-router box to create a barrier to the internet. That is specially important with IPv6 where all IP addresses are world reachable.
I only have those items shut off that way to retain all of the zones Fedora comes with, or creates, to use them later. I agree that using drop or block would simplify that a ton though.
The local vs. external is another good point, especially with IPv6. I have IPv6 fully disabled locally via a .conf file because I have no reason to use that yet. Maybe local net connections in some edge cases would warrant it. IPS is in use on local network hardware for that initial protection. The firewalld stuff is mostly there for tunneling from the local machine because that may negate the network hardware’s IPS entirely.
Before digging more into the firewall, try winboat with the firewall turned off, to be sure it’s actually a firewall problem and not something else:
sudo systemctl stop firewalld.service
I already did. You must have missed it in the upper comments of mine.
Yes, stopping the firewall restored Internet connection from Winboat.
I currently use winboat too, however I turned the firewall off anyways when trying winboat for the first time.
If this is reproducible, I’m sure it will be resolved soon. In the meantime, consider working with the firewall turned off. And if you have a spare computer, can you please try a fresh install (of f44, I suppose) and see if the problem goes away. If it doesn’t, please create an issue here.
No
I am not going to reinstall Fedora. I has taken me weeks to get it to my preferred setup. Winboat was working just fine with the firewall enabled for weeks. Winboat didn’t stop working until the latest firewall updates just a few days ago.
Looking at your zones again, the only zone that has an interface is home.
Have you tried adding dhcp and dns to the home zone?
Also, if you open Winboat and then get all the zones, you should see the zone it should be using become “active” I think.
Edit: You may need rdp on there as well. I did some searching, but I also came across maybe 3 or 4 other random port numbers I am not sure of.
Fair enough. If you’re really sure it is reproducible, then please consider opening a github issue. I will also try to reproduce, but not before August, when I’m done with my taxes 
Update
Adding “dhcp + dns” in Docker either on running or permanent with reload had no effect. Winboat was shut down and restarted, no go.
Adding “dhcp + dns” in Home either on running or permanent with reload had no effect. Winboat was shut down and restarted, no go.
Stopping firewall while Winboat is running (no restarting) instantly gives access to the Internet again.
Restarting firewall while Winboat is still running will instantly block it again.
I will remove the added services dns/dhcp in both both “Home” and “Docker” to bring it back to default state
Honestly, I was not sure how, so I asked AI how this can be identified because that would be smartest here. I just tested it myself and it seems to work. I guess I learned something, haha.
*You may want to only be using Winboat (nothing else intentionally running or open) after the logs quiet down, or you will get gibberish noise that is unrelated to Winboat.
Check the current log setting value (keep note):
firewall-cmd --get-log-denied
Enable logging all if it is not already set to “all”:
sudo firewall-cmd --set-log-denied=all
*Mine was already set to all, but you may have to reload if yours is not already set to all. Not sure.
Have your terminal open while you open Winboat, but this is how you will watch logs and for which zone it is logging under:
sudo journalctl -f -k
*This should help identify what and where the problem is.
*Use Ctrl-C to stop the logging in terminal when done.
*You can use dmesg, but that is an insane amount of data that did not seem necessary.
You will only really get you the protocol and port numbers that way.
Proto = protocol
SPT = source port
DPT = destination port
You should be able to figure out the zone easy this way. You may have to dig a bit to find the actual service being used from the protocols and port numbers if you want to that route instead of just adding the required protocols/ports.
There is a reason that I hate dealing with firewalls 
Anyway, it appears that the problem seems to be with zone: FedoraWorkstation
It also shows as “default/active”.
But for the life of me, I can’t see what is in the rules that stops the traffic. I show you a snipped of the log as recorded as it just keeps repeating. In that snipped, I see that Winboat/docker/rdp and constantly trying different ports to get through or actually get back in from the outside, but all these ports appear to me to be by default open.
I don’t know…
Jul 12 19:27:33 fedora kernel: filter_FWD_FedoraWorkstation_REJECT: IN=br-75bfbe7658f3 OUT=wlp192s0 MAC=6a:a6:85:9e:73:cf:da:31:dc:83:ae:f5:08:00 SRC=172.18.0.2 DST=52.110.12.40 LEN=52 TOS=0x00 PREC=0x00 TTL=126 ID=15926 DF PROTO=TCP SPT=56604 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0
Jul 12 19:27:33 fedora kernel: filter_FWD_FedoraWorkstation_REJECT: IN=br-75bfbe7658f3 OUT=wlp192s0 MAC=6a:a6:85:9e:73:cf:da:31:dc:83:ae:f5:08:00 SRC=172.18.0.2 DST=52.123.252.222 LEN=52 TOS=0x00 PREC=0x00 TTL=126 ID=2531 DF PROTO=TCP SPT=56598 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0
Jul 12 19:27:33 fedora kernel: filter_FWD_FedoraWorkstation_REJECT: IN=br-75bfbe7658f3 OUT=wlp192s0 MAC=6a:a6:85:9e:73:cf:da:31:dc:83:ae:f5:08:00 SRC=172.18.0.2 DST=125.56.205.154 LEN=52 TOS=0x00 PREC=0x00 TTL=126 ID=47943 DF PROTO=TCP SPT=56605 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0
Jul 12 19:27:33 fedora kernel: filter_FWD_FedoraWorkstation_REJECT: IN=br-75bfbe7658f3 OUT=wlp192s0 MAC=6a:a6:85:9e:73:cf:da:31:dc:83:ae:f5:08:00 SRC=172.18.0.2 DST=40.126.14.164 LEN=52 TOS=0x00 PREC=0x00 TTL=126 ID=2785 DF PROTO=TCP SPT=56600 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0
now look at the zone’s rules/services:
FedoraWorkstation (default, active)
target: default
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces:
sources:
services: dhcpv6-client samba-client ssh
ports: 1025-65535/udp 1025-65535/tcp
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
Actually, do I need to open port “dpt=443” as it doesn’t appear to be in the range of “FedoraWorkstation”. ??
Nope
That didn’t fix it either. Removed again.