This environment has twins of virtually everything, including two web server / firewall / gateway systems, and they were getting long-in-the-tooth version wise, so I decided to upgrade from Fedora Server 30 to 38 on one of them. The idea was, of course, to bring both "into the modern era", but one at a time.
My timing was curious because at the very same time I began the upgrade, without even touching (physically or electronically) the other server, it decided to fail! So, now I have a "server down" scenario. -ugh- Unfortunately, this also means I don't have a working example to look at.
The one I didn't touch apparently has hardware issues and I can't address them right now, so I'm focused on the one I already started, which has now emerged from the upgrade / update to Fedora Server 38 just fine... EXCEPT for the fact that it has an issue where it's not serving as an actual gateway! ACK!
To be clear, FROM it you can access the internet and internal nets just fine. But it's not passing bits THROUGH it.
Of course, it's all generic Fedora Server (Fedora Core 38 with whatever tweaks the Server version gets) and whatever differences there are between 30 and 38 are likely substantial, though here all that matters is the networking.
It's got two NICs, and I configured them as was (that is, IP addresses, masks, etc), and in fact the installation process seemed to help by helping identify which NIC was internal and which external. I used my past experience and was pretty sure I'd done it correctly.
Indeed, once up I was instantly able to get to the box via ssh via the internal net. And, well, there's a lot to do on such a system but soon enough I got to the firewall aspects of it all. (At that point I didn't realize the other system was not-responsive.)
The first thing I did was move the interfaces to internal and external zones, and then turn on masquerading on the external zone. I forwarded mail through, and so forth, using the forward-port commands, etc, and ended up with the external looking like this:
# firewall-cmd --zone=external --list-all
external (active)
target: default
icmp-block-inversion: no
interfaces: enp1s0
sources:
services: http https ssh
ports:
protocols:
forward: yes
masquerade: yes
forward-ports:
port=25:proto=tcp:toport=25:toaddr=192.168.1.1
source-ports:
icmp-blocks:
rich rules:
The other, internal:
# firewall-cmd --zone=internal --list-all
internal (active)
target: default
icmp-block-inversion: no
interfaces: enp2s0
sources:
services: dhcpv6-client mdns samba-client ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
As an aside, I didn't add any of the services to the internal zone - they're apparently just defaults, I guess.
I spent PLENTY of time with the routing as it looked pretty screwy to me from the start. However, it's now this:
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default router 0.0.0.0 UG 100 0 0 enp1s0
router 0.0.0.0 255.255.255.255 UH 100 0 0 enp1s0
192.168.1.1 0.0.0.0 255.255.255.0 U 101 0 0 enp2s0
192.168.1.1 0.0.0.0 255.255.255.0 U 101 0 0 enp2s0
FYI, this version of Fedora doesn't use IP Tables but rather Network Manager - a toolset I've loathed from the first, but now seems more mature. And anyway, MOST of the materials to be found on the net speak of this older strategy and is of no help. However, this page points people in the right general direction.
UPDATE 1
I got the older hardware that had apparently failed back up. It wasn't that hard to do, but it increases our odds. ...And I say "our", because a colleague has joined me in the fray; he's focused on the older box, and I'm focused on the newer one.
NEITHER is passing bits through as a gateway / firewall, and that puzzled me. However my colleague reminds that the one system was already not really working right, likely due to a botched attempt to get a particular OpenVPN installation going. And since he did that work, well, he's going to continue there.
This HAS to be something simple; what basic fundamental is being overlooked?!
It turns out that the system was blocking pass-through for all but the services
dhcpv6-client,mdns,samba-client, andsshas those services were already configured as accepted.In a sense, it WAS working properly, just not configured to pass ALL the bits through.
Any firewall directive, however achieved, that changes the acceptance of packets from the internal interface will alter this situation, whether it be implemented via a
firewall-cmdornmclicommand or via a configuration file, such as/etc/NetworkManager/system-connections/enp1s0.nmconnection.As a practical matter, your quickest options are one of these changes for the internal interface:
put the interface in the "trusted" zone, or;
Enable each individual "service" and / or port (which is annoying for those of us who have our own services we've just invented - you know, "hackers" do this...), or;
set the "target" of the internal zone to "accept", like this:
firewall-cmd --zone=internal --set-target=ACCEPT, or;Note that I have never tried option 3, but according to the documentation, it should work.
In my view the security architecture is flawed, and given that Network Manager is still undergoing substantial development, I'll make these comments in hopes of expanding thinking on the matter. To wit:
It's already got the basics present but artificially limits flexibility and should be improved. Note that it already has to perform the boolean check of whether or not the zone happens to be called "trusted," so it would make more sense to have "trusted" just be a single-bit attribute of all zones. This would permit permissions to be either additive or subtractive; if the bit is zero, start from the premise that nothing is permitted and then list exceptions, or if set use the premise that all is permitted and then list exceptions. This is the way better-engineered (typically large), sophisticated software packages do things, like, say The BigSur System, for example, which provides for exactly this kind of security logic - either additive or reductive; you either grant all and then remove explicitly, or grant no privileges and then add in a few. It's far faster for system management and easier to understand rather than have an odd-man-out exception like the zone happens to be named 'trusted.'
But then, I have read that the original intention of Network Manager was to serve the less-sophisticated general audience as IP Tables was deemed far too hard to deal with. (And while IP Tables is / was challenging, the Network Manager people had to bow to its sophistication with "rich rules." ... But I digress.