Virtual Routing is feature in cOS Core that allows the creation of multiple, logically separated virtual systems within cOS Core, each with its own routing table. These systems can behave as physically separated Clavister firewalls and almost everything that can be done with separate firewalls can be done with them, including dynamic routing with OSPF. Virtual systems are sometimes also referred to as Virtual Routers.

The cOS Core components involved in creating virtual routing are:

There are two ways of associating a specific routing table with a specific interface:

To ensure that a routing table does not use any other tables in the route lookup process, the Ordering parameter of the table should be set to Only. This is discussed further in Section 4.3, Policy-based Routing.

m> Virtual Routing Examples

The next section will describe an example of virtual routing usage. Another example where a simple virtual routing setup routes all Internet traffic from internal users through an IPsec tunnel can be found in an article in the Clavister Knowledge Base at the following link:

https://kb.clavister.com/324735851

Consider a single Clavister firewall connected to two external ISPs, ISP1 and ISP2. ISP1 provides Internet connection to the internal network for Department A and connects to the firewall via the physical interface If1.

ISP2 provides Internet connection to the internal network for Department B and connects via the physical interface If2. For administration purposes it is decided that the Clavister firewall is to be divided into 2 virtual systems, one for each ISP.

This is done by creating two dedicated routing tables. pbr1 is created to handle traffic for ISP1 and Department A. pbr2 is created to handle traffic for ISP2 and Department B. This arrangement is illustrated in the diagram below.

When the administrator configures this in cOS Core, interface If1 is made a member of routing table pbr1 but not pbr2. In other words, If1 is explicitly associated with pbr1. Conversely, interface If2 is made a member of pbr2 but not pbr1. It is this interface membership which determines which routing table is used and this keeps the two sets of traffic totally separated.

Using virtual routing (or PBR rules) to split Internet traffic between two ISPs is also described in more depth in a Clavister Knowledge Base article at the following link:

https://kb.clavister.com/324736086

Reusing Private IP Addresses

An advantage of using separate routing tables on different interfaces is that internal, private IP address ranges can be reused on different virtual systems. For example, Department A and Department B could both use the internal network 192.168.0.0/24.

Since route lookup is done in completely separate routing tables, there are no conflicts.

VPN Tunnels are Interfaces

VPN tunnels are also considered to be interfaces in cOS Core and can therefore also be associated with their own routing tables just as physical interfaces can.

This means that VPN tunnels can be logically separated from each other within cOS Core.

Using Loopback Interfaces

In this simple example, loopback interfaces were not used since there is no requirement for communication between the virtual systems. For example, Department A does not need to communicate with Department B. If communication between them is needed then an appropriate loopback interface pair would have to be defined to allow this.

After we define a loopback interface, all traffic sent to that interface automatically appears as being received on another interface.

Using Routing Rules can solve many of the problems that virtual routing can, but complex configurations can become unwieldy for such rules. Consider a single Clavister firewall being used as the firewall for two organizations, both using the same IP span.

In this case, two separate routing tables could be used, one for each organization as shown below.

Two routing tables pbr1 and pbr2 are first defined for this scenario. Their contents are listed below:

Routing Table pbr1

Routing Table pbr2

Getting traffic from each network to and from the Internet is straightforward. Assuming only outbound traffic, it requires only two Routing Rule objects. Assuming that each organization has a public IPv4 address which maps to servers on the respective networks then outbound as well as inbound traffic can be handled with the following four routing rules:

This works if the two organizations do not need to communicate with each other. If they do, the following two additional routing rules are also needed and are placed before the four above.

With two organizations, two routing rules are enough to allow them to communicate. However, with three organizations, six are needed; with four, twelve are needed; with five, twenty are needed as so on. The numbers continue with an all-to-all mapping of 30, 42, 56 rules and the administration task soon becomes unmanageable.

The Advantage of Virtual Routing

Virtual routing can eliminate the all-to-all mapping required with routing rules by using interface routing table membership instead of routing rules. This reduces the complexity by creating 3 virtual systems which are represented by the router symbols in the diagram below.

Here, each organization gets a virtual system of its own. These connect to the main routing table using pairs of loopback interfaces. The routing tables would have the following entries:

Routing Table main

