Firewall Structure

Shorewall views the network in which it is running as a set of zones. Shorewall itself defines exactly one zone called "fw" which refers to the firewall system itself . The /etc/shorewall/zones file is used to define additional zones and the example file provided with Shorewall defines the zones:

net -- the (untrusted) internet.
dmz - systems that must be accessible from the internet and from the local network. These systems cannot be trusted completely since their servers may have been compromised through a security exploit.
loc - systems in your local network(s). These systems must be protected from the internet and from the DMZ and in some cases, from each other.

Note: You can specify the name of the firewall zone. For ease of description in this documentation, it is assumed that the firewall zone is named "fw".

It can't be stressed enough that with the exception of the firewall zone, Shorewall itself attaches no meaning to zone names. Zone names are simply labels used to refer to a collection of network hosts.

While zones are normally disjoint (no two zones have a host in common), there are cases where nested or overlapping zone definitions are appropriate.

For a general picture of how packets traverse a Netfilter firewall, see http://www.netfilter.org/documentation/tutorials/blueflux/iptables-tutorial.html#TRAVERSINGOFTABLES.

Packets entering the firewall first pass through the mangle table's PREROUTING chain (you can see the mangle table by typing "shorewall show mangle"). If the packet entered through an interface that has the norfc1918 option, then the packet is sent down the man1918 which will drop the packet if its destination IP address is reserved (as specified in the /etc/shorewall/rfc1918 file). Next the packet passes through the pretos chain to set its TOS field as specified in the /etc/shorewall/tos file. Finally, if traffic control/shaping is being used, the packet is sent through the tcpre chain to be marked for later use in policy routing or traffic control.

Next, if the packet isn't part of an established connection, it passes through the nat table's PREROUTING chain (you can see the nat table by typing "shorewall show nat"). If you are doing both static nat and port forwarding, the order in which chains are traversed is dependent on the setting of NAT_BEFORE_RULES in shorewall.conf. If NAT_BEFORE_RULES is on then packets will ender a chain called interface_in where interface is the name of the interface on which the packet entered. Here it's destination IP is compared to each of the EXTERNAL IP addresses from /etc/shorewall/nat that correspond to this interface; if there is a match, DNAT is applied and the packet header is modified to the IP in the INTERNAL column of the nat file record. If the destination address doesn't match any of the rules in the interface_in chain then the packet enters a chain called sourcezone_dnat where sourcezone is the source zone of the packet. There it is compared for a match against each of the DNAT records in the rules file that specify sourcezone as the source zone. If a match is found, the destination IP address (and possibly the destination port) is modified based on the rule matched. If NAT_BEFORE_RULES is off, then the order of traversal of the interface_in and sourcezone_dnat is reversed.

Traffic is next sent to an input chain in the mail Netfilter table (called 'filter'). If the traffic is destined for the firewall itself, the name of the input chain is formed by appending "_in" to the interface name. So traffic on eth0 destined for the firewall will enter a chain called eth0_in. The input chain for traffic that will be routed to another system is formed by appending "_fwd" to the interface name. So traffic from eth1 that is going to be forwarded enters a chain called eth1_fwd. Interfaces described with the wild-card character ("+") in /etc/shorewall/interfaces, share input chains. if ppp+ appears in /etc/shorewall/interfaces then all PPP interfaces (ppp0, ppp1, ...) will share the input chains ppp_in and ppp_fwd. In other words, "+" is deleted from the name before forming the input chain names.

While the use of input chains may seem wasteful in simple environments, in complex setups it substantially reduces the number of rules that each packet must traverse.

Traffic directed from a zone to the firewall itself is sent through a chain named <zone name>2fw. For example, traffic inbound from the internet and addressed to the firewall is sent through a chain named net2fw. Similarly, traffic originating in the firewall and being sent to a host in a given zone is sent through a chain named fw2<zone name>. For example, traffic originating in the firewall and destined for a host in the local network is sent through a chain named fw2loc.

Traffic being forwarded between two zones (or from one interface to a zone to another interface to that zone) is sent through a chain named <source zone>2 <destination zone>. So for example, traffic originating in a local system and destined for a remote web server is sent through chain loc2net. This chain is referred to as the canonical chain from <source zone> to <destination zone>. Any destination NAT will have occurred before the packet traverses one of these chains so rules in /etc/shorewall/rules should be expressed in terms of the destination system's real IP address as opposed to its apparent external address. Similarly, source NAT will occur after the packet has traversed the appropriate forwarding chain so the rules again will be expressed using the source system's real IP address.

For each record in the /etc/shorewall/policy file, a chain is created. Policies in that file are expressed in terms of a source zone and destination zone where these zones may be a zone defined in /etc/shorewall/zones, "fw" or "all". Policies specifying the pseudo-zone "all" matches all defined zones and "fw". These chains are referred to as Policy Chains. Notice that for an ordered pair of zones (za,zb), the canonical chain (za2zb) may also be the policy chain for the pair or the policy chain may be a different chain (za2all, for example). Packets from one zone to another will traverse chains as follows:

If the canonical chain exists, packets first traverse that chain.
If the canonical chain and policy chain are different and the packet does not match a rule in the canonical chain, it then is sent to the policy chain.
If the canonical chain does not exist, packets are sent immediately to the policy chain.

The canonical chain from zone za to zone zb will be created only if there are exception rules defined in /etc/shorewall/rules for packets going from za to zb.

Shorewall is built on top of the Netfilter kernel facility. Netfilter implements connection tracking function that allow what is often referred to as "statefull inspection" of packets. This statefull property allows firewall rules to be defined in terms of "connections" rather than in terms of "packets". With Shorewall, you:

Identify the client's zone.
Identify the server's zone.
If the POLICY from the client's zone to the server's zone is what you want for this client/server pair, you need do nothing further.
If the POLICY is not what you want, then you must add a rule. That rule is expressed in terms of the client's zone and the server's zone.

Just because connections of a particular type are allowed between zone A and the firewall and are also allowed between the firewall and zone B DOES NOT mean that these connections are allowed between zone A and zone B. It rather means that you can have a proxy running on the firewall that accepts a connection from zone A and then establishes its own separate connection from the firewall to zone B.

If you adopt the default policy of ACCEPT from the local zone to the internet zone and you are having problems connecting from a local client to an internet server, adding a rule won't help (see point 3 above).

Last modified 8/22/2002 - Tom Eastep