Yes, I understand that the predefined zones are just named presets meant to be generic and for that exact reason I had to create own named zone as explained.
To get back to the original question:
Do I understand correctly that the only way to enable ipv4 forwarding for specific interface(s) is to explicitly disable it for each and every other interface OR is there a way to have ipv4 forwarding disabled by default but enable it explicitly for the desired interface(s) only?
And another one:
Is it enough to simply set ‘FirewallBackend=nftables’ in /etc/firewalld/firewalld.conf or do I need to also modify the rules (direct or other) so that nftables is used instead of iptables?
BTW I don’t know why but on Leap 15 there is no predefined ‘FirewallBackend’ in the template conf file. I see it only on Tumbleweed (on another machine). Does it mean it is not supported on Leap?
I’ll admit I haven’t taken the time to learn the entire firewalld approach starting with the foundation and what goes on top, but there is plenty that can be assumed based on use and observation.
I’d also recommend you take 10 minutes to look up and read what nftables is, that it’s not a total replacement for iptables, ebtables but a less complex, more intuitive syntax for configuration.
So, answering your questions directly…
IP forwarding hasn’t changed much with nftables.
IP forwarding is still enabled by creation of a FORWARDING rule, and without a rule, the forwarding doesn’t happen.
No, you should not need to disable forwarding explicitly <unless> you already set a rule to enable on all interface first.
Any kind of forwarding does not exist by default, you have to first create a rule that enables.
If you’re talking about using firewalld, nftables appears to be used by default to create rules.
It’s only when you decide not to use a tool like firewalld to create your firewall rules that you might need to declare your use of nftables somewhere, and that would probably depend on what you’re doing.
If you’re totally lost on what you’re doing,
I’d recommend you crack open a book (or a guide published on the Internet) on firewalld.
There’s nothing like doing that to give yourself a good foundation to build upon instead of thrashing around.
I have read the whole documentation on firewalld.org before opening this thread but it doesn’t answer my questions.
I’d also recommend you take 10 minutes to look up and read what nftables is, that it’s not a total replacement for iptables, ebtables but a less complex, more intuitive syntax for configuration.
It’s on my long todo list
So, answering your questions directly…
You explain about firewalld. Perhaps I didn’t make myself clear: I am asking about sysctl.conf in conjunction with the initial post as arvidjaar’s explanation got me a little confused. It is still not clear to me how it should be approached (through whitelististing or blacklisting interaces).
If you’re talking about using firewalld, nftables appears to be used by default to create rules.
It’s only when you decide not to use a tool like firewalld to create your firewall rules that you might need to declare your use of nftables somewhere, and that would probably depend on what you’re doing.
Then why does FirewallBackend setting exist?
If you’re totally lost on what you’re doing,
I’d recommend you crack open a book (or a guide published on the Internet) on firewalld.
There’s nothing like doing that to give yourself a good foundation to build upon instead of thrashing around.
Surely if one reads some books and becomes an expert one wouldn’t need to ask. That’s the general answer to almost every technical question, isn’t it?
As I described in my earlier post,
/etc/sysctl.conf is one way to apply commands, so that those commands which normally aren’t persistent across reboots are applied on every boot.
You should also disregard everything in this thread about handcrafting config files like /etc/sysctl.conf if you instead use a tool like firewall-config.
Regarding your Q about “Firewallbackend,” it’s in the following firewalld documentation, it clearly states that is the setting that defines the method used to write your firewall rules
firewall-config is where I add the direct rules for forwarding. Still forwarding didn’t work without modifying sysctl.conf. And this makes sense because if ipv4 forwarding is disabled on kernel level - how could any forwarding possibly work? If that was possible I wouldn’t even need to open this thread as it would contradict the facts leading to the initial question. So I don’t quite understand your suggestion about disregarding any customization of sysctl.conf. firewall-config does not seem to take care of modifying that file automatically based on firewalld rules.
Regarding your Q about “Firewallbackend,” it’s in the following firewalld documentation, it clearly states that is the setting that defines the method used to write your firewall rules
Considering an older discussion about that, my own questions here and your latest reply I found that ‘Firewallbackend’ is a feature of version 0.6.0](Releases · firewalld/firewalld · GitHub). Right now on Leap 15.0 we have an older version:
so it is not clear which backend it uses or if it supports nftables at all. Scrolling the changelog on github and searching for ‘nftables’ shows no matches back to version 0.1.1. So one would logically assume it is not supported before 0.6.0.
First,
I’m a bit mystified that you’re having problems no one else has reported.
This suggests to me that you could’ve modified your system to the point that it no longer has its defaults. Unless you are able to restore your system to a known starting point I don’t know that the problems you describe are typical of what people should see.
You should also note that my earliest post with the RHEL reference pre-dates implementing firewalld, and already relies on the conntrack module to support forwarding without creating a rule in both directions. In other words, you already had broken functionality before you started looking at nftable rules. I have no idea how your system was broken, only that it was and possibly still is.
One thing I can be sure of…
If you are creating rules using firewall-config, you shouldn’t be handcrafting rules in directly in the underlying config files unless you really know what you’re doing. GUI tools are supposed to prevent these kinds of mistakes.
I can’t give you a sure answer about “FirewallBackend” at the moment, but it’s possible you’re misreading the changelog, it might also be possible that with firewalld 6.0 only the <default> was set to nftables, it’s possible that the setting existed before and indeed… A literal reading of your error says that the setting is missing and not configured. If a default was set, then the error would not happen (ie with 6.0), and before 6.0 the setting must be configured.
And,
When you check that box in the Masquerading tab… I suggest you read what it says that it creates the forwarding rule for you.
To demystify: I am not “having problems” and I am not “reporting”. I am asking how to do something. Just because you may have not seen anyone else asking about it doesn’t mean I have “broken my system”, so I don’t see why you assume non-facts. Considering arvidjaar’s replies everything works as expected. But it is not clear if and why the explicit blacklisting of forwarding for specific interfaces in sysctl.conf is the only approach to restrict forwarding to other specific ones. That’s what I was hoping to understand with my follow up questions.
One thing I can be sure of…
If you are creating rules using firewall-config, you shouldn’t be handcrafting rules in directly in the underlying config files unless you really know what you’re doing. GUI tools are supposed to prevent these kinds of mistakes.
What mistakes? The rules I pasted as part of /etc/firewalld/direct.xml were created using ‘firewall-cmd --direct --add-rule …’. That is explained in the very first link in my very first post. Adding them through firewall-config or through command line gives the same result. I have never said I had created the config through editing the xml file.
I can’t give you a sure answer about “FirewallBackend” at the moment, but it’s possible you’re misreading the changelog, it might also be possible that with firewalld 6.0 only the <default> was set to nftables, it’s possible that the setting existed before and indeed…
And,
When you check that box in the Masquerading tab… I suggest you read what it says that it creates the forwarding rule for you.
I have read it before starting this thread. That checkbox simply adds a <masquerade/> line to the xml file of the zone. It does not modify sysctl.conf to enable the kernel level ipv4 forwarding and without that there is no forwarding.
Well,
What can I say.
I just went ahead and set up a NAT router as I described in my earlier post…
I would like to correct that post by saying you should <omit> that last step to reload the firewalld daemon, that will reset to the permanent rules losing your runtime configuration.
But,
Otherwise…
When you follow the steps I described to set up a NAT router using firewall-config, it “just works.”
And, you can’t argue with success.
Don’t argue, just learn.
Set up your system as I described and <then> look at what is in your config files.
And, disregard <everything> else that’s in this Forum thread.
If it doesn’t work for you, then your system is broken in that the ordinary way to set up a NAT router won’t work, likely because of changes you made to your system.
Because I feel I’ve already provided the “best” and really only proper answer,
I’ll post this one more time regarding your issues about using sysctl…
firewall-config is a tool that can configure your firewall.
You can choose to configure your firewall other ways, but you should then make hard and clear choices about what you are doing and probably not mix methods.
iptables (or ebtables) still provides basic firewalling functionality even if you choose to use nftables.
You should think of nftables as an improved way of writing your firewall configuration, more stream-lined and better able to define complex instructions.
If you’re using firewalld, instructions and settings are written to configuration files.
Do not mix instructions in firewalld config files with iptables or ebtables commands by any method (which as I’ve noted can be on demand, in the /etc/sysctl file or written to /proc/sys/). There is no need and can only lead to confusion.
And, your insistence that /etc/sysctl.conf is necessary at all is unsupportable in many ways… ie. Not only have I shown that a NAT router can be set up without anything in /etc/sysctl.conf, if asked I could also invoke any commands you’d put in a /etc/sysctl.conf by other methods.
I haven’t looked at how firewalld zones are constructed, but people who handcraft iptables rules know that you begin with statements that set your defaults, like explicitly closing all ports by default. I don’t know if firewalld zone configurations do the same, it would be useful to research this point.
But, when you’re talking about forwarding rules (instead of ports), declaring or “blacklisting” shouldn’t be necessary. Forwarding can happen only if a rule supporting that particular function exists;. Unless there is some kind of rule that first enables all forwarding from everywhere to everywhere exists, it’s not necessary to over-ride anything… The functionality simply doesn’t exist by default.
Lastly,
Based on my successful NAT router configuration using firewall-config, it’s pretty obvious that when done correctly your FirewallBackend error isn’t thrown, so it’s very likely you’re mis-interpreting what is in the firewalld changelogs, and my interpretation is likely correct.
Yes, you are correct about that. Leap 15 is using firewalld 0.5.5, and that uses the traditional iptables (and family) backend. Now, firewalld (0.6 onwards) has support for nftables (a newer kernel subsystem) that replaces parts of netfilter, is more efficient and provides better throughput
However, none of this changes how forwarding is implemented with respect to firewalld from a user perspective.
Could you please share your firewalld config files and sysctl.conf net.* lines?
…]when done correctly your FirewallBackend error isn’t thrown, so it’s very likely you’re mis-interpreting what is in the firewalld changelogs, and my interpretation is likely correct.
That error mentioned in another thread was for another system (running Tumbleweed and hence newer firewalld version) and is unrelated to current discussion. I cross linked it just for the purpose of saying that ntftables and FirewallBackend are not supported on 0.5.5. Any attempt to use FirewallBackend in firewalld.conf on Leap 15 results in (journalctl):
However, none of this changes how forwarding is implemented with respect to firewalld from a user perspective.
Yes, I also understand it that way: that firewalld is like a higher level “wrapper” of the backend used depending on what is supported in the particula version.
The
/etc/sysctl.conf file contains only commented lines, so is empty.
The only configuration change of note is the following
cat /etc/firewalld/zones/public.xml<?xml version="1.0" encoding="utf-8"?>
<zone>
<short>Public</short>
<description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
<service name="dhcpv6-client"/>
<masquerade/>
</zone>
There is nothing noteworthy in /etc/firewalld/firewalld.conf
It should also be noted that the nftables package is not installed by default
So, in summary it appears that by default
firewalld configures iptables nowadays, not ebtables or nftables
About firewalld being a wrapper of the backend I have a clear idea. What is still not clear to me is about sysct.conf in relation to all that:
tsu2 claims that ‘net.ipv4.ip_forward = 1’ is not necessary. arvidjaar says the opposite. The facts I shared show that arvidjaar is right.
Also my earlier question: is there a way to “blacklist” by default all ipv4 forwarding and “whitelist” it only for a particular interface VS “whitelisting/enablinig” ipv4 forwarding globally and after that disabling it for specific interfaces (like arvidjaar suggested). That means: without relying on firewall rules which handle forwarding (or not), or at even higher level: on services listening to ports or not, but restricting it on lower (kernel) level, then build up on that only what is needed. I can’t find the answer to this in the documentation.
Exactly what I was saying.
The /etc/sysctl.conf file contains only commented lines, so is empty.
So, it appears taht forwarding is enabled on all interfaces, although if you actually test each interface, you’ll find that everything is blocked from the public interface (eth0). My guess is that is a natural and default configuration of masquerading.
I asked you to paste the output of the find command just to double check (not guess or assume) that we are talking about the same thing and it seems we are not. Anyway I played a little with your approach and it gives strange results. I did the following:
Enable masquerade for the ‘drop’ zone
Result: all “1” in find command’s output (like in your paste)
Disable masquerade for the ‘drop’ zone
Result: again all “1”. (I would expect the state to be restored as it was though)
rcnetwork restart && systemctl restart firewall
Result: “0” for eth1 and lo, all others “1”. Still not restored as it was.
Look at other zones. For ‘external’ masquerade was enabled. I disabled it and set runtime to permanent. Repeat step 3
Repeat step 2 (which disables masquerade for ‘drop’ zone)
Result: all “1”
All this is very weird. I would even say it looks buggy as firewalld:
creates states which it does not restore
enables forwarding for everything upon disabling of masquerade (which makes no sense as it is not necessary)
the created states persist even after restarting of network and firewalld services
That is not the controlled approach I am looking for and it doesn’t answer my questions, so I can’t ignore the whole thread in order to follow that.
although if you actually test each interface, you’ll find that everything is blocked from the public interface (eth0).
My own earlier tests show that only in the ‘drop’ zone everything is blocked by default. Other preset zones allow icmp or other things.
My guess is that is a natural and default configuration of masquerading.
I have no idea what this means. Enabling masquerade indeed matches the text below the “Masquerade zone” checkbox. However the rest of it behaves quite unpredictably.
If you’re going to try to configure your firewall using nfables,
Since firewall0-config might not yet support nftables (I’d still be curious what would happen if you try to set the backend to nftables)
Install nftables.rpm. It installs the User-mode tools and to my eye also installs the config xml files nftables uses. Since you say you didn’t install nftables, I wonder what’s happening on your machine.
I do appreciate your level of expertise and as you see I am not ignoring the extra info you provided. But the amount of discussion around your non-factual guesses and the RTFM-styled advise turned this thread into a TLDR, making it highly unlikely for someone who may know the answer to my actual questions to step in and share it. I find that quite unfortunate.
You embarked on doing something without installing the necessary prerequisites.
It’s my experience that if you don’t install basic building blocks to a solution, the results aren’t reliable.
So, in this case I don’t know if your stubborn refusal to install basic tools might have broken your use of the conntrack module(who knows?)
You were provided with an answer which while it works for you, is an antiquated solution. The difference in this case is probably minor and hard to exploit, but in any case I don’t think you understood that there is a current recommended option that supersedes what you are doing.
I’m not clear even on the purpose of your line of questioning and effort which is perhaps fundamental to the differences in your and my thought processes.
You seem to be stuck on blacklisting forwarding.
The point is that unless you can describe a scenario where that might be required to address something,
I just don’t see that what you’re asking about does anything to change the effectiveness of what the SUSE/openSUSE maintainers have provided you, no matter the version of firewalld, whether you use firewalld or SuSEfirewall2 or whether your firewall is configured using iptables, ebtables or nftables.
The following question should be fundamental to your line of inquiry…
What exact scenario or exploit are you seeking to address?
