Republished with permission from WatchGuard Technologies, Inc.

WatchGuard


Routing and Your Firewall, Part 1

by David M. Piscitello, President, Core Competence, Inc.

The first line of defense between an organization's network and the Internet commonly begins with basic packet filters on perimeter routers. However, routers only filter one packet at a time, and many multi-packet exploits can bypass per-packet inspection capabilities. As organizations grow to appreciate how inadequate this defense is, they turn to firewalls. But if firewalls are inserted in network topologies without a complete reassessment of routing, intra- as well as internet communications can be disrupted. This article (and the next) may help you consider what it means from a routing perspective to drop a firewall into your network, and could help you stop a routing mistake before you make it.

Routing 101: The Fundamentals

Let's begin with a host attached to a LAN. When it is expected to forward a packet to or towards the destination specified in the packet, how does the host decide where to send it? The local host consults its routing table. You can view the routing table on a PC by using the MS-DOS command route print:

======================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 a0 c9 87 64 23 ...... Ethernet 10/100 + Modem 56 PC Card
0x3 ...08 00 46 02 22 f0 ...... Sony i.LINK(1394) Adapter
======================================================================
======================================================================
Active Routes:
        Network 
    Destination          Netmask         Gateway       Interface  Metric
        0.0.0.0          0.0.0.0   192.168.111.1   192.168.111.3     1
      127.0.0.0        255.0.0.0       127.0.0.1       127.0.0.1     1
 *192.168.111.0    255.255.255.0   192.168.111.3   192.168.111.3     1
  192.168.111.3  255.255.255.255       127.0.0.1       127.0.0.1     1
192.168.111.255  255.255.255.255   192.168.111.3   192.168.111.3     1
      224.0.0.0        224.0.0.0   192.168.111.3   192.168.111.3     1
255.255.255.255  255.255.255.255   192.168.111.3   192.168.111.3     1
Default Gateway:    192.168.111.1
========================================================================
Persistent Routes:
  None

