The components of a Route

• Interface – Interface where is the destination network
• Network – destination network itself
• Gateway – next hop IP address
• Local IP Address – something like secondary ip address. You can specify this on your physical interface and FW will reply to ARP for this IP. Where it is useful? When you for example connect two distinct subnets to same physical interface of course the interface will reply to ARP just for subnet within his range. However you can specify Local IP address to be in the second distinct range, hence replying to
• Metric – weight for comparing similar routes

The cOS Core route lookup mechanism has some slight differences to how some other router products work. In many routers, where the IP packets are forwarded without context (in other words, the forwarding is stateless), the routing table is scanned for each and every IP packet received by the router. In cOS Core, packets are forwarded with state-awareness, so the route lookup process is tightly integrated into the cOS Core stateful inspection mechanism. When an IP packet is received on any of the interfaces, the connection table is consulted to see if there is an already open connection for which the received packet belongs. If an existing connection is found, the connection table entry includes information on where to route the packet so there is no need for lookups in the routing table. This is far more efficient than traditional routing table lookups, and is one reason for the high forwarding performance of cOS Core.

If an established connection cannot be found, then the routing table is consulted. It is important to understand that the route lookup is performed before any of the various policy rules get evaluated.

Routing table

In the pictures you can see how the routing table looks like in cOS Core. It uses slightly different way of describing routes compared to other systems. Rules for matching the route table is same as in other systems – the narrowest routing table match is selected. That is the ordering of the routes is not important, instead the most specific route is selected and used. Beware that because of Access Rule to protect against IP spoofing you need to have also route for the source address in the table as reverse routing check is performed.

You can specify in cOS Core composite subnets. For example IP address range 192.168.0.5 to 192.168.017 and another route for IP addresses 192.168.0.18 to 192.168.0.254. Below you can see how to check routing tables content via CLI:

Routes to the Core Interface

cOS Core automatically populates the active routing table with Core Routes. These routes are present for cOS Core to understand how to route traffic that is destined for the itself. To display Core Routes use the CLI command routes -all This operation cannot be performed in InControl.

Route Failover

Clavister Security Gateways are often deployed in mission-critical locations where availability and connectivity is crucial. For example, an enterprise relying heavily on access to the Internet could have operations severely disrupted if a single connection to the external Internet via a single Internet Service Provider (ISP) fails. It is therefore not unusual to have backup Internet connectivity using a secondary ISP. The connections to the two service providers often use different routes to avoid a single point of failure. To allow for a situation with multiple ISPs, cOS Core provides a Route Failover capability so that should one route fail, traffic can automatically failover to another, alternate route. cOS Core implements route failover through the use of Route Monitoring in which cOS Core monitors the availability of routes and then switches traffic to an alternate route should the primary, preferred route fail.

To set up route failover, Route Monitoring must be enabled and this is an option that is enabled on a route by route basis. To enable route failover in a scenario with a preferred and a backup route, the preferred route will have route monitoring enabled, however the backup route does not require this since it will usually have no route to failover to. When route monitoring is enabled for a route, one of the following monitoring methods must be chosen:

• Interface link status
• Gateway monitoring
• Host monitoring

Secondary route should have lower priority than primary root. This can be accomplished via route metric settings. A primary, preferred route should have a lower metric (for example „10“), and a secondary, failover route should have a higher metric value (for example „20“). If the route fails, the cOS Core FW will constantly check status for it and if it is alive again the route is used again.

Beware if your failover setup is using different interface. For example if you have two ISP and both are connected to different interface also the rules, NATs,.. must be identical for both interfaces for the failover to work properly.  Example below. You have two failover routes for traffic to Internet and NAT is performed. However NAT is performed just for WAN interface as the second failover route was added some time after, when customer requested to increasing HA of Internet as we use now more cloud technology.