CentOS

Hi there.

I come from CentOS 7 and didn't have this problem.

I have a "Router" that essentially is a PC with 4 network adapters.
Presently I have 3 used network adapters: WAN connected to the ISP as Bridge (Dynamic IP), Local NetWork (192.168.1.254) and the 3rd adapter (192.168.2.254) that goes to a secundary NetWork that has it's own router.
In the previous CentOS (7), I just had to set the routing table to forward the traffic the was targeted at that secundary NetWork with something like this:
route add -net 192.168.3.0/24 gw 192.168.2.253
And the router in that secundary network would have the default gateway as 192.168.2.254

Presently, to activate the routing it seems that I have to activate the option "Masquerade Zone" in the Firewall Configuration, but this causes problems because it seems to masquerade traffic that it shouldn't... I'm able to get traffic into the secondary NetWork, but not the other way around and when I do a netstat in that network I see that the connections from the Local NetWork have a source address of 192.168.2.254 instead of 192.168.1.x

How can I enable routing without masquerading for a zone?

Cheers.

There is "routing" and there is "forwarding".
Routing involves looking at routing tables and asking: "Where should we toss this packet?"
Forwarding determines whether we let a packet that did pop in from somewhere to go out via another connection.

Forwarding is enabled in the kernel, if you get '1' with:

Code: Select all

sysctl net.ipv4.ip_forward

It seems that if you have masquerade enabled on a zone then it enables forwarding too. (Definitely true with the 'external' zone.)
You can enable forwarding on the fly with:

Code: Select all

sysctl -w net.ipv4.ip_forward = 1

But if you want to enable on every boot, then add a file, for example:

Code: Select all

echo "net.ipv4.ip_forward = 1" > /etc/sysctl.d/router.conf

See man 5 sysctl.d

Similarly, route add -net 192.168.3.0/24 gw 192.168.2.253 is not persistent config. Just till reboot.
Futhermore, command 'route' got "better" alternative two decades ago:

Code: Select all

ip route add 192.168.3.0/24 via 192.168.2.253

But, to make it persistent, you should add it to the config of the connection.

The network config is with NetworkManager by default. Commands to see summary, devices, and connections:

Code: Select all

nmcli
nmcli d s
nmcli c s

Lets say that the name of the third connection is System em3 and you want to add the route:

Code: Select all

nmcli c mod "System em3" +ipv4.routes "192.168.3.0/24 192.168.2.253"

If you had supplied that route while creating the connection, then it would appear as the connection starts.
If connection is already up, then the modification does not activate immediately. You need to restart the connection.

All that said, firewalld is not for routers. Replace it with nftables.service and write proper rules.
Examples: https://wiki.gentoo.org/wiki/Nftables/Examples

Firewall is another part of forwarding. While net.ipv4.ip_forward says whether kernel tries to forward at all, the firewall rules determine whether such forward is allowed. Current version of firewalld cannot create sane forwarding rules without inhuman effort. (Upstream can, but RHEL 8.3 does not have it, so hope is many many months away.) Learn the nftables.

Hi.

First of all, thank you taking the time to try to help me.

Let's see if I can understand and answer everything:

Code: Select all

[root@multirouter /]# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

I know this one for ages (probably before starting using Centos with version 5), so this is not the problem;

About the routing not being permanent, I know and just said the command for easiness, the route was added with the Gui Network settings and appears with "router -n" and nmcli shows the network, but not the gateway for it;

Code: Select all

enp1s0: connected to WAN
        "Intel 82583V"
        ethernet (e1000e), XX:XX:XX:XX:XX:48, hw, mtu 1500
        ip4 default
        inet4 XX.XX.107.46/21
        route4 0.0.0.0/0
        route4 XX.XX.104.0/21
        inet6 xxxx::8f37:b488:b00e:ac6d/64
        route6 xxxx::/64
        route6 ff00::/8

enp2s0: connected to Local NetWork
        "Intel 82583V"
        ethernet (e1000e), XX:XX:XX:XX:XX:51, hw, mtu 1500
        inet4 192.168.1.254/24
        route4 192.168.1.0/24
        inet6 xxxx::ee8:5cff:fe68:5e51/64
        route6 ff00::/8
        route6 xxxx::/64

enp3s0: connected to Bridge NetWork
        "Intel 82583V"
        ethernet (e1000e), XX:XX:XX:XX:XX:52, hw, mtu 1500
        inet4 192.168.2.254/24
        route4 192.168.2.0/24
        route4 192.168.3.0/24
        inet6 xxxx::ee8:5cff:fe68:5e52/64
        route6 ff00::/8
        route6 xxxx::/64

The nmcli command don't show anything special, most of it also shows with "ip addr" command;

I will look into nftables, anyway, I was already using firewalld with Centos 7, is it so much different?

I found that I had some rules in the FORWARD allowing traffic from and into 192.168.3.0/24, but it does not seem to work...

Code: Select all

