Multiple Route Tables

Up to this point you have been using the single master route table available within Policy Routing. All of the examples and uses have assumed that you only have a single global route structure. This is true for all known Policy Routing capable devices with the exception of Linux. At this point I will diverge into the enhanced world of Policy Routing structures under Linux.

As you saw in Chapter 3, within the Linux Policy Routing structure there is provision for 255 independent routing tables. The standard structure allocation provides a default structure. Recalling this information from Chapters 3 and 4, you have the following default table structure:

 Table #253    =    DEFAULT (created by the default rule #32767) Table #254    =     MAIN (default master route table) Table #255    =    LOCAL (broadcast & local addresses)

As you recall from Chapter 3, of these tables the LOCAL table should not be modified or used normally. It has a special functionality with respect to the broadcast and local route structures.

The naming of these tables is handled by a lookup reference file. This file is /etc/iproute2/rt_tables . While you can always reference the tables by number from 1 to 255, it is easier to read your scripts if you name the tables. I usually will place a comment at the beginning of my scripts that states the names and numbers association so that the file still makes sense if someone changes the rt_tables mapping.

Example 5.8: Basic Router Filters v3.0

In order to use the flexibility immediately accorded to you by the specification of multiple routing tables, you decide to recode your security structure from Example 5.7 in terms of simpler rules. You start with the core router. You decide to create two new route tables that contain the routes for the accounting and engineering networks. First you edit the rt_tables file and name the tables appropriately (see Listing 5.6).

Listing 5.6 The Edited rt_tables File

 # # reserved values # 255     local 254     main 253     default 0       unspec # # Policy Routing Example 5.8 # 1    accounting 2    engineering # # end rt_tables

Now you start to populate the route tables and rules.

Note that the specification of the complete routing and security structure can now be fulfilled on the core router. In Example 5.7 you were limited because of the rules. In that setup any traffic selected for either the engineering or accounting network could be routed to the other network. That is, any traffic from 10.10/14 could be routed to the accounting network due to being selected for fall through to the main table by the Engineering rule. And vice versa, the Accounting-allowed rule traffic would fall through to the main table and could be routed to the engineering network.

Now you see that you can specify exactly that all traffic to either of these networks be segregated into a table by the appropriate rule. Thus you only need three rules to specify all the traffic flow. You need to create the rules first by starting fresh on the core router without any routes or rules referring to the accounting or engineering networks.

  #For the Accounting Network   ip rule add from 10.2.3.32/27 to 172.17/16 prio 16000 table accounting   ip rule add from 10.3.2.0/27 to 172.17/16 prio 16010 table accounting   #For the Engineering Test Network   ip rule add from 10.10/14 to 192.168.2/24 prio 17000 table engineering

This sends the traffic destined for the respective network to a route table for that network, and only such traffic will get to the table. Now you need to code the accounting and engineering route tables.

 # The accounting table #1  ip route add 172.17/16 table accounting via 10.254.254.252 proto static   ip route add prohibit default  # The engineering table #2  ip route add 192.168.2/24 table engineering via 10.254.254.253 proto static   ip route add blackhole default

Now all traffic flowing to these networks is segregated and you have implemented the security policy. Or have you?

Recall that the original security policy stated that all traffic to the accounting network that was not permitted was to be returned an ICMP Administratively Denied message, and that no one was to be able to determine that the engineering test network existed if they were not permitted to access it. Does this setup still follow those maxims? Upon further inspection you determine that it does not. Why?

You added to the accounting and engineering routing tables default routes that specified the appropriate actions to take. For accounting you prohibit and for engineering you blackhole. But what if someone from the 10/8 network who is not allowed onto engineering ”in other words, someone sourced outside 10.10/14 ”decides to try to get to 192.168.2/24? From the rules above they would end up in the main table. Now the main table does not have a route to the engineering network so by default the router will return a ICMP Network Unreachable. This is not the same as a blackhole where the packets are dropped. So the default route in the engineering table is never reached or used. Ditto for the accounting network.

The trick then is to still use the rules to control the flow of alternate traffic. You do note that you had purposely allocated space in the rule priority selection so that you could also insert rules later on. To complete the Policy Routing structure, you add the rules to control the unwanted traffic streams:

 #For Accounting network  ip rule add from 0/0 to 172.17/16 prio 16050 prohibit  # For Engineering test network  ip rule add from 0/0 to 192.168.2/24 prio 17050 blackhole

Now you have the security policy completely specified on the core router. Turning to the accounting and engineering routers you see that the setups as specified in Example 5.7 are sufficient for the current security structure.

At this point you review the total Policy Routing structure. The core router has the main role in the routing structure. It provides the appropriate error messages and allowed traffic control to the accounting and engineering networks. This policy structure is supported by the implementation on the accounting and engineering routers. These subnetwork routers reinforce the security policy by allowing only the traffic that is allowed. While in this type of setup you could have dispensed with implementing any policy on the core router, you want to stress that the core router should always be the default. The subnetwork routers merely prevent internal hackery.

You can see how without the multiple routing tables on the core router you would not have been able to lock down the traffic to the subnetworks as accurately. This is true of many situations in Policy Routing. Since each routing table is completely independent of the others, there can be no crossover bleed of misdirected routes.

Top