Cockpit will not appear on the Tailnet, firewalld issue?

Ask Fedora
, ,
1

Hi All,

I’m new to Fedora, also new to firewalld. I like the system, although there are some struggles (I’ve posted more today.)

Currently I’m trying to make sure that cockpit (and later also other services) only work via the tailnet.

I think this shows I have set everything up correctly:

$ sudo firewall-cmd --get-active-zones
public (default)
  interfaces: enp114s0
trusted
  interfaces: Tailscale0

$ sudo firewall-cmd --zone=trusted --list-services
cockpit https ssh

# The public zone only has ssh
$ sudo firewall-cmd --zone=public --list-services
ssh

However, when going to https://castor:9090 I can’t connect.

Nmap for both interfaces shows:

$ nmap -p 9090 10.0.0.196 -Pn
Starting Nmap 7.98 ( https://nmap.org ) at 2025-12-16 19:37 +0100
Nmap scan report for 10.0.0.196
Host is up (0.0048s latency).

PORT     STATE    SERVICE
9090/tcp filtered zeus-admin

Nmap done: 1 IP address (1 host up) scanned in 0.53 seconds

$ nmap -p 9090 castor -Pn
Starting Nmap 7.98 ( https://nmap.org ) at 2025-12-16 19:37 +0100
Nmap scan report for castor (100.68.55.15)
Host is up (0.0035s latency).
rDNS record for 100.68.55.15: castor.tail1c6b1.ts.net

PORT     STATE    SERVICE
9090/tcp filtered zeus-admin

Nmap done: 1 IP address (1 host up) scanned in 1.04 seconds

Castor is the magic DNS name in the Tailnet. It worked before I started blocking services. I did re-enable mDNS, doesn’t help.

Any tips?

2

I haven’t read through https://tailscale.com/kb/1082/firewall-ports. But by changing the zone of enp114s0 from FedoraWorkstation to public the following port ranges have been closed:

firewall-cmd --info-zone=FedoraWorkstation
...
  ports: 1025-65535/udp 1025-65535/tcp

Maybe run tcpdump and open some port(s) up again?

3

Hmm, this getting pretty troublesome, there is a lot of weird, unexpected behavior in Fedora imho, first Network manager changes zones without my permission (Firewalld confusion, interface is automatically put back in wrong zone - #5 by freekvh), now you’re telling me that even though every indicator in firewalld tells me a service should be available, there is some other layer that still prevents access? This is a bug right? Why would firewalld, which works with zones en ports hide some settings for some ports in some zones?

I don’t want give the impression of gas-lighting but people say NixOS has a steep learning curve, but stuff like this does not really happen there. Things like opening ports, or say SSHkey based encrypted drive unlock both take 1 or 2 lines of unambiguous config, instead of 10 dracut and config file editing steps and a hunt for any hidden layers. Sure NixOS has it’s own issues, it hides the complexity (but so does firewalld).

How can I best make this better myself as someone completely new to Fedora?

The installer was a similar experience, honestly the Arch one is a lot clearer. Is there a way to document my experiences in a way that Fedora devs can make use of it? I could record my install session for example? I documented at least 10 issues which I could post somewhere.

Maybe I should have opted for Centos Stream, does that have stuff like this ironed out?

4

Here is some additional info from the command you gave, my output is different:

freek@castor:~$ sudo firewall-cmd --info-zone=FedoraServer
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: 

freek@castor:~$ sudo firewall-cmd --info-zone=public
public (default, active)
  target: default
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: enp114s0
  sources: 
  services: mdns ssh
  ports: 
  protocols: 
  forward: yes
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

freek@castor:~$ sudo firewall-cmd --info-zone=trusted
trusted (active)
  target: ACCEPT
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: Tailscale0
  sources: 
  services: cockpit https ssh
  ports: 
  protocols: 
  forward: yes
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:
5

Firewalld has services and ports. While the cockpit service has been enabled on the Tailscale interface, ports 1025-65535 have been closed on the Ethernet interface by moving it to the public zone:

firewall-cmd --info-zone=FedoraWorkstation
  ports: 1025-65535/udp 1025-65535/tcp

firewall-cmd --info-zone=public
  ports:

To provide a working Tailscale interface, VPN traffic needs to reach a tailnet port through the Ethernet interface. The article linked above claims there should be no need to open any ports, except <list of exceptions>.

You could try to reopen the port ranges by moving the Ethernet interface back to the FedoraWorkstation zone. If it works, you can either leave it as it is or find out which specific port needs to be open.

6

Thanx for the response.

My default zone was FedoraServer, and in that zone everything worked. The FedoraServer zone does not have open ports (just services).

$ sudo firewall-cmd --info-zone=FedoraServer
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:

Moreover, I can ssh into the box over Tailscale, ssh castor just works. I also see the server in the Tailscale admin channel (though granted, that can be out of date info.) Still I doubt the issue is in the Tailscale layer.

7

If ssh castor works Tailscale works. Still, the filtered in 9090/tcp filtered zeus-admin seems to indicate port 9090 is blocked by firewall.

If you want to give tcpdump a try, connect to Cockpit over tailnet while running

sudo tcpdump -nn -i enp114s0 icmp or udp
sudo tcpdump -nn -i Tailscale0 icmp or port 9090

and provide the first few packets. Consider removing public IP addresses.

1 Like
8

Thanx for staying on the case. The output from the physical nic is a bit much, the Tailnet gives this everytime I try to connect to https://castor:9090

$ sudo tcpdump -nn -i tailscale0 icmp or port 9090
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tailscale0, link-type RAW (Raw IP), snapshot length 262144 bytes
14:22:45.806787 IP 100.99.163.88.46832 > 100.68.55.15.9090: Flags [S], seq 3716669279, win 64480, options [mss 1240,sackOK,TS val 1194968766 ecr 0,nop,wscale 7], length 0
14:22:45.806965 IP 100.68.55.15 > 100.99.163.88: ICMP host 100.68.55.15 unreachable - admin prohibited filter, length 68
14:22:50.980247 IP 100.99.163.88.50214 > 100.68.55.15.9090: Flags [S], seq 314131415, win 64480, options [mss 1240,sackOK,TS val 1194973939 ecr 0,nop,wscale 7], length 0
14:22:50.980344 IP 100.68.55.15 > 100.99.163.88: ICMP host 100.68.55.15 unreachable - admin prohibited filter, length 68
14:22:51.869116 IP 100.99.163.88.50216 > 100.68.55.15.9090: Flags [S], seq 2126023601, win 64480, options [mss 1240,sackOK,TS val 1194974829 ecr 0,nop,wscale 7], length 0
14:22:51.869222 IP 100.68.55.15 > 100.99.163.88: ICMP host 100.68.55.15 unreachable - admin prohibited filter, length 68

Admin prohibited filter sounds like the thing :slight_smile:

Edit:
Same is true for the public zone, although there it is expected to be blocked of course:

$ sudo tcpdump -nn -i enp114s0 icmp or port 9090
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp114s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:27:22.499951 IP 10.0.0.248.59062 > 10.0.0.196.9090: Flags [S], seq 2378565477, win 64240, options [mss 1460,sackOK,TS val 2012646578 ecr 0,nop,wscale 7], length 0
14:27:22.500066 IP 10.0.0.196 > 10.0.0.248: ICMP host 10.0.0.196 unreachable - admin prohibited filter, length 68
9

Btw, while my other post is temporarily marked as spam, I tried this:

$ sudo firewall-cmd --zone=FedoraServer --change-interface=tailscale0
success

freek@castor:~$ sudo firewall-cmd --zone=FedoraServer --list-interfaces
tailscale0

freek@castor:~$ sudo firewall-cmd --zone=FedoraServer --list-services
cockpit dhcpv6-client ssh

And then it does work as expected.
But I’d rather understand by changing between 2 zones both with cockpit enabled has this effect before just switching the zone.

EDIT:

And now I found the issue, see this:

$ sudo firewall-cmd --zone=trusted --list-interfaces
Tailscale0 tailscale0

Apologies!!! No idea where that capital snuck in!!

Thanx for the help! I’m terribly sorry for the effort. I did learn a lot though…

What can be a bit confusing is that Firewalld will let you just make interfaces up without complaining, ie it will say:

$ firewall-cmd --get-zone-of-interface=Tailscalfreree0 
no zone

Where as “Not an interface” would have prevented my error. Still, all my bad of course, perhaps I’ll file a suggestions at the Firewalld project.

Edit2: Firewalld will happily let you work with non-existing interfaces · Issue #1530 · firewalld/firewalld · GitHub (the issue is pretty insidious, it will warn you for a non-existing interface, but not when the only mismatch is a capital! So we did at least catch a bug.)

1 Like