-d 192.168.3.0/24 -j ACCEPT
-s 192.168.3.0/24 -j ACCEPT

Any more ideas would be appreciate....

Cheers.

The kernel of CentOS 7 has netfilter. Rules to netfilter are written with iptables. Firewalld.service uses iptables . One can see the rules, for example with:

Code: Select all

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

The kernel of CentOS 8 has nftables. Rules to nftables are written with nft. Firewalld.service uses nft. One can see the rules with:

Code: Select all

sudo nft list ruleset

CentOS 8 has still command iptables, but it is a wrapper to nft. It does not support 100% of iptables syntax.

The nftables can have many "tables" and has no chains by default.
The use of iptables wrapper automatically creates tables and (empty) chains that mimic netfilter's built-in tables and chains.
These are the only ones that the iptables -S / iptables -L show in CentOS 8.

Firewalld creates some tables for its "native" rules, but it also creates what iptables wrapper does, because firewalld supports something (direct/passthrough?) only in iptables syntax. There are thus both

Code: Select all

table ip filter {
 ...
	chain FORWARD {
		type filter hook forward priority filter; policy accept;
	}
 ...
}

and

Code: Select all

table inet firewalld {
 ...
	chain filter_FORWARD {
		type filter hook forward priority filter + 10; policy accept;
		ct state { established, related } accept
		ct status dnat accept
		iifname "lo" accept
		ip6 daddr { ::/96, ::ffff:0.0.0.0/96, 2002::/24, 2002:a00::/24, 2002:7f00::/24, 2002:a9fe::/32, 2002:ac10::/28, 2002:c0a8::/32, 2002:e000::/19 } reject with icmpv6 type addr-unreachable
		jump filter_FORWARD_IN_ZONES_SOURCE
		jump filter_FORWARD_IN_ZONES
		jump filter_FORWARD_OUT_ZONES_SOURCE
		jump filter_FORWARD_OUT_ZONES
		ct state { invalid } drop
		reject with icmpx type admin-prohibited
	}
 ...
}

I did take ruleset created by firewalld:

Code: Select all

nft list ruleset > /etc/nftables/my.nft
chmod 600 /etc/nftables/my.nft

Then I edited that to my liking (which obviously is the delicate part) and installed nftables.service:

Code: Select all

dnf install nftables
echo 'include "/etc/nftables/my.nft" >> /etc/sysconfig/nftables
systemctl disable firewalld.service
systemctl stop firewalld.service
systemctl start nftables.service
systemctl enable nftables.service

Hi.

Thank you again for your time replying to me.

Don't don't yet understand enough about how nftables work to dive into that solution yet.

I come from ipchains and it was a while to adapt to iptables, now that I almost know what I'm doing with iptables it changes to nftables...

I see that firewalld uses nftables, so I can tweak the present configuration to allow the forwarding between networks, can you point me to the rules I need for that function?

Maybe I may be able to use the direct/passthrough options to pass that rules without messing with the configuration files.

Cheers.

Firewalld 0.9 has "policy objects". Their introduction https://firewalld.org/2020/09/policy-ob ... troduction writes:

With some exceptions (e.g. masquerade, forward-ports) firewalld was previously limited to being an end-station firewall. This meant you could not use it to filter traffic flowing between virtual machines, containers, and zones. A subset of that functionality was available by using the direct interface and writing your own iptables rules, but it wasn’t a great user experience.

Note that CentOS 8 has firewalld 0.8. The "previous, limited" version.

I have used ipchains, but adopted iptables many years ago. (Linux kernel got nftables almost seven years ago; CentOS with 8, last year.) When I had to replace CentOS 6 router (manually crafted iptables ruleset) with CentOS 8 I had two options: (A) force firewalld to route or (B) learn nftables. Neither option is probably "a great user experience", but learning nftables was the lesser evil for me.

Firewalld takes the "direct rules" in "iptables syntax". If you know what your rules would be in iptables-based machine, then that is a starting point.

Hi.

Thank you for your answer. That opinion pushes me into learning how nftables works.

About some comments:
IPCHAINS: yes, I used ipchanes since more than 20 years ago and started using iptables maybe 15 years ago (don't really remember)

Your last sentence about direct rules points me to having other problem, because I applied the same rules I know I had working in Centos 7 and something is not working as it should, the fact is that I didn't have to activate the masquerade for that zone for the forwarding to work...
Even if I apply some "-j ACCEPT" rules in the FORWARD chain of IPTABLES with direct rules it does not work... maybe some other rule is blocking the traffic between networks and even the rules I add are not overriding those ones.

Anyway, thanks again for your time... I will try to spend some of my time learning nftables...

Cheers.

CentOS

Activating Routing without Masquerading

Activating Routing without Masquerading

Re: Activating Routing without Masquerading

Re: Activating Routing without Masquerading

Re: Activating Routing without Masquerading

Re: Activating Routing without Masquerading

Re: Activating Routing without Masquerading

Re: Activating Routing without Masquerading