Shorewall and Routing

Tom 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.


Routing vs. Firewalling.

One of the most misunderstood aspects of Shorewall is its relationship with routing. This article attempts to clear some of the fog that surrounds this issue.

As a general principle:

  1. Routing determines where packets are to be sent.

  2. Once routing determines where the packet is to go, the firewall (Shorewall) determines if the packet is allowed to go there.

There are ways that Shorewall can affect routing which are described in the following sections.

Routing and Netfilter

The following diagram shows the relationship between routing decisions and Netfilter.

The light blue boxes indicate where routing decisions are made. Upon exit from one of these boxes, if the packet is being sent to another system then the interface and the next hop have been uniquely determined.

The green boxes show where Netfilter processing takes place (as directed by Shorewall). You will notice that there are two different paths through this maze, depending on where the packet originates. We will look at each of these separately.

Packets Entering the Firewall from Outside

When a packet arrives from outside, it first undergoes Netfilter PREROUTING processing. In Shorewall terms:

  1. Packets may be marked using entries in the /etc/shorewall/mangle (/etc/shorewall/tcrules) file. Entries in that file containing ":P" in the mark column are applied here as are rules that default to the MARK_IN_FORWARD_CHAIN=No setting in /etc/shorewall/shorewall.conf. These marks may be used to specify that the packet should be routed using an alternate routing table; see the Shorewall Squid documentation for examples.


    Marking packets then using the fwmark selector in your "ip rule add" commands should NOT be your first choice. In most cases, you can use the from or dev selector instead.

  2. The destination IP address may be rewritten as a consequence of:

    • DNAT[-] rules.

    • REDIRECT[-] rules.

    • Entries in /etc/shorewall/nat.

So the only influence that Shorewall has over where these packets go is via NAT or by marking them so that they may be routed using an alternate routing table.

Packets Originating on the Firewall

Processing of packets that originate on the firewall itself are initially routed using the default routing table then passed through the OUTPUT chains. Shorewall can influence what happens here:

  1. Packets may be marked using entries in the /etc/shorewall/mangle (/etc/shorewall/tcrules) file (rules with "$FW" in the SOURCE column). These marks may be used to specify that the packet should be re-routed using an alternate routing table.

  2. The destination IP address may be rewritten as a consequence of:

    • DNAT[-] rules that specify $FW as the SOURCE.

    • Entries in /etc/shorewall/nat that have "Yes" in LOCAL column.

So again in this case, the only influence that Shorewall has over the packet destination is NAT or marking.

Alternate Routing Table Configuration

The Shorewall 2.x Shorewall Squid documentation shows how alternate routing tables can be created and used. That documentation shows how you can use logic in /etc/shorewall/init to create and populate an alternate table and to add a routing rule for its use. It is fine to use that technique so long as you understand that you are basically just using the Shorewall init script (/etc/init.d/shorewall) to configure your alternate routing table at boot time and that other than as described in the previous section, there is no connection between Shorewall and routing when using Shorewall versions prior to 2.3.2.

Routing and Proxy ARP

There is one instance where Shorewall creates main routing table entries. When an entry in /etc/shorewall/proxyarp contains "No" in the HAVEROUTE column then Shorewall will create a host route to the IP address listed in the ADDRESS column through the interface named in the INTERFACE column. This is the only case where Shorewall directly manipulates the main routing table.



#ADDRESS        INTERFACE       EXTERNAL        HAVEROUTE       PERSISTENT eth1            eth0            No

The above entry will cause Shorewall to execute the following command:

ip route add dev eth1

Multiple Internet Connection Support in Shorewall 2.4.2 and Later

Beginning with Shorewall 2.3.2, support is included for multiple Internet connections. If you wish to use this feature, we recommend strongly that you upgrade to version 2.4.2 or later.

Shorewall multi-ISP support is now covered in a separate article.


Frequently Used Articles

- FAQs - IPv4 Manpages - IPv6 Manpages - Configuration File Basics - Beginner Documentation - Troubleshooting

Shorewall 4.0/4.2 Documentation

Current HOWTOs and Other Articles

- 6to4 and 6in4 Tunnels - Accounting - Actions - Aliased (virtual) Interfaces (e.g., eth0:0) - Anatomy of Shorewall - Anti-Spoofing Measures - AUDIT Target support - Bandwidth Control - Blacklisting/Whitelisting - Bridge/Firewall - Building Shorewall from GIT - Commands - Compiled Programs - Configuration File Basics - DHCP - DNAT - Dynamic Zones - ECN Disabling by host or subnet - Events - Extension Scripts - Fallback/Uninstall - FAQs - Features - Fool's Firewall - Forwarding Traffic on the Same Interface - FTP and Shorewall - Helpers/Helper Modules - Installation/Upgrade - IPP2P - IPSEC - Ipsets - IPv6 Support - ISO 3661 Country Codes - Kazaa Filtering - Kernel Configuration - KVM (Kernel-mode Virtual Machine) - Limiting Connection Rates - Linux Containers (LXC) - Linux-vserver - Logging - Macros - MAC Verification - Manpages (IPv4) (IPv6) - Manual Chains - Masquerading - Multiple Internet Connections from a Single Firewall - Multiple Zones Through One Interface - My Shorewall Configuration - Netfilter Overview - Network Mapping - No firewalling of traffic between bridge port - One-to-one NAT - Operating Shorewall - OpenVPN - OpenVZ - Packet Marking - Packet Processing in a Shorewall-based Firewall - 'Ping' Management - Port Forwarding - Port Information - Port Knocking (deprecated) - Port Knocking, Auto Blacklisting and Other Uses of the 'Recent Match' - PPTP - Proxy ARP - QuickStart Guides - Release Model - Requirements - Routing and Shorewall - Routing on One Interface - Samba - Shorewall Events - Shorewall Init - Shorewall Lite - Shorewall on a Laptop - Shorewall Perl - Shorewall Setup Guide - SMB - SNAT - Split DNS the Easy Way - Squid with Shorewall - Starting/stopping the Firewall - Static (one-to-one) NAT - Support - Tips and Hints - Traffic Shaping/QOS - Simple - Traffic Shaping/QOS - Complex - Transparent Proxy - UPnP - Upgrade Issues - Upgrading to Shorewall 4.4 (Upgrading Debian Lenny to Squeeze) - VPN - VPN Passthrough - White List Creation - Xen - Shorewall in a Bridged Xen DomU - Xen - Shorewall in Routed Xen Dom0

Top of Page