Policy Based Routing

This section includes the following topics:

• How Policy Based Routing works

• Policy Based Routing Tables configuration

• Policy Based Routing Rules configuration

• Policy Based Routing examples

Normal routing can be said to be a simple form of policy based routing; the "policy" is the routing table, and the only data that can be filtered on is the destination IP address of the packet. What is commonly referred to as policy based routing, is, simply put, an extension of what fields of the packet we look at to determine the routing decision.

Clavister Security Gateway extends this further by not just looking at the packets one by one, but also at state information, which results in higher flexibility while being easier to use, much in the same way that a stateless packet filter differs from a stateful firewall.

Policy based routing can be used to:

• Connect to two or more ISPs without using BGP, and accepting inbound connections from all of them. Return traffic is routed back out through the ISP that delivered the incoming request.

• Route certain protocols through transparent proxies such as web caches and anti-virus scanners, without adding another point of failure for the network as a whole.

• Create provider-independent metropolitan area networks, i.e. one where all users share a common active backbone, but can use different ISPs, subscribe to different streaming media providers, etc.

How Policy Based Routing works

The Policy Based Routing (PBR) implementation in Clavister Security Gateway consists of two elements:

• One or more named routing tables in addition to the normal routing table

• A separate PBR ruleset, which determines which named routing table to use

As mentioned earlier, policy routing is done per state, which means that the rules in the PBR ruleset can specify which routing table to use in the forward as well as return direction.

The order of execution for an inbound packet is as follows:

1. Look up destination interface according to the main routing table (the "Routes" section)

2. Perform a ruleset lookup in the "Rules" section. Note that destination interface filters in the ruleset will be compared to the result of the route lookup from the previous point; not some future PBR decision.

3. If the lookup in the "Rules" section resulted in the packet being allowed, perform a lookup in the "Policy-Based Routing Rules" section. As usual, the first matching rule is the one that will be used. If there is no matching rule, no policy based routing will be performed. Route lookups will simply be done according to the "Routes" section.

4. If SAT rules were encountered in the "Rules" lookup (step 2), perform address translation.

5. Do the final route lookup according to what we learned in step 3.

To clarify: We decide which routing table to use before carrying out address translation. However, the actual route lookup is performed on the altered address.

Policy-Based Routing Tables configuration

Policy-Based Routing tables are defined in the Policy-Based Routing table configuration section located in the Routing folder.

Creating a Policy-Based Routing table

To create a named routing table, right-click the "Policy-Based Routing Tables" folder in the security editor and choose "New Policy-Based Routing Table". The following dialog will appear:

Creating a Policy-Based route

Policy-Based Routing Rules configuration

The PBR ruleset basically uses the same filtering and schedule parameters as the Rules section. There is however no Action (NAT/Allow/etc).  There are two new parameters: the names of named routing tables to use in the forward and return direction of traffic through a state.

Policy Based Routing examples

The following two examples illustrate two common uses of policy based routing:

• Using multiple ISPs.

• Passing traffic on for processing on a separate machine, e.g. an anti-virus scanner or web cache.

Example 1: Multiple ISPs

This scenario assumes the following:

• Each ISP will give you an IP network from its network range. We will assume a 2-ISP scenario, with the network 1.2.3.0/24 belonging to "ISP A" and "2.3.4.0/24" belonging to "ISP B". The ISP gateways are 1.2.3.1 and 2.3.4.1, respectively.

• All addresses in this scenario are public addresses, for simplicity's sake.

• It is as a "drop-in" design, where there are no explicit routing subnets between the ISP gateways and the firewall.

In a provider-independent metropolitan area network, clients will likely have a single IP address, belonging to either one or the other ISP. In a single-organization scenario, publicly accessible servers will be configured with two separate IP addresses: one from each ISP. However, this difference does not matter for the policy routing setup itself.

Note that, for a single organization, Internet connectivity through multiple ISPs is normally best done through BGP, where you do not need to worry about different IP spans or policy routing. Unfortunately, this is not always possible, and this is where policy based routing becomes a necessity.

We will set up the main routing table to use ISP A, and add a named routing table, r2 that uses the default gateway of ISP B.

Contents of the main routing table:

Contents of the named policy routing table r2:

The table r2 has its Ordering parameter set to Default, which means that it will only be consulted if the main routing table lookup matches the default route (0.0.0.0/0).

Contents of the PBR ruleset:

Note: that we add rules for inbound as well as outbound connections.

Example 2: Extra traffic inspection

This example illustrates how you can pinpoint a certain protocol and hand it over to a transparent proxy for extra processing. Such extra processing may be web caching or anti-virus scanning. We assume the following:

• We will hand over outbound HTTP connections to the transparent proxy

• The proxy is connected to a firewall interface named util, and has an IP address of 1.2.3.4

Contents of the main routing table:

The route to 1.2.3.4/32 is not, strictly speaking, needed. However, it allows normal connectivity to the proxy, e.g. allowing you to ping it, or connect to it for other administrative purposes.

Contents of the named policy routing table r2:

The table r2 has its Ordering parameter set to First, which means that it will be consulted before the main routing table. As this routing table only has a single route, covering all destinations, it means that all traffic passed through this routing table will be routed through 1.2.3.4.

Contents of the PBR ruleset:

This ruleset may look deceptively simple, but it accomplishes several things:

• The obvious: packets from the inside to port 80 get passed to the proxy

• Perhaps less obvious: packets from the proxy back to the inside will not get passed back to the proxy! If there had been no distinction between Forward and Return direction, we would have been using the r2 table in both directions, which would produce less-than-desirable results. However, this rule is set to use the main routing table in the return direction, and return traffic from the proxy works as intended.

• Outbound connections from the proxy will not trigger the above rule, as they originate from the util interface. If they had triggered the above rule, the requests from the proxy itself would have been sent right back to the proxy, which would not work.