Home  Prev  cOS Core 14.00.15 Administration Guide  Next

4.3. Policy-based Routing

Overview

Policy-based Routing (PBR) is an extension to the standard routing described previously. It offers administrators significant flexibility in implementing routing decision policies by being able to use different routing tables according to specified criteria.

Normal routing forwards packets according to destination IP address information derived from static routes or from a dynamic routing protocol. For example, using OSPF, the route chosen for packets will be the least-cost (shortest) path derived from an SPF calculation. Policy-based routing means that routes chosen for traffic can be based on specific traffic parameters.

Policy-based routing allows the following to be possible:

PBR Components

Policy-based routing implementation in cOS Core is implemented using two components:

Routing Tables

cOS Core, as standard, has one default routing table called main. In addition to the main table, it is possible to define one or more, additional routing tables for policy-based routing. (these will sometimes be referred to as alternate routing tables).

Alternate routing tables contain the same information for describing routes as main, except that there is an extra property defined for each of them which is called ordering. The ordering property decides how route lookup is done using alternate tables in conjunction with the main table. This is described further below.

[Note] Note: The number of tables is limited by the license

The maximum number of routing tables that can be created is determined by the cOS Core license At minimum, there is a limit of 5 alternate tables in addition to the main table.

Example 4.5. Creating a Routing Table

In this example, a new routing table called MyPBRTable is created with the Ordering property set to First.

Command-Line Interface

To see the configured routing table:

Device:/> add RoutingTable MyPBRTable Ordering=First

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

  1. Go to: Network > Routing > Routing Tables > Add > RoutingTable
  2. Now enter:
    • Name: MyPBRTable
    • For Ordering select one of:
      • First - the named routing table is consulted first of all. If this lookup fails, the lookup will continue in the main routing table.
      • Default - the main routing table will be consulted first. If the only match is the default route (in other words, the all-nets route), the named routing table will be consulted. If the lookup in the named routing table fails, the lookup as a whole is considered to have failed.
      • Only - the named routing table is the only one consulted. If this lookup fails, the lookup will not continue in the main routing table.
  3. If Remove Interface IP Routes is enabled, the default interface routes are removed, that is to say routes to the core interface (which are routes to cOS Core itself).
  4. Click OK

Example 4.6. Adding Routes

After defining the routing table MyPBRTable, routes can be added to the table. Assume that the route to a network my_network is to be defined for the lan interface.

Command-Line Interface

Change the context to be the routing table:

Device:/> cc RoutingTable MyPBRTable

Add the route

Device:/main> add Route Interface=lan Network=my_network

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

  1. Go to: Network > Routing > Routing Tables > MyPBRTable > Add > Route
  2. Now enter:
    • Interface: lan
    • Network: my_network
    • Gateway: The gateway router (if there is one)
    • Local IP Address: The IP address specified here will be automatically published on the corresponding interface. This address will also be used as the sender address in ARP queries. If no address is specified, the firewall's interface IP address will be used.
    • Metric: Specifies the metric for this route. (Mostly used in route failover scenarios)
  3. Click OK

Routing Rules

A rule in the routing rule set can decide which routing table is selected. A routing rule has a number of filtering properties that are similar to those used in IP rule set entries. A rule can trigger on a type of service (HTTP for example) in combination with the specified Source/Destination Interface and Source/Destination Network.

When looking up routing rules, it is the first matching rule found that is triggered, so the rule position can be important. In addition, it should be noted that the destination interface used in the filter should be the original destination interface of the traffic before the interface is potentially changed by the new routing table that the rule selects.

Example 4.7. Creating a Routing Rule

In this example, a routing rule called my_routing_rule is created. This will select the routing table MyPBRTable for any http traffic destined for the network my_network.

Command-Line Interface

