Tom Eastep 2004-03-06 2004 Thomas M. Eastep Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.

Systems where Shorewall runs normally function as routers. In the context of the Open System Interconnect (OSI) reference model, a router operates at layer 3. Beginning with Shorewall version 2.0.1, Shorewall may also be deployed on a GNU Linux System that acts as a bridge. Bridges are layer-2 devices in the OSI model (think of a bridge as an ethernet switch). Some differences between routers and bridges are: Routers determine packet destination based on the destination IP address while bridges route traffic based on the destination MAC address in the ethernet frame. As a consequence of the first difference, routers can be connected to more than one IP network while a bridge may be part of only a single network. A router cannot forward broadcast packets while a bridge can.

In order to use Shorewall with a bridging firewall, your kernel must meet the following requirements: It must contain bridge support (CONFIG_BRIDGE=m or CONFIG_BRIDGE=y). It must contain Netfilter physdev match support (CONFIG_IP_NF_MATCH_PHYSDEV=m or CONFIG_IP_NF_MATCH_PHYSDEV=y). Physdev match is available in the 2.6 kernel series but must be patched into the 2.4 kernels (see http://bridge.sf.net). Your iptables must contain physdev match support. iptables 1.2.9 and later contain this support. You must have the bridge utilities (bridge-utils) package installed. You must also be running Shorewall 2.0.1 or later (users running Shorewall 2.0.0-RC* or Shorewall-2.0.0 may find the necessary updated files at http://shorewall.net/pub/shorewall/Bridging).

The following diagram shows a typical application of a bridge/firewall. There is already an existing router in place whose internal interface supports a network and you want to insert a firewall between the router and the systems in the local network. In the example shown, the network uses RFC 1918 addresses but that is not a requirement; the bridge would work exactly the same if public IP addresses were used (remember that the bridge doesn't deal with IP addresses). There are a several key differences in this setup and a normal Shorewall configuration: The Shorewall system (the Bridge/Firewall) has only a single IP address even though it has two ethernet interfaces! The IP address is configured on the bridge itself rather than on either of the network cards. The systems connected to the LAN are configured with the router's IP address (192.168.1.254 in the above diagram) as their default gateway. traceroute doesn't detect the Bridge/Firewall as an intermediate router. If the router runs a DHCP server, the hosts connected to the LAN can use that server without having dhcrelay running on the Bridge/Firewall. There are other possibilities here -- there could be a hub or switch between the router and the Bridge/Firewall and there could be other systems connected to that switch. All of the systems on the local side of the router would still be configured with IP addresses in 192.168.1.0/24.

Configuring the bridge itself is quite simple and used the brctl utility from the bridge-utils package. Bridge configuration information may be found at http://bridge.sf.net. Unfortunately, Linux distributions don't have good bridge configuration tools and the network configuration GUIs don't detect the presence of bridge devices. You may refer to my configuration files for an example of configuring a bridge at system boot under SuSE. Here is an excerpt from a Debian /etc/network/interfaces file for a bridge: auto br0 iface br0 inet static address 192.168.1.253 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 pre-up /sbin/ip link set eth0 up pre-up /sbin/ip link set eth1 up pre-up /usr/sbin/brctl addbr br0 pre-up /usr/sbin/brctl addif br0 eth0 pre-up /usr/sbin/brctl addif br0 eth1 gateway:/etc/network# While it is not a requirement to give the bridge an IP address, doing so allows the bridge/firewall to access other systems and allows the bridge/firewall to be managed remotely. I have not tested Shorewall with a bridge configured without an IP address so if you try it and it doesn't work do not be surprised.

Bridging in Shorewall is enabled using the BRIDGING option in /etc/shorewall/shorewall.conf: BRIDGING=Yes In the scenario pictured above, there would probably be two zones defined -- one for the internet and one for the local LAN so in /etc/shorewall/zones: #ZONE DISPLAY COMMENTS net Net Internet loc Local Local networks #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE A conventional two-zone policy file is appropriate here — /etc/shorewall/policy: #SOURCE DEST POLICY LOG LIMIT:BURST loc net ACCEPT net all DROP info all all REJECT info #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE Only the bridge device itself is configured with an IP address so only that device is defined to Shorewall in /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS - br0 192.168.1.255 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE The zones are defined using the /etc/shorewall/hosts file. Assuming that the router is connected to eth0 and the switch to eth1: #ZONE HOST(S) OPTIONS net br0:eth0 loc br0:eth1 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE When Shorewall is stopped, you want to allow only local traffic through the bridge — /etc/shorewall/routestopped: #INTERFACE HOST(S) OPTIONS br0 192.168.1.0/24 routeback #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE The /etc/shorewall/rules file from the two-interface sample is a good place to start for defining a set of firewall rules.

A system running Shorewall doesn't have to be exclusively a bridge or a router -- it can act as both. Here's an example: This is basically the same setup as shown in the Shorewall Setup Guide with the exception that the DMZ is bridged rather than using Proxy ARP. Changes in the configuration shown in the Setup Guide are as follows: The /etc/shorewall/proxyarp file is empty in this confiiguration. The /etc/shorewall/interfaces file is as follows:#ZONE INTERFACE BROADCAST OPTIONS - br0 detect rfc1918,routefilter loc eth1 detect The /etc/shorewall/hosts file would have: #ZONE HOSTS OPTIONS net br0:eth0 dmz br0:eth2

Bridging doesn' t work with some wireless cards — see http://bridge.sf.net.