Firewalld Not Allowing Local Traffic

I’d like to be able to access my development servers from other computers in my home. I had this working last week, but then I went and got a new hard drive and I wanted to put my OS on that, instead - and I’ve been unable to get it working again.

Here’s what I’ve done:

Firewalld has been (permanently) configured so:

  • ‘home’ is my default zone
  • http & https are enabled on ‘home’

The local web server I’m running works, and I’ve confirmed it’s a firewall issue: if I disable the firewalld service via systemctl, I can access the web server just fine.

when I look at the output of nft list table inet firewalld, I see the following:

chain filter_IN_home {
		jump filter_IN_home_pre
		jump filter_IN_home_log
		jump filter_IN_home_deny
		jump filter_IN_home_allow
		jump filter_IN_home_post
		meta l4proto { icmp, ipv6-icmp } accept
	}

and

	chain filter_IN_home_allow {
		tcp dport 22 accept
		ip daddr 224.0.0.251 udp dport 5353 accept
		ip6 daddr ff02::fb udp dport 5353 accept
		udp dport 137 ct helper set "helper-netbios-ns-udp"
		udp dport 137 accept
		udp dport 138 accept
		ip6 daddr fe80::/64 udp dport 546 accept
		tcp dport 80 accept
		tcp dport 631 accept
		udp dport 631 accept
		udp dport 443 accept
		tcp dport 443 accept
		tcp dport 3306 accept
	}

which, like, seems like it should work? but when I hard refresh after starting firewalld again, I see the following line in journalctl -x -e

Jul 28 22:43:10 desktop kernel: filter_IN_home_REJECT: IN=enp8s0 OUT= MAC=blahblahblah SRC=10.0.0.143 DST=10.0.0.59 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=23147 DF PROTO=TCP SPT=37772 DPT=5173 WINDOW=64240 RES=0x00 SYN URGP=0 

Anyone know what I’m missing here?

I’ve spent all day trying to figure this out with no luck yet - I understand a lot more now! but not enough yet.

if anyone comes along and sees this who knows things about things - do firewalld “zones” matter for a computer that never moves? In other words, for a desktop computer, does it matter what zone you’re working with?

You can add a new zone for devices on the local subnet (or just individual IPs if you want).

sudo firewall-cmd --zone=my_cool_zone --add-source=192.168.0.0/24 --permanent

Then open the ports in that zone for whatever services need to get through.

sudo firewall-cmd --zone=my_cool_zone --add-port=22/tcp --permanent

Finally, reload the firewall and test.

sudo firewall-cmd --reload

I’m going to try this next - it seems like a good approach, though I’m still baffled by what’s happening.

I found myself skipping firewalld altogether and focusing on iptables - for which, if I understand this correctly, firewalld is merely a front end.

I followed the Arch Wiki’s Simple Stateful Firewall guide, and then just disabled firewalld altogether, and that seems to be an adequate solution - I can access my server locally, but I ssh’d to my work computer and tried to ping the server, and tried to wget it, and both were unable to connect, so, that’s adequate I think?

Edit: spoke too soon. I had enabled iptables.service, but I hadn’t started it - once I started it, the same thing started happening - no local network connections.

Is it at all relevant that my home network uses 10.0.0.x-based ip addresses?

Firewalls, packet filtering, NAT etc are almost guaranteed to confuse the hell out of you until you finally understand it, and then technology will change.

Like ipchains became iptables, and there may even have been some other netfilter before ipchains.

I almost understand iptables, and now nftables is transitioning in, so firewalld could also be a mishmash of iptables and nftables, like some firewall setups can be on other systems, or it probably will be in the future. Looking at your first post, looks like firewalld is using nftables, not iptables, so concentrating on iptables is probably extra confusing. I would stop trying to use iptables and look for a guide for nftables. While there is some cross compatability with iptables commands, it will be harder to understand, and harder to debug if both are active, or some iptables commands are being translated into nftables rules.

If you want to understand firewalling and iptables, then examine all the rules firewalld has created. Make sure you check the filter table, the nat table, and the mangle table. Advanced filtering may also use packet marking and alternate routing tables, another way to confuse me, and I guess you too.

On my remote VPS setups I have a very simple firewall setup with allow connected sessions, drop invalid, and allow very few selected service to establish connections. I have a couple of NAT rules too. I generally don’t filter output, and forward is only interesting if I have multiple interfaces like when running a VPN. My setup is simple and easy to understand.

On my local machines I just am very restrictive of what can get in to the local net, and what services are running, and lock them down. On my laptop I am even more restrictive of what is running, mainly only expose ssh, keys only, and fail2ban to catch persistent but doomed to failure because of keys only ssh password guessers. I’m considering expanding fail2ban to detect other connection attempts and block them too.

When you have zones etc, things get more complicated, and adding more zones and interfaces and services can cause the combinational complexity to explode. Zones are supposed to make things simpler, but that it only the case when you understand the interactions. If you just dump all the generated rules and try to understand it from that then it is just a big mess.

If you are using a VPN that will make things more complicated.

Looking at the Arch Wiki SSF link, it seems similar to what I use on my external VPS, but mine is simpler as I don’t need even that complexity. The wiki link seems to be iptables, while you seem to have firewalld generating nftables, Pick one or the other.

There isn’t any thing special about 10.0.0.x/24 in general.

Looking at the block in the first post, DPT=5173 while chain filter_IN_home_allow doesn’t have a rule for tcp dport=5173 allow in the chain so that is consistent. You don’t show filter_IN_home_REJECT chain of even if there is such a chain.

2 Likes

Ok after giving this a few days, I tried something that worked - everything everywhere all at once.

I used firewalld, and allowed all the services I wanted (http, https, mysql, etc). Then I specifically called out the IP addresses of the two main computers I’ll use to connect to the server, and then specifically called out the main ports that I use in development - 5173, 5174, etc. Blanketing it in rules, it seemed to be happy with me, and it’s working great. Thank you everyone for your feedback and support!

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.