Device:/> add RoutingRule
			SourceInterface=any
			SourceNetwork=all-nets
			DestinationInterface=any
			DestinationNetwork=my_network
			Service=http
			ForwardRoutingTable=MyPBRTable
			ReturnRoutingTable=MyPBRTable
			Name=my_routing_rule

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

  1. Go to: Network > Routing > Policy-Based Routing Rules > Add > Routing Rule
  2. Now enter:
    • Name: my_routing_rule
    • Service: http
    • SourceInterface: any
    • SourceNetwork: all-nets
    • DestinationInterface: any
    • DestinationNetwork: my_network
    • ForwardRoutingTable: MyPBRTable
    • ReturnRoutingTable: MyPBRTable
  3. If Remove Interface IP Routes is enabled, the default interface routes are removed, that is to say routes to the core interface (which are routes to cOS Core itself).
  4. Click OK

Routing Rules can use IPv4 or IPv6 Addresses

Routing rules support either IPv4 or IPv6 addresses as the source and destination network for a rule's filtering properties.

However both the source and destination network must be either IPv4 or IPv6. It is not permissible to combine IPv4 and IPv6 addresses in a single rule. For further discussion of this topic, see Section 3.2, IPv6 Support.

The Forward and Return Routing Table can be Different

In most cases, the routing table for forward and return traffic will be the same. In some cases it can be advantageous to have different values so that outgoing (forward) traffic uses one routing table, and incoming (return) traffic uses another table.

Consider the example of a system with two hypothetical interfaces, wan1 and wan2, connected to two ISPs. There is also a protected network If1_net on the If1 interface. There are two routing tables, the main routing table and an isp2 routing table. These tables have the following contents:

The main routing table

Index # Interface Network Gateway
1 If1 If1_net  
2 wan1 all-nets isp1_ip

The isp2 routing table

Index # Interface Destination Gateway
1 wan2 all-nets isp2_ip

If traffic coming through wan2 is to have access to If1_net then a routing rule needs to constructed as follows:

Source
Interface 		Source
Network 		Destination
Interface 		Destination
Network 		Forward
Routing Table 		Return
Routing Table
wan2 all-nets any If1_net main isp2

This rule allows the forward traffic through the wan2 table to find the route for If1_net in the main routing table. The return traffic will use the isp2 table so it can reach the initiator of the connection.

This example should also have some address translation rules since If1_net will probably be a private IP network. For simplicity, that has been omitted.

Explicit Interface/Routing Table Association

If a particular routing table is to be always used for traffic from a given source interface, regardless of the service, it is possible to associate the source interface explicitly with a particular table using the Routing Table Membership property of the interface.

The difference with this method of explicit association is that the administrator cannot specify the service, such as HTTP, for which the lookup will apply. Routing rules allow a more fine-grained approach to routing table selection by being able to also select a specific service and interface/network filter.

The Routing Table Selection Process

When a packet corresponding to a new connection first arrives, these are the processing steps taken to determine which routing table to use:

  1. The routing rules are looked up first. To allow this, the packet’s destination interface must be determined using an initial route lookup that is always performed in the main routing table. It is therefore important that a match for the destination network is found. To ensure this, it is recommended to at least have a default all-nets route which can catch anything not explicitly matched.

  2. A search is now made for a routing rule that matches the packet's source/destination interface/network as well as service. If a matching rule is found then this determines the routing table to use.

  3. If no matching routing rule is found, a check is made to see if the receiving interface is a member of a specific routing table. If the interface is associated with a particular routing table through its Routing Table Membership property, that routing table will be used. If there is no membership then the main table will be used.

  4. Once the correct routing table has been located, a check is made to make sure that the source IP address in fact belongs on the receiving interface. The Access Rules are first examined to see if they can provide this check (see Section 7.1, Access Rules for more details of this feature). If there are no Access Rules or a match with the rules cannot be found, a reverse lookup in the previously selected routing table is done using the source IP address. If the check fails then a default access rule log error message is generated.

  5. At this point, using the routing table selected, the actual route lookup is done to find the packet's destination interface. Note that the routing table's Ordering property is used to determine how the actual lookup is done and the options for this are described in the next section. To implement virtual systems, the property should be set to the value Only.

  6. The connection is then subject to the IP rule set. If a SAT rule set entry is encountered, address translation will be performed. The decision of which routing table to use is made before carrying out address translation but the actual route lookup is performed on the altered address. Note that the original route lookup to find the destination interface used for all rule lookups was done with the original, untranslated address.

  7. If allowed by the IP rule set, the new connection is opened in the cOS Core state table and the packet forwarded through this connection.

