Provided by: shorewall_4.4.26.1-1_all bug

NAME

       nesting - Shorewall Nested Zones

SYNOPSIS

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

DESCRIPTION

       In shorewall-zones[1](5), a zone may be declared to be a sub-zone of one or more other
       zones using the above syntax. The child-zone may be neither the firewall zone nor a
       vserver zone. The firewall zone may not appear as a parent zone, although all vserver
       zones are handled as sub-zones of the firewall zone.

       Where zones are nested, the CONTINUE policy in shorewall-policy[2](5) allows hosts that
       are within multiple zones to be managed under the rules of all of these zones.

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 above says that when Sam is the client, connection requests should first
       be processed under rules where the source zone is sam and if there is no match then the
       connection request should be treated under rules where the source zone is net. It is
       important that this policy be listed BEFORE the next policy (net to all). You can have
       this policy generated for you automatically by using the IMPLICIT_CONTINUE option in
       shorewall.conf[3](5).

       Partial /etc/shorewall/rules:

                   #ACTION   SOURCE    DEST            PROTO    DEST PORT(S)
                   ...
                   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 is 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    DEST PORT(S)
                   ...
                   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.

       Care must be taken when nesting occurs as a result of the use of wildcard interfaces
       (interface names ends in '+').

       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        DEST
                   #                                                       PORT(S)
                   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.

       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.

       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      DEST
                   #                                                       PORT(S)
                   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

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-route_rules(5), shorewall-routestopped(5), shorewall-rules(5),
       shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
       shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)

NOTES

        1. shorewall-zones
           http://www.shorewall.net/manpages/shorewall-zones.html

        2. shorewall-policy
           http://www.shorewall.net/manpages/shorewall-policy.html

        3. shorewall.conf
           http://www.shorewall.net/manpages/shorewall.conf.html

[FIXME: source]                             12/13/2011                       SHOREWALL-NESTING(5)