firewalld-users December 2020

firewalld-users@lists.fedorahosted.org

5 participants
3 discussions

How to allow ipv4/ipv6 port range for a cidr block
by Steven Frazier 14 Dec '20

14 Dec '20

I have a cidr block that I would like to allow 174.192.0.0/10. From only the following tcp/udp ports: 5000-5299 that I want to add to trusted. I am not sure what the proper add would be. I best guess would be the following, could someone please correct my best guess below? firewall-cmd --permanent --add-service=family="ipv4" source address="174.192.0.0/10" port protocol="tcp" port="5000-5299" accept' firewall-cmd --permanent --add-service=family="ipv4" source address="174.192.0.0/10" port protocol="udp" port="5000-5299" accept' firewall-cmd --permanent --add-service=family="ipv6" source address="174.192.0.0/10" port protocol="tcp" port="5000-5299" accept' firewall-cmd --permanent --add-service=family="ipv6" source address="174.192.0.0/10" port protocol="udp" port="5000-5299" accept' TIA.

2 2

Not possible to configure forwarding between subnets?
by andrew goh 12 Dec '20

12 Dec '20

hi, I ran into various issues attempting to setup firewalld that would forward ip traffic between 2 subnets. lets start with the network map. +-- lan subnet 1 wan <---- router (firewalld) + +-- lan subnet 2 firewalld runs in the router box. the wan interface works well in firewalld and is simply in the 'external' zone. it is simply marked masquerade so that it is doing NAT for all traffic bound for the internet. no issues with this LAN 1 and LAN 2 are local ipv4 /24 subnets e.g. you can imagine one being 192.168.1.0 / 24 the other being 192.168.2.0 / 24. the trouble is ip traffic is blocked between the 2 LAN subnets you can imagine one being 'home' zone the other being 'work' zone. all (http) connections are intercepted by the firewall setup by firewalld and rejected. that happens even if i place both of them in the same zone say 'home' or 'work'. I went ahead and tried 'direct configuration' putting a rule like * filter FORWARD -s 192.168.1.0/24 -d 192.168.2.0/24 -j ACCEPT * filter FORWARD -s 192.168.2.0/24 -d 192.168.1.0/24 -j ACCEPT However, this is to no avail and all traffic are still rejected. finally i did the deep dive and tried tracing using nftrace https://wiki.nftables.org/wiki-nftables/index.php/Ruleset_debug/tracing I found out something rather alarming, in that the rules setup in 'direct configuration' are based on iptables command while firewalld setup its own large sets of nft rules. it turns out firewalld is using the 'INET' ( ipv4 and/or ipv6) family for its rules. https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families While the iptables rules done in 'direct configuration' goes into the IP family. And the firewalld's own INET rules are evaluated *before* the IP rules setup in 'direct configuration'. the packets are rejected in the firewalld rules before they can even be evaluated by the 'direct configuration' iptables rules. Is there anyway to configure forwarding between the 2 LAN subnets using firewalld ? i've even tried 'rich rules' and 'sources' but firewalld it seemed always patch the rules elsewhere in the input and output nftables chains (this are intended for the router itself) except the 'forward' chain which happens during routing and are intended for other hosts than the router itself. i.e. there seem to be no way to specify in firewalld to say that traffic between the 2 subnets should be forwarded to each other. Thanks in advance, Andrew

2 3

Difference in IPv4 v.s. IPv6?
by Ed Greshko 07 Dec '20

07 Dec '20

Hi, System is a Fedora 33 VM running firewalld-0.8.4-1. I have: [root@f33k ~]# firewall-cmd --get-active-zones drop interfaces: enp1s0 enp1s0 has addresses 192.168.122.26 and 2001:b030:112f:2::53. If I try to ssh to it from another system I get.... [egreshko@meimei ~]$ ssh 192.168.122.26 ^C Meaning it "hangs" until I ctrl-C it or it will timeout at some point if left alone. But I get this using the IPv6 address [egreshko@meimei ~]$ ssh 2001:b030:112f:2::53 ssh: connect to host 2001:b030:112f:2::53 port 22: No route to host So, is this a difference in how the FW handles IPv6 or due to how IPv6 works on the source side? Thanks, Ed

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

firewalld-users December 2020