Firewall masquerade and MTU problems

[ukoda]

I have done an unplanned upgrade of a server from CentOS 8 Stream to Rocky 9.5. This server also has the PPPoE Internet connection so provides Internet access to all other IP devices on the LAN via NAT masquerade. Initially I had a lot of network timeout failures for devices other than the server itself. I have tracked the problem to the PPPoE interface having a MTU of 1492 while the LAN MTU is 1500.

On my earlier system this all just worked. From what I understand “MTU discovery” should take care of this but I don’t know how that actually works. If I manually change the LAN MTU to 1492 on a device using the server as its gateway it works fine. So for now I have simply added “option interface-mtu 1492;” to dhcpd.conf and now have a working system.

However I suspect this not how things are meant to be done?

I used firewall-cmd to set things up, using Linux NAT Firewall Setup as a starting point. There were a few things in their set up script which I had not seen or used before.

Firstly there was:

firewall-cmd --zone=internal --add-masquerade --permanent

Which I assume I don’t actually need for local device that want Internet access. Later I will want to forward a port for my KiwiSDR to give public access, as I had before. So maybe I will need it when I try to get that working again?

There were some new commands I had not seen before that apparently relate to Rocky 9, so used them to. I don’t know if they are relevant to the problems I had. They are:

# This next bit is needed for RHEL 9, Rocky 9, Fedora 35+
# create new policy to allow traffic forwarding between zones
firewall-cmd --permanent --new-policy policy_int_to_ext
firewall-cmd --permanent --policy policy_int_to_ext --add-ingress-zone internal
firewall-cmd --permanent --policy policy_int_to_ext --add-egress-zone external
firewall-cmd --permanent --policy policy_int_to_ext --set-priority 100
firewall-cmd --permanent --policy policy_int_to_ext --set-target ACCEPT

I did all the network set up using the nmcli commands so the NetworkManager should be in control of everything, I think.

So open to pointers on if I should be doing anything differently, or links to relevant reading.

Thanks

[jlehtone]

The FirewallD is a frontend, a “middleware”. It creates rules for the backend, nf_tables in the kernel.
One can see what the “logical” FirewallD config translates into with:
[EDIT]

nft list ruleset

[/EDIT]
It is a bit long list, with plenty of empty chains, so spotting “the beef” takes effort.

---

I don’t know PPPoE or MTU, but why do I associate the MTU discovery with IPv6?

[ukoda]

Thanks for that. The best I could find was the files that firewalld has in the /etc/firewalld/ directory. I tried comparing that with a backup from the earlier Centos * install, but that was not helpful.

Isn’t ‘dnf’ the latest package manager? “dnf list ruleset” just gives the error “No matching Packages to list”

PPPoE is “Point-to-Point Protocol over Ethernet” which is the protocol my ISP uses for my fibre connection. MTU is “Maximum Transmission Unit”, or the largest IP packet size a network device. Because the Internet interface maximum packet size is 8 bytes smaller than the LAN interface then packets over a certain size will be truncated, corrupting them, unless the situation is handled correctly.

By forcing the LAN packet size limit to match the Internet connection I have stopped the issue, but I don’t think the way I have done it is meant to be necessary. Google was ok about warning about the issue but rather sparse on information about dealing with it in the era of nf_tables.

[jlehtone]

@ukoda

Isn’t ‘dnf’ the latest package manager? “dnf list ruleset” just gives the error “No matching Packages to list”

My bad.

nft list ruleset

---

@ukoda

The best I could find was the files that firewalld has in the /etc/firewalld/ directory. I tried comparing that with a backup from the earlier Centos * install,

In principle, that config ought to be transferrable. Alas, the FirewallD in CentOS 7 did lack support for things, like inter-zone rules (i.e. rules for “real router”, which the “Policy Objects” now implement). Hence, the config options have changed. Translating from one system to another is almost never fully automatic.