The sequence described above is also illustrated as a flowchart in Figure 1.4, “Expanded Apply Rules Logic”.

The Ordering parameter

Once the routing table for a new connection is chosen and that table is an alternate routing table, the Ordering parameter associated with the table is used to decide how the alternate table is combined with the main table to lookup the appropriate route. The three available options are:

  1. Default

    The default behavior is to first look up the route in the main table. If no matching route is found, or a default route is found (a route with the destination all-nets), a lookup for a matching route in the alternate table is performed. If no match is found in the alternate table then the default route in the main table will be used.

  2. First

    This behavior is to first look up the connection's route in the alternate table. If no matching route is found there then the main table is used for the lookup. The default all-nets route will be counted as a match in the alternate table if it is found there.

  3. Only

    This option ignores the existence of any other table except the alternate table so that is the only one used for the lookup.

    One application of this option is to give the administrator a way to dedicate a single routing table to one set of interfaces. The Only option should be used when creating virtual systems since it can dedicate a routing table to a set of interfaces.

The first two options can be regarded as combining the alternate table with the main table and assigning one route if there is a match in both tables.

[Important] Important: Ensure an all-nets route appears in the main table

A common mistake when setting up policy-based routing is the absence of a default all-nets route in the main routing table. If there is no matching route in main, the traffic will be dropped, unless the receiving interface is a member of a specific routing table. This is explained further under the heading “The Routing Table Selection Process” above.

Policy-based Routing with Multiple ISPs

A common application of the policy-based routing feature is when traffic is being sent to the Internet using multiple Internet Service Providers (ISPs). The setup for this is described below in Example 4.8, “Policy-based Routing with Multiple ISPs”. This topic is also discussed in a Clavister Knowledge Base Article at the following link:

https://kb.clavister.com/324736086

Example 4.8. Policy-based Routing with Multiple ISPs

This example illustrates a scenario where Internet traffic is going to be sent to multiple ISPs. The following will be assumed:

  • Each ISP will provide an IPv4 network from its network range. A 2 ISP scenario is assumed in this case, with the network 10.10.10.0/24 belonging to ISP A and 20.20.20.0/24 belonging to ISP B. The ISP provided gateways are 10.10.10.1 and 20.20.20.1 respectively.
  • All addresses in this scenario are public addresses for the sake of simplicity.
  • This is a "drop-in" design, where there are no explicit routing subnets between the ISP gateways and the Clavister firewall.

In a provider-independent network, clients will likely have a single IP address, belonging to one of the ISPs. 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 with the BGP protocol, which means not worrying about different IP spans or about 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 called r2 that uses the default gateway of ISP B.

Interface Network Gateway ProxyARP
lan1 10.10.10.0/24   wan1
lan1 20.20.20.0/24   wan2
wan1 10.10.10.1/32   lan1
wan2 20.20.20.1/32   lan1
wan1 all-nets 10.10.10.1  

Contents of the named Policy-based Routing table r2:

Interface Network Gateway
wan2 all-nets 20.20.20.1

The table r2 has its Ordering property set to Default, which means that it will only be consulted if the main routing table lookup matches the default route (all-nets).

Contents of the Policy-based Routing Policy:

Source
Interface 		Source
Range 		Destination
Interface 		Destination
Range 		Selected/
Service 		Forward
VR table 		Return
VR table
lan1 10.10.10.0/24 wan1 all-nets all_services r2 r2
wan2 all-nets lan1 20.20.20.0/24 all_services r2 r2

To configure this example scenario:

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

  1. Add the routes in the list to the main routing table, as shown above.
  2. Create a routing table called r2 and make sure the ordering is set to Default.
  3. Add the routes found in the list above for the routing table r2.
  4. Add the PBR routing rules according to the list with the following:
    • Go to: Network > Routing > Policy-Based Routing Rules > Add > Routing Rule
    • Enter the information from the list
    • Repeat to add the next rule

Note: Separate routing rules should be added for the inbound and outbound connections.

Home  Prev   Next