Routing Table vs1

Routing Table vs2

Ethernet Interfaces

Loopback Interfaces

For each connection between a pair of virtual systems, a pair of loopback interfaces is required, one for each system. When traffic is sent through main-vs1, it arrives on vs1-main. When traffic is sent through vs1-main, it is received on main-vs1. This is exactly the same as with two firewalls and two interfaces, one on each, with a connection between them.

The Routing Table Membership setting means that if a connection arrives on an interface, it will be routed according to the routing table that the interface is a member of.

Also note how the IPv4 addresses of the internal interfaces of the virtual systems differ. If per-interface routing table membership were not used, the core routes for both IP addresses would be added in both routing tables, leading to 192.168.0.1 being unusable in vs2 (even though it should be usable) and 192.168.0.254 being unusable in vs1. With per-interface routing table membership, interface IP addresses belonging to one virtual system will not interfere with other virtual systems and loopback interfaces are not needed.

The IPv4 addresses of the main-vs1 and main-vs2 interfaces are the same as the IP address of the external interface. They could also have been set to something nonsensical, such as 127.0.0.1. Regular routing would still have worked since loopback interfaces are raw IP interfaces (the ARP protocol is not used over them). However, their IP addresses will be visible to users doing a traceroute from the inside, and also the issue exists of traffic originating from the Clavister firewall itself to the internal networks, such as pings or logging. Such traffic is most often routed according to the main routing table, and will be sourced from the IP address of the nearest interface in the main routing table.

The IP rule sets for different virtual systems can be split into separate rule sets using the cOS Core feature of creating multiple IP rule sets (see Section 3.6.5, Multiple IP Rule Sets for more detail on this feature).

IP rule set entries for different virtual systems need not be split up. They can reside together in a single IP rule set. The benefit of doing this is being able to define "shared" or "global" IP policies that span over several virtual systems. For example, to counter aggressive attacks, it may be desirable to drop all communication on ports known to be used by those attacks until counter-measures can be put into place. A single Drop entry placed at the top of the rule set can take care of this for all the virtual systems. Using the example of the previous section, this is how the IP rule set might look:

Interface Groups

IP Rule Set Entries

Note that SAT rules do not need to take into account that there are more organizations connected to the same physical unit. There is no direct connection between them; everything arrives through the same interface, connected to the main routing table. If this was done without virtual routing, the Allow rules would have to be preceded by NAT rules for traffic from other organizations. Care would also have to be taken that such rules were in accordance with the security policy of each organization. Such problems are eliminated with virtual routing.

The source interface filters are very specific. Any is not used as the source interface anywhere, since such a rule would trigger regardless. Consider for instance what would happen if the vs1-http-in rules were to use Any as source interface. They would trigger as soon as packets destined to pubip-vs1 were received on main-ext. The destination address would be rewritten to 192.168.0.5, and passed on using the main routing table. The main routing table would not know what to do with 192.168.0.5 and pass it back out to the default gateway outside the Clavister firewall.

If the same naming scheme as shown in this example is used, making sure the source interfaces are correct can be done quickly. All the rules concerning the main system have source interfaces beginning with "main-". All those concerning vs1 have source interfaces beginning with "vs1-", and so on.

The destination interface filters, however, do not need to be as specific as the source interface filters. The possible destinations are limited by the routing tables used. If the vs1 table only includes routes through vs1- interfaces, Any filters can only mean "through other interfaces in the same virtual system". It may however be sound practice to write tighter destination interface filters in case an error occurs elsewhere in the configuration. In this example, rule 1 might use main-ifs, rule 4 might use vs1-main. The SAT and corresponding Allow rules however are already fairly tight in that they only concern one single destination IP address.

An alternative approach to having all the IP policies for different virtual systems in one rule set is to make use of Multiple IP rule sets.

Although all scanning of IP rule sets begins in the main rule set, it is possible to create an entry in the main set whose action is Goto so that scanning continues in another separate, named rule set. These extra rule sets can be defined as needed and one rule set can be created for each virtual system and its corresponding routing table.

More details on this subject can be found in Section 3.6.5, Multiple IP Rule Sets.

When setting up virtual routing, the following steps can help with troubleshooting any problems.