4

I installed Fedora on this one machine which is EXCLUSIVELY a gateway / firewall system.

Following installation, I ran 'yum upgrade', and so it should be up to the very latest Fedora 21 - I'm a little behind on purpose (not Fedora 22) specifically so that any problems are hopefully fixed (and now realize MAYBE I should have gone for Fedora 20?!)...

As soon as I got it up, I configured the two NICs in the box with their respective IP addresses, rebooted, confirmed they were fine, and began the "firewall" setup. First, I ran:

# firewall-cmd --list-all-zones

I confirmed that the names of the interfaces that firewalld is using are consistent with the other tools (unlike past versions of Fedora, such as 19 - see FC19 FirewallD debugging help requested: ports not forwarding )

To put the interfaces into the correct zones, I then ran:

firewall-cmd --permanent --zone=external --change-interface=enp2s0
firewall-cmd --permanent --zone=internal --change-interface=enp5s4

..and went on to try and set up port forwarding, etc. There are a couple of steps, such as opening up the port, then forwarding it. However NONE of that worked. After some digging, I found this article, dated only a few days ago, so I figured it's very current - http://www.certdepot.net/rhel7-get-started-firewalld/ - and followed its advice to edit /etc/sysctl.conf and add a line reading net.ipv4.ip_forward=1 and activate it with # sysctl -p, however, unhappily, things actually went "backwards"...

Previously, attempted connections to a forwarded port were hanging but now they were returning:

ssh: connect to host 167.101.97.2 port 6543: No route to host

So, I attempted to restore things to normal by UN-DOING the port-forwards and the edits to sysctl.conf, but things did NOT go back to "original!"

Incredulously, I rebooted, with everything set up as back to the default, just installed condition as I could - except for those zone changes; what harm could THEY do?! But when the system came back up, THE INTERFACES HAD GONE BACK TO THE DEFAULT ZONE!

I then tried it all over again. Nope! The interfaces STAY IN THE "FedoraServer" zone following reboot NO MATTER WHAT I DO. I've tried the --permanent in several different positions in the command line. Every time the response is "success", and yet, every time the result is it doesn't survive a reboot, even if that's the ONLY thing done on the system between reboots.

...It's enough to shake a person's loyalty to their (otherwise) favorite Linux distribution! ...Don't let me tell you what I really think!

OK, SURELY this was tested; how's this done? (YES, I'd like to know about the port forwarding, but here I'm ONLY asking about the zone changes for interfaces surviving reboot.)

ADDITIONAL DATA:

So, I got the idea that MAYBE it was NetworkManager getting in the way, as it has often done in the past. However, none of my efforts there were fruitful. The first effort was to simply set NM_CONTROLLED="no" in the interfaces' files in /etc/sysconfig/network-scripts but that left the system with NO interfaces!

I then had to go back into my past to remember it was "network.service" that was present before and thankfully it was already installed. So, I ran:

systemctl disable NetworkManager.service
systemctl enable network.service

And the interfaces were then available. However, after reboot - AND ensuring the requisite firewall-cmd commands were executed (see above) - unfortunately, it again didn't work.

I then tried changing the NM_CONTROLLED values to "no", but that didn't work either.

Community
  • 1
Richard T
  • 1,130
  • 11
  • 26
  • For something that's _not_ going to be a host server, like a router/firewall, I would start with a "Minimal" installation rather than a "Fedora Server" installation. You use the same installation media for this. And it will cut out a lot of other stuff you don't need. – Michael Hampton Apr 18 '15 at 21:41
  • @MichaelHampton ...I was unaware, thanks, good suggestion. – Richard T Apr 18 '15 at 23:43
  • In particular, with the Minimal installation, you don't get a FedoraServer firewall zone. – Michael Hampton Apr 19 '15 at 00:39
  • 1
    This is not the case of "Server" install, I've confirmed this on Minimal Install of RHEL 7.1. In fact `man firewall-cmd` says that `--change interface` is internal function and you should use ZONE=external as mattdm answered. – kubanczyk Jun 09 '15 at 11:31

2 Answers2

5

I'm not sure about the firewalld command to do so, but you can change the zone in the ifcfg files in /etc/sysconfig/network-scripts — edit ifcfg-enp2s0 and ifcfg-enp5s4 and add ZONE=external and ZONE=internal, respectively.

mattdm
  • 6,550
  • 1
  • 25
  • 48
  • 1
    `firewall-config`, the graphical alternative to `firewall-cmd`, actually adds `ZONE` to the `network-scripts` files. Makes me wonder why `firewall-cmd` does not? – sourcenouveau Aug 19 '15 at 12:30
  • `firewall-cmd`adds the interfaces to the zones configuration files actually, which is more reliable when disbling Networkmanager – Abel Jan 08 '18 at 13:28
0

Another solution in this post : Cant keep interfaces in assigned zones, Centos7

Tested in my environement and working properly

Abel
  • 322
  • 3
  • 13
  • Actually, I've just tested after executing an update, and the bug in `Networkmanager` that was causing this behavior seams to be solved. – Abel Jan 08 '18 at 13:39