Masquerade / firewalld target : impacts on filtering?

[Carbon69]

Hello,

I'm facing a situation that I would like to understand. Here is the situation, that can be reproduced:

On Centos7 OS. Configuration of two interfaces eth1 and eth2 with ip adresses X and Y

Code: Select all

-----------------> @X CENTOS @Y -----------------> @Z  -------
    dst_IP = A                      dst_IP = A
    src_IP = B                      dst_IP = B

edit /etc/firewalld/zones/TEST.xml, add the two interfaces, activate masquerade. The firewalld target is set to "default" by default.

add a route as following :

Code: Select all

Destination     Gateway     GenMask
A               Z           255.255.255.255

Then activate ip forward an put rp_filter to "loose" mode :

Code: Select all

sysctl net.ipv4.ip_forward=1
sysctl net.ipv4.conf.eth1.rp_filter=2
sysctl net.ipv4.conf.eth2.rp_filter=2

Now I'm only obesrving, listening on Centos interface @Y, if the paquets is routed, or dropped.

In this situation, if I route a packet (@dest=A) to CentOS, the paquet is routed to Z. -> Why firewalld does not block it? as there is no rule to accept it

If I disable masquerade , the paquet is not routed anymore. -> Why ?

With masquerade activated, if I change the target from default to DROP, the paquet is not routed anymore -> So the "default" target is not strictly identiqual to "DROP" target. What are exactly the differences ? I couldn't find any clear information

[jlehtone]

First, you can see the current active ruleset with either:

Code: Select all

iptables -S
iptables -t mangle -S
iptables -t nat -S

or

Code: Select all

iptables-save

If you look at that output, you should see that firewalld has lots of framework around the "rules".

With all that framework it is also harder to notice that firewalld (version in CentOS 7) has practically no support for custom filter on forwarded (i.e. routed) and output traffic. Some you can achieve with rich and direct rules, but only some and not trivially.

Ok, port forwarding (DNAT) is supported. Furthermore, if you put "inside" into trusted zone and "outside" into external zone, the you get ip_forward enabled and SNAT on external. That is, anyone in inside can connect anyone in outside and outside sees only the external IP of the "router".

The recommendation (by Red Hat for RHEL 7 and 8) is not to use firewalld for "complex setup". For workstation it is ok, for "real router" not.
The alternative was iptables.service, but then you have to generate the ruleset yourself.

I just noticed that since RHEL 7.6 it has been possible to install and use nftables.service. See https://access.redhat.com/documentation ... h_nftables
(Red Hat must have backported nftables functionality into the kernel of RHEL 7.)

You can now choose between FirewallD, where routing is hard/impossible, and iptables/nftables where you have to know how to write logical firewall ruleset. You don't want to make mistakes on firewall.


RHEL 8 has in practice firewalld and nftables and no, version of firewalld is still lacking. The 8.5 point update might improve that a bit later this year.