Routing on One Interface

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.

2013/12/27


Caution

This article applies to Shorewall 4.3 and later. If you are running a version of Shorewall earlier than Shorewall 4.3.5 then please see the documentation for that release.

Introduction

While most configurations can be handled with each of the firewall's network interfaces assigned to a single zone, there are cases where you will want to divide the hosts accessed through an interface between two or more zones.

  • The interface has multiple addresses on multiple subnetworks. This case is covered in the Aliased Interface documentation.

  • You are using some form of NAT and want to access a server by its external IP address from the same LAN segment. This is covered in FAQs 2 and 2a.

  • There are routers accessible through the interface and you want to treat the networks accessed through that router as a separate zone.

  • Some of the hosts accessed through an interface have significantly different firewalling requirements from the others so you want to assign them to a different zone.

The key points to keep in mind when setting up multiple zones per interface are:

  • Shorewall generates rules for zones in the order that the zone declarations appear in /etc/shorewall/zones unless you modify the processing order using the explicit child-zone:parent-zone syntax, in which case the child zone rules are generated first.

  • The order of entries in /etc/shorewall/hosts is immaterial as far as the generated rule set is concerned.

These examples use the local zone but the same technique works for any zone. Remember that Shorewall doesn't have any conceptual knowledge of Internet, Local, or DMZ so all zones except the firewall itself ($FW) are the same as far as Shorewall is concerned. Also, the examples use private (RFC 1918) addresses but public IP addresses can be used in exactly the same way.

Router in the Local Zone

Here is an example of a router in the local zone.

Note

the box called Router could be a VPN server or other such device; from the point of view of this discussion, it makes no difference.

Can You Use the Standard Configuration?

In many cases, the standard two-interface Shorewall setup will work fine in this configuration. It will work if:

  • The firewall requirements to/from the Internet are the same for 192.168.1.0/24 and 192.168.2.0/24.

  • The hosts in 192.168.1.0/24 know that the route to 192.168.2.0/24 is through the router.

All you have to do on the firewall is add a route to 192.168.2.0/24 through the router and restart Shorewall.

Will One Zone be Enough?

If the firewalling requirements for the two local networks is the same but the hosts in 192.168.1.0/24 don't know how to route to 192.168.2.0/24 then you need to configure the firewall slightly differently. This type of configuration is rather stupid from an IP networking point of view but it is sometimes necessary because you simply don't want to have to reconfigure all of the hosts in 192.168.1.0/24 to add a persistent route to 192.168.2.0/24. On the firewall:

  1. Add a route to 192.168.2.0/24 through the Router.

  2. Set the routeback option for eth1 (the local firewall interface) in /etc/shorewall/interfaces.

  3. Restart Shorewall.

I Need Separate Zones

If you need to make 192.168.2.0/24 into its own zone, you can do it one of two ways; Nested Zones or Parallel Zones.

Nested Zones

You can define one zone (called it loc) as being all hosts connected to eth1 and a second zone loc1 (192.168.2.0/24) as a sub-zone.

Note

The Router in the above diagram is assumed to NOT be doing SNAT for the hosts in the 192.168.2.0/24 network.

The advantage of this approach is that the zone loc1 can use CONTINUE policies such that if a connection request doesn't match a loc1 rule, it will be matched against the loc rules. For example, if your loc1->net policy is CONTINUE then if a connection request from loc1 to the Internet doesn't match any rules for loc1->net then it will be checked against the loc->net rules.

/etc/shorewall/zones

#ZONE       TYPE      OPTIONS
loc         ipv4
loc1:loc    ipv4

Note

the Parent zone (loc) is defined first then the sub-zone (loc1) is defined using the special syntax shown.

/etc/shorewall/interfaces

#ZONE               INTERFACE           BROADCAST               OPTIONS
loc                 eth1                -

/etc/shorewall/hosts

#ZONE               HOSTS                        OPTIONS
loc1                eth1:192.168.2.0/24          -

If you don't need Shorewall to set up infrastructure to route traffic between loc and loc1, add these two policies.

/etc/shorewall/policy

#SOURCE             DEST                 POLICY
loc                 loc1                 NONE
loc1                loc                  NONE

Parallel Zones

You define both zones in the /etc/shorewall/hosts file to create two disjoint zones.

Note

The Router in the above diagram is assumed to NOT be doing SNAT for the hosts in the 192.168.2.0/24 network.

/etc/shorewall/zones

#ZONE       TYPE      OPTIONS
loc1        ipv4
loc2        ipv4

/etc/shorewall/interfaces

#ZONE               INTERFACE           BROADCAST
-                   eth1                192.168.1.255

/etc/shorewall/hosts

#ZONE               HOSTS                    OPTIONS
loc1                eth1:192.168.1.0/24      -
loc2                eth1:192.168.2.0/24      -

You don't need Shorewall to set up infrastructure to route traffic between loc and loc1, so add these two policies:

#SOURCE             DEST                 POLICY
loc1                loc2                 NONE
loc2                loc1                 NONE

Some Hosts have Special Firewalling Requirements

There are cases where a subset of the addresses associated with an interface need special handling. Here's an example.

In this example, addresses 192.168.1.8 - 192.168.1.15 (192.168.1.8/29) are to be treated as their own zone (loc1).

/etc/shorewall/zones

#ZONE       TYPE      OPTIONS
loc         ipv4
loc1:loc    ipv4

/etc/shorewall/interfaces

#ZONE               INTERFACE           BROADCAST
loc                 eth1                -

/etc/shorewall/hosts

#ZONE               HOSTS                  OPTIONS
loc1                eth1:192.168.1.8/29    broadcast

The broadcast option causes limited broadcasts (destination IP address 255.255.255.255) to be checked against the loc1 zone. If that zone allows the packet, then of course it will be seen by the mempers of loc that are outside of loc1 as well. If the broadcast is not specifically DROPped by the fw->loc1 rules then it will also be checked against the fw->loc rules, even if there is a DROP or REJECT fw->loc1 policy.

You probably don't want Shorewall to set up infrastructure to route traffic between loc and loc1 so you should add these two policies.

/etc/shorewall/policy

#SOURCE             DEST                 POLICY
loc                 loc1                 NONE
loc1                loc                  NONE

One-armed Router

Nested zones may also be used to configure a one-armed router (I don't call it a firewall because it is very insecure. For example, if you connect to the Internet via cable modem, your next door neighbor has full access to your local systems as does everyone else connected to the same cable modem head-end controller). Here eth0 is configured with both a public IP address and an RFC 1918 address (More on that topic may be found here). Hosts in the loc zone are configured with their default gateway set to the Shorewall router's RFC1918 address.

/etc/shorewall/zones

#ZONE       TYPE      OPTIONS
net         ipv4
loc:net     ipv4

/etc/shorewall/interfaces

#ZONE               INTERFACE           BROADCAST      OPTIONS
net                 eth0                detect         routefilter

/etc/shorewall/hosts

#ZONE               HOSTS                              OPTIONS
loc                 eth0:192.168.1.0/24                maclist

/etc/shorewall/masq

#INTERFACE              SOURCE          ADDRESS
eth0:!192.168.1.0/24    192.168.1.0/24

Note that the maclist option is specified in /etc/shorewall/interfaces. This is to help protect your router from unauthorized access by your friends and neighbors. Start without maclist then add it and configure your /etc/shorewall/maclist file when everything else is working.

Documentation


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