Bug 1198984 - firewalld: please improve documentation on using it on a RedHat/Fedora/CentOS router
Summary: firewalld: please improve documentation on using it on a RedHat/Fedora/CentOS...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora Documentation
Classification: Fedora
Component: firewall-guide
Version: devel
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Pete Travis
QA Contact: Fedora Docs QA
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-05 09:24 UTC by Răzvan Sandu
Modified: 2017-09-02 02:29 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-02 02:29:22 UTC


Attachments (Terms of Use)

Description Răzvan Sandu 2015-03-05 09:24:24 UTC
Hello, 

Description of problem:

Even using the rich-language feature, it is still rather difficult to figure out
how to use firewalld on a RedHat/Fedora/CentOS system that is used as a router (a "transparent" system).

That's because:

a. administrators will need *different* sets of rules/restrictions for access to the router itself and to the various services that run beyond the router (using or non using NAT).


b. It is not very clear how/where the predefined firewalld zones implement their policies (ACCEPT or DROP) and when these policies apply to traffic bounded *to* the router system or to traffic that *traverses* the router.

For example, an administrator needs an *easy* method to restrict VNC access *to* the router itself (INPUT), but may want free VNC access to some server located *behind* the router (FORWARD). In the second case, forwarding may (or may not) imply NAT, depending if he goes on the Internet via the external interface or simply goes in another LAN segment beyond the router.


c. It is not very clear how/where the predefined firewalld zones implement their trafic rules ( *exceptions* to ACCEPT or DROP default policies) and when these rules apply to traffic bounded *to* the router system or to traffic that *traverses* the router.


Additional info:


Even it is not dynamic, the Shorewall application (http://shorewall.net/) acts as a higher-level language over iptables, offering the same concepts of "zones" for interfaces. Much of its conceptual architecture is directly applicable ("portable") to firewalld, if accepted by developers.

Somewhat different from conceptual point of view, the "zones" are "levels of trust surrounding the router", including thr FW zone for the router itself.
(unlike firewalld, the shorewall zones have no "sources" or "services" embedded in them).

IPv4 and IPv6 zones are completely separated (they actually represent different levels of trust).

Administrators may directly define policies, i.e. allow *default* actions to be done when an packet travels from a zone to another (ACCEPT, REJECT). The most sane policy between any two zones is REJECT (with further exceptions defined as rules, see below).

Rules are *exceptions to policies* , explicitly defined (based on various criteria such as source IP, destination IP, ports, etc.)

Rules may be expressed via predefined (or customised) "macros" (which are the direct equivalent of firewalld's "services").

IPv4 and IPv6 policy and rules are completely separated (IMHO that's good, since the use of global IPv6 addresses pose completely different security problems than NATted & externally firewalled IPv4).


Best regards,
Răzvan

Comment 1 Pete Travis 2015-03-14 06:41:20 UTC
I'm going to move this over to the firewall guide, because you've raised good questions that I think it should expand on, and because https://bugzilla.redhat.com/show_bug.cgi?id=1101796 already exists.

Comment 2 Pete Travis 2017-09-02 02:29:22 UTC
Hello, this is still a good idea but noone has contributed the doc yet.  We have moved issues to live with the upstream sources at pagure.io, so I have created https://pagure.io/networking-guide/issue/2 to track it.


Note You need to log in before you can comment on or make changes to this bug.