# Firewall masquerade and MTU problems **URL:** \ **Category:** Rocky Linux Help & Support\ **Created:** [January 28, 2025, 4:38am UTC](https://forums.rockylinux.org/t/firewall-masquerade-and-mtu-problems/17340 "2025-01-28T04:38:16Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![ukoda](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/ukoda/32/5146_2.png) [@ukoda](https://forums.rockylinux.org/u/ukoda)\ **Post date:** [January 28, 2025, 4:38am UTC](https://forums.rockylinux.org/t/firewall-masquerade-and-mtu-problems/17340/1 "2025-01-28T04:38:16Z")
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](https://wrightthisway.com/index.php/2022/07/18/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: ```auto 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: ```auto # 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 🙂 ---
**Author:** ![jlehtone](https://avatars.discourse-cdn.com/v4/letter/j/e9a140/32.png) [@jlehtone](https://forums.rockylinux.org/u/jlehtone)\ **Post date:** [January 28, 2025, 9:33am UTC](https://forums.rockylinux.org/t/firewall-masquerade-and-mtu-problems/17340/2 "2025-01-28T09:33:02Z")
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] ```auto 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? ---
**Author:** ![ukoda](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/ukoda/32/5146_2.png) [@ukoda](https://forums.rockylinux.org/u/ukoda)\ **Post date:** [January 28, 2025, 10:10am UTC](https://forums.rockylinux.org/t/firewall-masquerade-and-mtu-problems/17340/3 "2025-01-28T10:10:32Z")
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. ---
**Author:** ![jlehtone](https://avatars.discourse-cdn.com/v4/letter/j/e9a140/32.png) [@jlehtone](https://forums.rockylinux.org/u/jlehtone)\ **Post date:** [January 28, 2025, 10:45am UTC](https://forums.rockylinux.org/t/firewall-masquerade-and-mtu-problems/17340/4 "2025-01-28T10:45:34Z")
> [@ukoda](#): > > Isn’t ‘dnf’ the latest package manager? “dnf list ruleset” just gives the error “No matching Packages to list” My bad. 😳 ```bash 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. ---
**Author:** ![system](https://us1.discourse-cdn.com/flex020/uploads/rockylinux/original/1X/91b7219eec10e30013422e4df76c1d898711a5d5.svg) [@system](https://forums.rockylinux.org/u/system)\ **Post date:** [March 29, 2025, 10:45am UTC](https://forums.rockylinux.org/t/firewall-masquerade-and-mtu-problems/17340/5 "2025-03-29T10:45:50Z")
Closed on March 29, 2025, 10:45am UTC This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.