The routing entry beginning with * indicates the local network. If the destination address is in the same subnet as the local host, then the host concludes that the destination is local (that is, somewhere on the host's own LAN). It now consults its Address Resolution Protocol (ARP) table for the Medium Access Control (MAC) address of the destination so that it can transmit the packet over the LAN. The MAC address is hard-coded by the manufacturer into a network interface card. It serves as the physical address of the card on your network. It's different from the IP address, which is configured by the user. IP addresses may change if the device's location changes, but the MAC address stays with the card. Use the MS-DOS command arp –a to view the ARP cache on your PC:

Interface: 192.168.111.3 on Interface 0x2
  Internet Address      Physical Address      Type
  192.168.111.1         00-90-7f-0f-d2-7d     dynamic 

Notice there is no entry for 192.168.111.2 (yet). ARP tables are dynamically established and routinely refreshed, using the Address Resolution Protocol.

ARP

ARP is a request-response protocol used to discover the MAC address that corresponds to a specified IP address. Let's look at the ARP sequence of events, as captured by the Ethereal LAN analyzer software:

Time        Source              Destination           Protocol Info
18.047226  00:a0:c9:87:64:23  ff:ff:ff:ff:ff:ff  ARP  Who has 192.168.111.2?
                                                      Tell 192.168.111.3
18.047641  00:e0:29:93:11:88  00:a0:c9:87:64:23  ARP  192.168.111.2 is at
                                                      00:e0:29:93:11:88

Here, an ARP request from a host (IP address 192.168.111.3 and Ethernet MAC address 00:a0:c9:87:64:23) needs the MAC address of 192.168.111.2. It sends an ARP request to the broadcast MAC address ff:ff:ff:ff:ff:ff:ff:ff, asking, "Who has IP address 192.168.111.2? Tell 192.168.111.3 at MAC address 00:a0:c9:87:64:23." All hosts listen for broadcast Ethernet packets. 192.168.111.2 replies to host 192.168.111.3 at MAC address 00:a0:c9:87:64:23 with an ARP reply packet, in which it supplies its own MAC address, 00:e0:29:93:11:88.

Consulting the local host's ARP table following this exchange, we see a new entry:

Interface: 192.168.111.3 on Interface 0x2
  Internet Address      Physical Address      Type
  192.168.111.1         00-90-7f-0f-d2-7d     dynamic   
  192.168.111.2         00-e0-29-93-11-88     dynamic   

This host now knows where to send packets destined for 192.168.111.2.

ARP and Routing

ARP is also used when the local host must learn the MAC address of a (default) gateway—a router or firewall—that has been identified as the system to which all IP packets with non-local destinations are to be forwarded (often called the first hop). In our example, non-local destinations are any IP network other than 192.168.111.0, subnet mask 255.255.255.0. The Windows 2000 route command conveniently calls out the Default gateway (the final entry in the route table above). Otherwise, the default gateway is usually identified with the network destination 0.0.0.0 and netmask 0.0.0.0.

Gateways use ARP to forward IP packets over the next or last hop to the host identified as the destination. Your firewall (Firebox or SOHO) has an ARP table for each Ethernet interface, and consults this just as the local host in our example.

Subnet Masks can Subvert ARP

The subnet mask is significant in ARP. You won't see it in the ARP requests or replies, but the local host consults the subnet mask in its routing table to determine whether it should:

1.      Use ARP to send traffic directly to a neighbor on its local network,

2.      Use a manually configured or static route for forwarding the packet, or

3.      Use its default gateway for forwarding the packet.

Subnet masks tell systems the "extent" of the address space that corresponds to the local network. Sometimes a subnet mask is expressed in dotted decimal notation (255.255.255.0), and sometimes it is expressed as slash notation (/24). In slash notation, the number after the slash expresses how many bits of the 32-bit IP address are dedicated to the network's address. The remaining bits are used to address the hosts on this network. For example, in the address 192.168.110.0/24, the network address is 192.168.110.x, and the devices on the network will fill out the final quad "x" with any number between 1 and 254. To help remember which dotted quad notation corresponds with what slash notation, I keep the following table on my Windows desktop:

Subnet    Host     Num. of     Hosts per 
Bits      Bits     Subnets     Subnet         Netmask 
24         8         1             254        255.255.255.0 
25         7         2             126        255.255.255.128 
26         6                      62        255.255.255.192 
27         5                      30        255.255.255.224
28         4        16              14        255.255.255.240
29         3        32               6        255.255.255.248 
30         2        64                      255.255.255.252 
32         0       256                      255.255.255.255

Problems occur when hosts on the same LAN are configured with different subnet masks. When administrators or config tools use different mask notations, converting between dotted quad and slash notation can lead to user error.

When you mismatch subnet masks, two routing problems can arise. If the local host's subnet mask is larger than the correct mask for the local network, the local host may ARP for a destination rather than use the default gateway—it's incorrectly assuming the destination is on its local network. If the local host's subnet mask is smaller than the correct mask for the local network, it will incorrectly forward packets to the default gateway rather than the destination itself, resulting in sub-optimal packet handling across the local network.

Proxy ARP

Your organization might have legitimate reasons to maintain currently assigned IP addresses on certain public servers now protected by the firewall, either on the trusted or DMZ network. This is one of the reasons the Firebox provides the drop-in mode. In this configuration, the Firebox plays an important role as an intermediary or proxy for hosts that have addresses assigned from the public space.

Recall that ARP relies on the broadcast capability of Ethernet. With drop-in mode, you assign the same public IP address to the trusted, DMZ, and external Firebox interfaces, and then assign addresses from your public IP space to hosts behind the trusted and DMZ interfaces. Because only the Firebox's external network interface is connected to public LAN, hosts with public IP addresses connected to the trusted and DMZ LANs won't hear broadcasts received on the public Ethernet LAN. Not to worry, the Firebox proxies ARP responses on all these hosts' behalf. In other words, the Firebox not only answers ARP requests for its own public IP address, but for all hosts with public IP addresses on the trusted and DMZ LANs as well. With these capabilities, a new Firebox can drop into your network with minimal changes to your routing.

More to come…

ARP is only the initial element of the routing and forwarding process for IP-based networks. Now that we've set the stage by describing some basic routing, in Part 2, I'll explain how best path selection and policy-based routing protocols work, and the kinds of issues you may encounter when inserting a firewall in networks where such protocols are enabled. See you then. ##

For more helpful articles, see our LiveSecurity Archive

Copyright© 2002, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.



Copyright © 1996 - 2002 WatchGuard Technologies, Inc. All rights reserved.