Join Log in
Score:0
avatar Server

Networking issue with Fedora Server 38 as a firewall / gateway

ru flag
Richard T

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?!

460
1 + 5
djdomi avatar
za flag
djdomi
do you really want to solve the problem by using a own solution? why not using pfsense or similar?
0
Reply
Davidw avatar
in flag
Davidw
PFSense is a Linux Distro designed for use as a firewall/router.
0
Reply
ru flag
Richard T
@Davidw Thanks... I'll look into it someday but right now I have a system to get up ASAP. And I KNOW it's close. It's surely just one teeny-tiny-little thing I have yet to do?! ...I'm double checking hardware, too, and will try and bring up the downed system as well.
0
Reply
djdomi avatar
za flag
djdomi
the pfsense has the similar distribution you like to use and is running within 10 Minutes. moreover opens Ense and pfsense are well known in the business environment which I think you don't have or asking for due it looks for me like an home and enduser setup
0
Reply
ru flag
Richard T
@djdomi The use case is FAR more than just a gateway: I need to run nginx, apache's httpd, roundcube, postgres, and a host of other packages... It's NOT "10 minutes" unless ALL it's doing is networking! ...And BOTH the current systems are all installed already.
0
Reply
Score:0
avatar Server
ru flag
Richard T

It turns out that the system was blocking pass-through for all but the services dhcpv6-client, mdns, samba-client, and ssh as 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-cmd or nmcli command 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:

  1. put the interface in the "trusted" zone, or;

  2. 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;

  3. 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.

+ 1
djdomi avatar
za flag
djdomi
as i understood, he wants to use the same box as AiO eonderbox that should protect itself and it's services directly as moreover I pointed out it should also protect the lan heOnd itself. it's against most common practice to do so
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.