Republished with permission from
WatchGuard Technologies, Inc.
Routing and Your Firewall, Part 2
In my first column discussing routing and your firewall, I explained how the Address Resolution Protocol works. I then identified some of the problems users and administrators may experience when firewalls are incorporated into a network topology. In this column, I explain how the most commonly used Internet routing protocols operate and identify problems you may encounter when adding a firewall to a topology where dynamic, adaptive routing is used.
Let's begin with some routing terminology. Dynamic routing means that systems participating in routing actively exchange information about the best paths or routes between networks. Dynamic routing is distinguished from static routing, where hosts and gateways use pre-configured tables that describe the interfaces and gateways across which packets are forwarded towards their destinations. The Windows route for the LAN attached to your Ethernet NIC is an example of static routing.
Adaptive routing means that systems participating in routing adjust for situations where connectivity between networks is interrupted, either from the loss of a router or the loss of a communications link. Adaptive routing protocols like RIP and OSPF are commonly used in larger networks to provide resiliency from temporary network failures. For an overview of how RIP and OSPF work, read my sidebar, Interior Gateway Protocols (IGPs).
Dynamic Routing and Firewalls
The Firebox doesn't support dynamic, adaptive routing protocols. Most firewalls don't. This isn't a bad thing. A proxy firewall is supposed to be a choke and policy enforcement point for application traffic. But, for a number of reasons, it's not uncommon for routing to break or performance to deteriorate when firewalls are deployed.
The exact impact of a new firewall on your routing depends on the network topology. IGP shares something in common with ARP: misconfigured subnet masks result in individual routers interpreting route advertisements inconsistently. This is a common reason routing may break.
Other problems are more difficult to describe. But generally, if two routers in a routing domain must be able to exchange reachability information for "expected" routing to occur, and you place a firewall between them, something unexpected (and probably bad) will occur.
When neighboring routers are prevented from exchanging reachability information, neither router will be aware of any destination networks reachable through the other router. If these routers cannot identify alternative paths, then some destination networks will be unreachable from some source networks. If the routers can converge on alternative paths, then traffic may flow but not in the optimal manner originally intended.
Let's consider the following example.
A company uses two access routers (that is, routers having direct access to the Internet; in the diagram, A and B) with two separate T1 links to the public Internet. There are also several other routers (C, D, E) in the company's topology. All use an IGP to determine best paths throughout the company network, and most importantly for Router E, the path to the nearest router (A) that provides Internet access.
Inserting a firewall between routers A and C can break adaptive routings. Relying totally on its IGP, Router A won't know about any router other than the ISP's router (your ISP's access router terminates your access circuit(s) at a "point of presence;" this demarcation point between your network and the ISP is not depicted in the Internet cloud above). Router E incorrectly thinks the best path to the Internet is through Routers C, D, and B. The partitioning of the company network and the inefficient routing are minor issues compared to the security breach: data traffic can go around the firewall we just placed between Routers A and C because alternative routes have been determined by routers as they process the topology changes they receive.
How do you deal with this? In this case, it would be prudent to have a firewall between Routers B and D as well as between A and C, supporting an identical security policy. If routers A and B are not connected to each other by a LAN, turn off adaptive routing in those routers.
What about allowing a routing protocol through a firewall to deal with this? After all, in the Policy Manager you can enable unicast Routing Information Protocol (RIP) (Edit => Add Service => Packet Filters => RIP). So, yes, you can run routing through the firewall, but there are several constraints, and some risks you must attempt to reduce.
One very legitimate reason to allow routing through a firewall is to allow an Internet access router to dynamically learn what routable subnets exist behind the firewall. This saves you the headache of configuring static routes each time you add, drop or change a subnet. You can allow RIP through the Firebox for this purpose, but if you do, you must be wary of routes injected from or leaked to the public Internet. This problem occurs if you permit RIP traffic both inbound and outbound, and if you exchange routing with your ISP. Many scans can detect a RIP listener port, and spoofing RIP is rather simple, so don't enable RIP to your ISP. Instead, allow unicast RIP through your Firebox (since broadcast RIP won't pass through it), outbound only. Configure the routers in your internal (protected) network to announce RIP updates to your access router(s). Then, enable RIP on your access router's inside interface, the one that faces your Firebox, so that it can listen for RIP updates from routers behind your Firebox. The effect here is that your access router will learn the topology of your internal network, but no advertisements from your access router or from the Internet will affect your internal network.
The benefits of such a configuration are as follows:
Of course, when you add new subnets internally, the Firebox must be configured to process traffic for the new internal IP subnet, and your access router must be configured to forward traffic for any new network your ISP understands to be reachable via your access router.
Lest I overlook the obvious, private IP addresses must be hidden behind NAT. These are not routable, and such addresses should never be seen or advertised outside the Firebox.
Troubleshooting Routing Problems
In general, how do you know when routing is broken? First you must know how you expect your routing to behave. Yes, this means you need a map of the topology that illustrates how you expect routing to converge when all links and routers are up and servicing traffic. You'll need to document the configuration for each router in the topology. Document what routing protocol you are using, what type of measurement you use to identify the cost of transiting a link (e.g., delay, hop), subnet addressing and masks of each network, IP addresses assigned to each router interface, and all IGP-specific routing parameters (these probably depend on your router vendor).
Once you have documented and configured your routers, set 'em loose. When you have a stable topology -- one where all routers and links are up and operating -- use SNMP or a vendor specific method to gather the routing tables from all your routers to see if all the expected routes exist in each router's tables. If the routing tables don't show the routes you expect, then examine the configurations of routers to determine if you have entered the correct identity, authentication, addressing and subnet masking information at your gateways. Double-check the parameters appropriate for the routing protocol you've selected: if anything has more tuning knobs than a firewall, it's a router.
Any decent router will support logging and diagnostics or debug levels for routing protocols. Use these to determine how the routing protocol is behaving. If you want to be thorough, determine whether your routing will adapt to failures by systematically removing links and routers from the topology. You may want to repeat the collection and examination of routing tables to see whether your network adapted to each failure as you expected. Yes, this is a painstaking and methodical process. But like VPN implementation, investing more up front makes your daily operations easier.
What about daily operations? Ping, traceroute and SNMP-based tools are still commonly used to help you determine how much of your network is reachable, and to isolate faults. Ping sweeps of all router interfaces will help you identify failure points in your network. Traceroutes will identify the last in a sequence of routers that packets have traversed on their path from the source to a destination network. And of course, collect routing tables and compare the currently employed routes to the expected routes you have documented (and have kept up to date). If your firewall policy blocks ICMP-based ping or traceroute, try a UDP version like VisualRoute. This is safer than allowing ICMP-based ping or SNMP access on your firewalls, since it's too easy to forget you temporarily enabled ICMP through your firewall's outside interface. It's not very safe to allow SNMP outside your firewall; functions like the GET request can reveal too much about your routing. If you feel you must use SNMP to a router outside the firewall, make sure you use SNMP v3 or higher so that you aren't sending community strings (SNMP-speak for "passwords") in clear text. Use strong community strings; better yet, use a VPN tunnel to protect and limit SNMP access.
Dynamic routing can be tedious to implement, but understanding it will help you add firewalls at will, without a high cost in confusion and downtime. As your network grows, your investment in deployment will pay off in network availability. ##
For Part 1 of this article, click here.
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.