1

Although service dns is allowed through firewalld, DNS queries received through an internal interface are denied.

Here is the network:

PC ------------- SERVER ---------------- DNS Server
> nslookup       # firewall-cmd          DNS service
192.168.2.11 --- ens244 192.168.2.1
                 net.ipv4.ip_forward=1
                 ens160 192.168.1.1 ---- 192.168.1.11

This are the zone settings:

[christine@montreal ~]$ sudo firewall-cmd --list-all --zone=internal
internal (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens224
  sources:
  services: cockpit dhcpv6-client dns mdns samba-client ssh
  ports:
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
[christine@montreal ~]$

This are the log messages:

Jun 10 <...> montreal.<...>: FINAL_REJECT: IN=ens224 OUT=ens160 MAC=<...>  SRC=192.168.2.11 DST=192.168.1.11 LEN=71 TOS=0x00 PREC=0x00 TTL=127 ID=61889 PROTO=UDP SPT=53254 DPT=53 LEN=51

Tried: Rejection stops when target is set to ACCEPT, but this is not the strategy I want.

4
  • Not familiar with firewalld but you are forwarding DNS querys on IP level (instead of application level with a DNS forwarder like dnsmasq). So you need to get firewalld to make iptables (its backend) to allow corresponding forward traffics (instead of input traffics), or forward on application level.
    – Tom Yan
    Jun 13, 2022 at 6:50
  • @TomYan The net.ipv4.ip_forward parameter has the SERVER routing towards the two subnets. This works well for any IP traffic when no firewall filtering interferes. Do you mean that forwarded traffic is treated differently (by firewalld/nftables) than inbound traffic? Jun 14, 2022 at 3:04
  • Yes, iptables/nftables use different chains / hooks for input and forward traffics respectively. Your firewalld configuration may be allowing dns / ssh / etc. traffics that are destined for this server (on Layer 3 / IP Layer) itself, but that does NOT necessarily mean that you are instructing the firewall to also allow such traffics to be forwarded (i.e. when such traffics are destined for this server on Layer 2 / MAC layer only).
    – Tom Yan
    Jun 14, 2022 at 3:19
  • Thank you @TomYan, you make me progress. The next step for me is to learn how to inspect and configure nftables chains. Any help appreciated. (I didn't expect this SERVER machine to be that hard to set up.) Jun 14, 2022 at 19:56

1 Answer 1

1

DISCLAIMER: I am not really experienced / familiar with firewalld, so my judgement / opinion might be biased / inaccurate.

It's actually not very difficult to allow IP forwarding between two interfaces / network, especially if you want to "statelessly" allow that bidirectionally (i.e. allowing hosts on both sides to initiate communication with a host on another side). You really just need to create a zone, add the two interfaces to the zone, and then --add-forward the zone. (There's also --add-masquerade btw, which you might need/want as well.)

The problem is firewalld seems super inflexible and dumb to me. As I just mentioned, there doesn't seem to be any way at all for you to just "statelessly" allow forwarding of just one direction (while the other direction is only allowed "statefully", like typical LAN-WAN case). But perhaps that isn't a corcern in your case (since both network seems more or less an internal one, judging with the IP subnet blocks that are used).

An even bigger problem is, its design doesn't allow you to further cherry-pick an interface that has been added to a zone (for forwarding) to allow inbound traffics destined for this host. You can only allow with IP (ranges) by using "rich rules".

You can't even use another source zone (which has higher precedence than interface zone) to do that. For example, if you have a source zone for 192.168.2.0/24 that allows ssh connection or so to this host, it will overrides forwarding rules that are added by the interface zone just configured. Even if you --add-forward this zone as well, it will only allow something like "source 192.168.2.0/24 (logical AND) destination 192.168.2.0/24". If you additionally add 0.0.0.0/0 as a source to this zone, than you will be allowing ALL (from 0.0.0.0/0 to 0.0.0.0/0) forwarding traffics.

As I said at the beginning, these might all be just misjudgement. It could be just me not knowing how to use it right. Regardless I'd rather write my own nftables ruleset anyway. I hardly see any point in using it.

In any case, here's an example zone (file) that you might want to take as a reference:

$ cat /etc/firewalld/zones/myForward.xml 
<?xml version="1.0" encoding="utf-8"?>
<zone>
  <rule family="ipv4">
    <source address="192.168.1.0/24"/>
    <service name="ssh"/>
    <accept/>
  </rule>
  <rule family="ipv4">
    <source address="192.168.150.0/24"/>
    <service name="dns"/>
    <accept/>
  </rule>
  <interface name="wlan0"/>
  <interface name="bridge0"/>
  <forward/>
</zone>

It allows forwarding between wlan0 and bridge0 statelessly-bidirectionally, and allows ssh connection to this host from 192.168.1.0/24 (IP subnet on the wlan0 side), and allow DNS requests to this host from 192.168.150.0/24 (IP subnet on the bridge0 side).

(This is the only zone file in /etc/firewalld/zones/. I'm not using any builtin zones.)

EDIT: I've sort of found out a way to statelessly allow forward for only one direction. You can add the "WAN" interface (e.g. ens160) to the builtin public zone. For "LAN" interfaces that you want to forward traffic from (e.g. ens244), you do NOT need to add it to the public zone. However, you CANNOT add it to ANY other zone either, since that other zone will have its own forward configuration (it does NOT matter whether you --add-forward that zone). (You can check with nft list chain inet firewalld filter_FORWARD_ZONES. Note the gotos.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .