Score:0

why isn't firewalld blocking ports that aren't open?

hn flag

I have the following zone for my internal network:

internal (active)
  target: default
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: enp1s0f0
  sources:
  services: dhcpv6-client dns mdns samba-client ssh
  ports:
  protocols:
  forward: yes
  masquerade: yes
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

I only have a few services enabled for testing but if I run a web server on any port e.g. 8080 then curl http://serverip:8080 I get a response from the web server. The firewalld service is showing as running on the machine but isn't blocking access to port 8080 despite it not being listed above.

How can I debug why this isn't working as intended?

  • enp1s0f0 is definitely the correct interface
  • the firewalld service is running via systemd and showing as running

Here's my iptables -S output:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N DOCKER
-N DOCKER-ISOLATION-STAGE-1
-N DOCKER-ISOLATION-STAGE-2
-N DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -j DOCKER-USER
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -o br-d8adea070e26 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o br-d8adea070e26 -j DOCKER
-A FORWARD -i br-d8adea070e26 ! -o br-d8adea070e26 -j ACCEPT
-A FORWARD -i br-d8adea070e26 -o br-d8adea070e26 -j ACCEPT
-A DOCKER -d 172.19.0.2/32 ! -i br-d8adea070e26 -o br-d8adea070e26 -p tcp -m tcp --dport 443 -j ACCEPT
-A DOCKER -d 172.19.0.2/32 ! -i br-d8adea070e26 -o br-d8adea070e26 -p tcp -m tcp --dport 80 -j ACCEPT
-A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 6789 -j ACCEPT
-A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p udp -m udp --dport 5514 -j ACCEPT
-A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p udp -m udp --dport 1900 -j ACCEPT
-A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p udp -m udp --dport 10001 -j ACCEPT
-A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 8843 -j ACCEPT
-A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 8443 -j ACCEPT
-A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p udp -m udp --dport 3478 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN

I have services running in docker but it's not just services in docker that are accessible if I run php -S 192.168.2.1:8000 on the machine itself (not in a container) then curl 192.168.2.1:8000 on another machine on the network I get a response from the php server.

HBruijn avatar
in flag
Are you running `curl http://serverip:8080` from the server itself?
Tom B avatar
hn flag
no sorry, I should have said, it's running from a PC connected to the server via a switch connected to `enp1s0f0`
HBruijn avatar
in flag
Thank you for adding the iptables -S output. There is no obvious evidence in that ruleset that shows that firewalld hs created any iptables rules. Currently there aren't any actual rules in the INPUT chain and the policy `-P INPUT ACCEPT` is to allow all traffic.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.