620 Alden Rd
Suite 104 Markham, ON  L3R 9R7
Phone: 905-513-8866
Fax: 905-470-6019

Toll Free: 1-800-263-1794


Don't Run Routing Protocols on Firewalls

I was reminded again this week of why it's a bad idea to run a routing protocol on a firewall. Sometimes you can't avoid it, but if at all possible, firewalls should use static routes. There are several reasons for this, but here are what I consider to be the top four.

The first and most important reason is that firewalls are inherently stateful. This means that they keep track of every "flow" or conversation passing through them. If one device starts a conversation on interface A and the other device is on interface B, then the firewall should reject packets from either device if they are received on interface C. The firewall will assume that this packet has had its source address spoofed by an attacker. Routing protocols exist to dynamically reroute packets, and don't keep track of flows. So there is enormous potential for legitimate flows to be disrupted.

Second, an attacker might take advantage of routing protocols to reroute packets through a protocol analyzer, or perhaps through an unprotected Internet connection. This could be used to facilitate other attacks.

Third, an attacker could launch a simple denial of service attack by disrupting the firewall's routing table.

And fourth, firewalls almost never have a routing protocol implementation that is as feature rich or robust as a router. Firewalls generally reside at the edges of networks, where routing information is often redistributed from one protocol to another. Redistribution is where having the full rich feature set of a routing protocol is most important - route tags and complex filtering rules are common. Firewalls rarely provide good support for these types of features.

The example that I saw this week was an example of the first problem. The customer's firewall had a default route as well as running OSPF internally. The firewall temporarily lost contact with its OSPF neighbor router, so it had to start using its default route to direct packets that were previously routed dynamically. During this short disruption, the firewall received packets from a DMZ interface destined for the internal network. It promptly routed these packets to the outside interface, correctly following its default route. At the same time, it created a flow state table entry pointing to the outside interface. In this particular case it was a UDP flow, so there was no need for the firewall to see two-way communication before creating the connection table entry.

When OSPF recovered, the flow state table was not cleared, arguably a bug, but a subtle one. In this particular case, the packets were not TCP, so the firewall did not see a fresh SYN packet to establish a new flow state entry. In fact, because the server on the DMZ kept rapidly sending packets to the destination devices, the flow entry was never removed in the firewall. The application became completely stuck.

The client assumed it must be a hardware problem, and tried to fail over the firewall to the backup device. This disrupted the OSPF peers again, causing the problem to happen again. In the end they managed to temporarily restore the connection by resetting the DMZ interface, which forced the firewall to finally purge the flow table without disrupting OSPF.

The permanent fix involved implementing static routes to over-ride OSPF. There are cases where a firewall really does need to run a routing protocol, but I believe that these cases are relatively rare in a well-designed network.