SHOREWALL-NESTING(5)

📦
version 5.2.8 · 2 versions
  • 5.2.8 · alpine 3.22, alpine 3.23, alpine 3.24, debian bookworm, debian trixie, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking (latest)
  • 5.2.3.4 · ubuntu jammy
, in alpine 3.22, alpine 3.23, alpine 3.24, debian bookworm, debian trixie, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

💖 SHOREWALL-NESTING(5) — the nesting page, bestie 💖

okay so this is shorewall-nesting from section 5 of the manual — it lives under Configuration Files and it's all about nested zones in Shorewall. grab a snack, we're doing zones-inside-zones and it's honestly kind of iconic. 🦋

✨ NAME ✨

nesting — Shorewall Nested Zones 👑

🌸 SYNOPSIS 🌸

child-zone[:parent-zone[,parent-zone]...]

💅 DESCRIPTION 💅

So in shorewall-zones(5), a zone can be declared as a sub-zone of one or more other zones using that syntax up there. Like, the whole point.

  • The child-zone can not be the firewall zone, and it can not be a vserver zone. periodt.
  • The firewall zone can not show up as a parent zone — but lowkey, all vserver zones are handled as sub-zones of the firewall zone anyway, so there's that. ✨

Where zones are nested, the CONTINUE policy in shorewall-policy(5) lets hosts that live inside multiple zones get managed under the rules of all of those zones. it's giving "everyone gets a turn" energy. 🫶

🎀 EXAMPLE 🎀

/etc/shorewall/zones:

#ZONE    TYPE        OPTION
fw       firewall
net      ipv4
sam:net  ipv4
loc      ipv4

/etc/shorewall/interfaces:

#ZONE     INTERFACE     BROADCAST     OPTIONS
-         eth0          detect        dhcp,norfc1918
loc       eth1          detect

/etc/shorewall/hosts:

#ZONE     HOST(S)                     OPTIONS
net       eth0:0.0.0.0/0
sam       eth0:206.191.149.197

/etc/shorewall/policy:

#SOURCE      DEST        POLICY       LOG LEVEL
loc          net         ACCEPT
sam          all         CONTINUE
net          all         DROP         info
all          all         REJECT       info

The second entry up there says that when Sam is the client, connection requests should first be processed under rules where the source zone is sam, and if there's no match, then the connection request should be treated under rules where the source zone is net. 💫

Bestie, it is important that this policy be listed BEFORE the next policy (net to all). Do not skip this. 😭

You can have this policy generated for you automatically by using the IMPLICIT_CONTINUE option in shorewall.conf(5). slay, no manual labor required. 💅

Partial /etc/shorewall/rules:

#ACTION   SOURCE    DEST            PROTO    DPORT
...
DNAT      sam       loc:192.168.1.3 tcp      ssh
DNAT      net       loc:192.168.1.5 tcp      www
...

Given these two rules, Sam can connect to the firewall's internet interface with ssh and the connection request will be forwarded to 192.168.1.3. Like all hosts in the net zone, Sam can connect to the firewall's internet interface on TCP port 80 and the connection request will be forwarded to 192.168.1.5. The order of the rules is not significant. 🧚

Sometimes it's necessary to suppress port forwarding for a sub-zone. For example, suppose that all hosts can SSH to the firewall and be forwarded to 192.168.1.5 EXCEPT Sam. When Sam connects to the firewall's external IP, he should be connected to the firewall itself. Because of the way that Netfilter is constructed, this requires two rules as follows:

#ACTION   SOURCE    DEST            PROTO    DPORT
...
ACCEPT+   sam       $FW             tcp      ssh
DNAT      net       loc:192.168.1.3 tcp      ssh
...

The first rule allows Sam SSH access to the firewall. The second rule says that any clients from the net zone with the exception of those in the “sam” zone should have their connection port forwarded to 192.168.1.3. If you need to exclude more than one zone, simply use multiple ACCEPT+ rules. This technique also may be used when the ACTION is REDIRECT. 🔥

🦋 the wildcard interface situation 🦋

Care must be taken when nesting occurs as a result of the use of wildcard interfaces (interface names ends in '+'). ngl this is the part where things get spicy. 💀

Here's an example. /etc/shorewall/zones:

/etc/shorewall/interfaces:

#ZONE    INTERFACE      BROADCAST        OPTIONS
net      ppp0
loc      eth1
loc      ppp+
dmz      eth2

Because the net zone is declared before the loc zone, net is an implicit sub-zone of loc and in the absence of a net->... CONTINUE policy, traffic from the net zone will not be passed through loc->... rules. But DNAT and REDIRECT rules are an exception! 😱

  • DNAT and REDIRECT rules generate two Netfilter rules: a 'nat' table rule that rewrites the destination IP address and/or port number, and a 'filter' table rule that ACCEPTs the rewritten connection.
  • Policies only affect the 'filter' table.

As a consequence, the following rules will have unexpected behavior:

#ACTION     SOURCE               DEST      PROTO        DPORT
ACCEPT      net                  dmz       tcp          80
REDIRECT    loc                  3128      tcp          80

The second rule is intended to redirect local web requests to a proxy running on the firewall and listening on TCP port 3128. But the 'nat' part of that rule will cause all connection requests for TCP port 80 arriving on interface ppp+ (including ppp0!) to have their destination port rewritten to 3128. Hence, the web server running in the DMZ will be inaccessible from the web. 💀 rip.

The above problem can be corrected in several ways. 👇

The preferred way is to use the ifname pppd option to change the 'net' interface to something other than ppp0. That way, it won't match ppp+. 🎀

If you are running Shorewall version 4.1.4 or later, a second way is to simply make the nested zones explicit:

#ZONE    TYPE        OPTION
fw       firewall
loc      ipv4
net:loc  ipv4
dmz      ipv4
If you take this approach, be sure to set IMPLICIT_CONTINUE=No in shorewall.conf. no cap, don't forget this one. 🙈

When using other Shorewall versions, another way is to rewrite the DNAT rule (assume that the local zone is entirely within 192.168.2.0/23):

#ACTION     SOURCE                 DEST      PROTO      DPORT
ACCEPT      net                    dmz       tcp        80
REDIRECT    loc:192.168.2.0/23     3128      tcp        80

Another way is to restrict the definition of the loc zone:

/etc/shorewall/interfaces:

#ZONE    INTERFACE      BROADCAST        OPTIONS
net      ppp0
loc      eth1
-        ppp+
dmz      eth2

/etc/shorewall/hosts:

#ZONE    HOST(S)             OPTIONS
loc      ppp+:192.168.2.0/23

🌈 FILES 🌈

  • /etc/shorewall/zones
  • /etc/shorewall/interfaces
  • /etc/shorewall/hosts
  • /etc/shorewall/policy
  • /etc/shorewall/rules
  • /etc/shorewall6/zones
  • /etc/shorewall6/interfaces
  • /etc/shorewall6/hosts
  • /etc/shorewall6/policy
  • /etc/shorewall6/rules

👑 SEE ALSO 👑

shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-mangle(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)

💜 NOTES 💜

  1. shorewall-zones https://shorewall.org/manpages/shorewall-zones.html
  2. shorewall-policy https://shorewall.org/manpages/shorewall-policy.html
  3. shorewall.conf https://shorewall.org/manpages/shorewall.conf.html

okay bestie that's the whole page, we ate and left no crumbs. 🍓

this one came out of the Configuration Files corner, dated 09/24/2020, and it's filed under SHOREWALL-NESTING(5) — mwah, go forth and nest responsibly. 💖✨

📦 where this page comes from