| Home Prev |  cOS Core 14.00.15 Administration Guide
|
Next |
|---|
The most basic form of routing is known as Static Routing. The term "static" is used because most entries in a routing table are part of the cOS Core system's static configuration. They usually remain unchanged during long periods of system operation.
Due to this manual approach, static routing is most appropriate to use in smaller network deployments where addresses are fairly fixed and where the amount of connected networks are limited to a few. However, for larger networks, or whenever the network topology is complex, the work of manually maintaining static routing tables can be time-consuming and also problematic. Dynamic routing should therefore be used in such cases.
For more information about the dynamic routing capabilities of cOS Core, please see Section 4.7, OSPF. Note, however, that even if dynamic routing is chosen for a network, understanding the principles of static routing and how it is implemented in cOS Core is still required.
IP routing is the mechanism used in TCP/IP based networks for delivering IP packets from their source to their ultimate destination through a number of intermediary network devices. These devices are most often referred to as routers since they are performing the task of routing packets to their destination.
In each router, one or more routing tables contain a list of routes and these are consulted to find out where to send a packet so it can reach its destination. The components of a single route are discussed next.
The Components of a Route
A Route object in cOS Core can be added to a Routing Table. A Route object has following key properties:Interface
The interface to forward the packet on in order to reach the destination network. In other words, the interface to which the destination IP range is connected, either directly or through a router.
The interface might be a physical interface of the firewall or it might be a VPN tunnel (tunnels are treated like physical interfaces by cOS Core).
Network
This is the destination network IP address range which this route will reach. The route chosen from a routing table is the one that has a destination IP range which includes the IP address being sought. If there is more than one such matching route, the route chosen is the one which has the smallest IP address range.
The destination network all-nets is usually always used in the route for Internet access via an ISP.
Gateway
The IP address of the gateway which is the next router in the path to the destination network. This is optional. If the destination network is connected directly to the interface, this is not needed.
When a router lies between the firewall and the destination network, a gateway IP must be specified. For example, if the route is for Internet access via an ISP then the public IPv4 address of the ISP's gateway router would be specified.
Local IP Address
This parameter usually does not need to be specified. If it is specified, cOS Core responds to ARP queries sent to this address. A special section below explains this parameter in more depth.
Local IP Address and Gateway are mutually exclusive and either one or the other should be specified.
Metric
This is a metric value assigned to the route and is used as a weight when performing comparisons between alternate routes. If two routes are equivalent but have different metric values then the route with the lowest metric value is taken.
The metric value is also used by Route Failover and Route Load Balancing.
For more information, see Section 4.4, Route Load Balancing and Section 4.2.3, Route Failover.
A Typical Routing Scenario
The diagram below illustrates a typical routing scenario.In the above diagram, the LAN interface is connected to the network 192.168.0.0/24 and the DMZ interface is connected to the network 10.4.0.0/16. The WAN interface is connected to the network 195.66.77.0/24 and the address of the ISP gateway to the public Internet is 195.66.77.4.
The associated routing table for this would be as follows:
| Route # | Interface | Destination | Gateway |
|---|---|---|---|
| 1 | lan | 192.168.0.0/24 | |
| 2 | dmz | 10.4.0.0/16 | |
| 3 | wan | 195.66.77.0/24 | |
| 4 | wan | all-nets | 195.66.77.4 |
The above routing table provides the following information:
Route #1
All packets going to hosts on the 192.168.0.0/24 network should be sent out on the lan interface. As no gateway is specified for the route entry, the host is assumed to be located on the network segment directly reachable from the lan interface.
Route #2
All packets going to hosts on the 10.4.0.0/16 network are to be sent out on the dmz interface. Also for this route, no gateway is specified.
Route #3
All packets going to hosts on the 195.66.77.0/24 network will be sent out on the wan interface. No gateway is required to reach the hosts.
Route #4
All packets going to any host (the all-nets network will match all hosts) will be sent out on the wan interface and to the gateway with IP address 195.66.77.4. That gateway will then consult its routing table to find out where to send the packets next.
A route with the destination all-nets is often referred to as the Default Route as it will match all packets for which no specific route has been configured. This route usually specifies the interface which is connected to the Internet.
The Narrowest Routing Table Match is Selected
When a routing table is evaluated, the ordering of the routes is not important. Instead, all routes in the relevant routing table are evaluated and the most specific route is used. In other words, if two routes have destination networks that overlap, the narrower network definition will be taken before the wider one. This behavior is in contrast to IP rule set matching where the first matching entry is used.In the previous example, a packet with a destination IP address of 192.168.0.4 will theoretically match both the first route and the last one. However, the first route entry is a narrower, more specific match so the evaluation will end there and the packet will be routed according to that entry.
Although a logical routing table ordering is not crucial, it is still recommended for readability to try and place narrower routes first and a default all-nets route last.
When two or more single host routes (routes with a single IP address) match then the route chosen is random. Given no changes in the configuration and no system restart, that same route will be chosen every time.Where two or more routes with an address range match and all have the same width, then the route chosen is the one with the lowest metric (this was mentioned previously in the description of the metric property). If the metric on all of them is the same then a random choice between them is made. This random choice can explain strange behavior after a system restart, which is discussed next.
Duplicate Routes Can Explain Sudden Network Access Loss
By accident (or sometimes by design) a configuration might have two routes that both trigger for all-nets traffic. At system restart, cOS Core will randomly pick which route to use and this might mean a sudden loss of Internet access after a long period of operation without problems.This issue is discussed further in an article in Clavister Knowledge Base at the following link:
https://kb.clavister.com/324735722
The Route Index is for Display Only
When routing tables are listed in a management interface, an index number is assigned to each route and this index can then be used to manipulate the route. It should be noted that this index is not fixed and is assigned by cOS Core when the table is displayed. Manually changing the index number can be done but this may only change a route's position in the table temporarily. A system restart can completely reorder a routing table, with routes getting new index numbers. This is especially true for routes that are automatically created by cOS Core.As mentioned in the description above of routing table matching, the position of a route in a routing table has no effect on route selection.
The Local IP Address Parameter
The correct usage of the Local IP Address parameter can be difficult to understand so additional explanation can be helpful.Normally, a physical interface such as lan is connected to a single network and the interface and network are on the same network. We can say that the network is bound to a physical interface and clients on the connected network can automatically find the Clavister firewall through ARP queries. ARP works because the clients and the cOS Core interface are part of the same network.
A second network might then be added to the same physical interface via a switch, but with a new network range that does not include the physical interface's IP address. This network is said to be not bound to the physical interface. Clients on this second network will not then be able to communicate with the firewall because ARP will not function between the clients and the interface.
To solve this problem, a new route is added to cOS Core with the following parameters:
When the Default Gateway of the second network's clients is now set to the same value as the Local IP Address of the above route, the clients will be able to communicate successfully with the interface. The IP address chosen in the second network is not significant, as long as it is the same value for the Default Gateway of the clients and the Local IP Address.
The effect of adding the route with the Local IP Address is that the firewall will act as a gateway with the Local IP Address and respond to, as well as send out, ARP queries as though the interface had that IP address.
The diagram below illustrates a scenario where this feature could be used. The network 10.1.1.0/24 is bound to a physical interface that has an IP address within the network of 10.1.1.1. If we now attach a second network 10.2.2.0/24 to the interface via the switch, it is unbound since the interface's IP address does not belong to it.
By adding a route for this second network with the Local IP Address specified as 10.2.2.1, the interface will then respond to ARP requests from the 10.2.2.0/24 network. The clients in this second network must also have their Default Gateway set to 10.2.2.1 in order to reach the firewall.
This feature is normally used when an additional network is to be added to an interface but it is not desirable to change the existing IP addresses of the network. From a security standpoint, doing this can present significant risks since different networks will typically be joined together through a switch which imposes no controls on traffic passing between those networks. Caution should therefore be exercised before using this feature.
Adding an additional network to an interface is discussed further in a Clavister Knowledge Base article at the following link:
https://kb.clavister.com/324735744
All Traffic Must have Two Associated Routes
Something that is not intuitive when trying to understand routing in cOS Core is the fact that all traffic must have two routes associated with it. Not only must a route be defined for the destination network of a connection but also for the source network.The route that defines the source network simply says that the source network is found on a particular interface. When a new connection is opened, cOS Core performs a check known as a reverse route lookup which looks for this route. The source network route is not used to perform routing but instead as a check that the source network should be found on the interface where it arrived. If this check fails, cOS Core generates a default Access Rule error log message.
Even traffic destined for Core (cOS Core itself), such as ICMP ping requests must follow this rule of having two routes associated with it. In this case, the interface of one of the routes is specified as Core.
The default access rule is discussed further in an article in the Clavister Knowledge Base at the following link:
This section describes how routing is implemented in cOS Core, and how to configure static routing.
cOS Core supports multiple routing tables. A default table called main is predefined and is always present in cOS Core. However, additional and completely separate routing tables can be defined by the administrator to provide alternate routing.
Extra, user-defined routing tables can be used in two ways:
Virtual Routing associates interfaces with a particular routing table. This enables a single cOS Core installation to act as multiple virtual systems. Communication between these systems is achieved with Loopback Interfaces (see Section 4.6, Virtual Routing and also Section 3.4.9, Loopback Interfaces).
Policy Based Routing Rules can be defined which decide which of the routing tables will deal with certain types of traffic (see Section 4.3, Policy-based Routing).
The Route Lookup Mechanism
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 opened connection to 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 relevant routing table is consulted. By default, this is the predefined main table but various configuration options could be used to specify an alternate table set up by the administrator for specific traffic types (for example, Application-based Routing can force usage of a specific table for a given application.
It is important to understand that the route lookup is performed before any of the various policy rules get evaluated (for example, IP rule set lookup). Consequently, the destination interface is known at the time cOS Core decides if the connection should be allowed or dropped. This design allows for a more fine-grained control in security policies.
cOS Core Route Notation
cOS Core uses a slightly different way of describing routes compared to most other systems but this way is easier to understand, making errors less likely.Many other products do not use the specific interface in the routing table, but specify the IP address of the interface instead. The routing table below is from a Microsoft Windows based computer:
====================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x10003 ...00 13 d4 51 8d dd ...... Intel(R) PRO/1000 CT Network
0x20004 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
===================================================================
===================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.10 20
10.0.0.0 255.0.0.0 10.4.2.143 10.4.2.143 1
10.4.2.143 255.255.255.255 127.0.0.1 127.0.0.1 50
10.255.255.255 255.255.255.255 10.4.2.143 10.4.2.143 50
85.11.194.33 255.255.255.255 192.168.0.1 192.168.0.10 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.0.0 255.255.255.0 192.168.0.10 192.168.0.10 20
192.168.0.10 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.0.255 255.255.255.255 192.168.0.10 192.168.0.10 20
224.0.0.0 240.0.0.0 10.4.2.143 10.4.2.143 50
224.0.0.0 240.0.0.0 192.168.0.10 192.168.0.10 20
255.255.255.255 255.255.255.255 10.4.2.143 10.4.2.143 1
255.255.255.255 255.255.255.255 192.168.0.10 192.168.0.10 1
Default Gateway: 192.168.0.1
===================================================================
Persistent Routes:
None
The corresponding routing table in cOS Core will be similar to the following:
Flags Network Iface Gateway Local IP Metric
----- ------------------ -------- -------------- --------- ------
192.168.0.0/24 lan 20
10.0.0.0/8 wan 1
0.0.0.0/0 wan 192.168.0.1 20
cOS Core Route Definition Advantages
The cOS Core method of defining routes makes the reading and understanding of routing information easier.A further advantage with the cOS Core approach is that the administrator can directly specify a gateway for a particular route and the following is true:
A separate route does not need to be defined that includes the gateway IP address.
It does not matter even if there is a separate route which includes the gateway IP address and that routes traffic to a different interface.
Composite Subnets can be Specified
Another advantage with the cOS Core approach to route definition is that it allows the administrator to specify routes for destinations that are not aligned with traditional subnet masks.For example, it is perfectly legal to define one route for the destination IP address range 192.168.0.5 to 192.168.0.17 and another route for IP addresses 192.168.0.18 to 192.168.0.254. This is a feature that makes cOS Core highly suitable for routing in highly complex network topologies.
Displaying Routing Tables
It is important to note that routing tables that are initially configured by the administrator can have routes added, deleted and changed automatically during live operation and these changes will appear when the routing table contents are displayed.These routing table changes can take place for different reasons. For example, if dynamic routing with OSPF has been enabled then routing tables will become populated with new routes learned from communicating with other OSPF routers in an OSPF network. Other events such as route failover can also cause routing table contents to change over time.
Example 4.1. Displaying the main Routing Table
This example illustrates how to display the contents of the default main routing table.
Command-Line Interface
To see the routing table contents:
Device:/>cc RoutingTable mainDevice:/main>show Route # Interface Network Gateway Local IP - --------- -------- ------------- -------- 1 wan all-nets 213.124.165.1 <empty> 2 lan lan_net <empty> <empty> 3 wan wan_net <empty> <empty>
To return the default CLI context:
Device:/main>ccDevice:/>
To see the active routing table enter:
Device:/> routes
Flags Network Iface Gateway Local IP Metric
----- ------------------ ------- --------------- -------- ------
192.168.0.0/24 lan 0
213.124.165.0/24 wan 0
0.0.0.0/0 wan 213.124.165.1 0InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
To see the configured routing table:
The main window will list the configured routes
To see the active routing table in the Web Interface, select the Routes item in the Status dropdown menu in the menu bar - the main window will list the active routing table
![[Tip]](images/tip.png) |
Tip: The cc command may be needed to change context |
|---|---|
|
In the CLI example above, it was necessary to first select the name of a specific routing table with the cc command (meaning change category or change context) before manipulating individual routes. |
Default Static Routes are Added Automatically for Each Interface
When the Clavister firewall is started for the first time, cOS Core will automatically add a route in the main routing table for each physical interface. These routes are assigned a default IP address object in the address book and these IP objects must have their addresses changed to the appropriate range for traffic to flow.![[Note]](images/note.png) |
Note: The metric for default routes is 100 |
|---|---|
|
The metric assigned to the default routes automatically created for the physical interfaces is always 100. |
These automatically added routes cannot be removed manually by deleting them one at a time from a routing table. Instead, the properties of the interface must be selected and the advanced option Automatically add a route for this interface using the given network must be disabled. This will remove any route that was added automatically at startup. This option has no other purpose but to delete the automatically added routes.
The most important route that should be defined is the route to all-nets which usually corresponds to an ISP that provides Internet access. If using the cOS Core setup wizard, this route is also added automatically.
However, the option also exists for any physical interface to indicate that it should be used
for connection to the Internet. In the Web Interface or InControl this is an advanced setting in the
Ethernet interface properties called:
Automatically add a default route for this interface using the given default gateway.
When this option is selected, the appropriate all-nets route is automatically added to the main routing table for the interface.
Example 4.2. Adding a Route to the main Table
This example shows how an all-nets route is added to the routing table called main. This route will be for the ISP connected to the wan interface and the ISP is accessed via a router with the IP address isp_gw_ip which will be the gateway for the route.
Command-Line Interface
Change the context to be the routing table:
Device:/> cc RoutingTable mainAdd the route:
Device:/main> add Route
Interface=wan
Network=all-nets
Gateway=isp_gw_ipReturn to the default CLI context:
Device:/main>ccDevice:/>
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Routes can Contain IPv4 or IPv6 Addresses
A single route can contain either an IPv4 or IPv6 address but not both. Routes that use IPv4 and IPv6 addresses can be mixed in the same routing table. This topic is described further in Section 3.2, IPv6 Support.Routes with core as the 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 cOS Core itself. A good example for such traffic are ICMP ping messages sent to an Ethernet interface, where cOS Core itself that must handle and respond to the ping request.There is one route added for each Ethernet interface in the system. For example, if there are two interfaces named lan and wan with the IPv4 addresses 192.168.0.10 and 193.55.66.77, this will result in the following routes existing:
| Route # | Interface | Destination | Gateway |
|---|---|---|---|
| 1 | core | 192.168.0.10 | |
| 2 | core | 193.55.66.77 |
When the system receives an IP packet whose destination address is one of the interface IPs, the packet will be routed to the core interface. In other words, it is processed by cOS Core itself.
There is also a core route added for all multicast addresses:
| Route # | Interface | Destination | Gateway |
|---|---|---|---|
| 1 | core | 224.0.0.0/4 |
To include the core routes when the active routing table is displayed, it is necessary to explicitly specify that all routes are to be displayed. This is shown in the example below.
Example 4.3. Displaying the Core Routes
This example illustrates how to display the core routes in the active routing table.
Command-Line Interface
Device:/> routes -all
Flags Network Iface Gateway Local IP Metric
----- ------------------ ---------- ------------- -------- ------
127.0.0.1 core (Shared IP) 0
192.168.0.1 core (Iface IP) 0
213.124.165.181 core (Iface IP) 0
127.0.3.1 core (Iface IP) 0
127.0.4.1 core (Iface IP) 0
192.168.0.0/24 lan 0
213.124.165.0/24 wan 0
224.0.0.0/4 core (Iface IP) 0
0.0.0.0/0 wan 213.124.165.1 0InControl
This operation cannot be performed with InControl.
Web Interface
|
Tip: Understanding output from the routes command |
|---|---|
|
For detailed information about the output of the CLI routes command, refer to the separate CLI Reference Guide. |
Overview
Clavister firewalls 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.
Setting Up Route Failover
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
cOS Core will monitor the link status of the interface specified in the route. As long as the interface is up, the route is diagnosed as healthy. This method is appropriate for monitoring that the interface is physically attached and that the cabling is working as expected. As any changes to the link status are instantly noticed, this method provides the fastest response to failure.
Gateway Monitoring
If a specific gateway has been specified as the next hop for a route, accessibility to that gateway can be monitored by sending periodic ARP requests. As long as the gateway responds to these requests, the route is considered to be functioning correctly.
Host Monitoring
The first two options check the accessibility of components local to the Clavister firewall. An alternative is to monitor the accessibility of one or more nominated remote hosts. These hosts might have known high availability and polling them can indicate if traffic from the local firewall is reaching them. Host monitoring also provides a way to measure the network delays in reaching remote hosts and to initiate failover to an alternate route if delays exceed administrator-specified thresholds.
Automatically Added Routes Need Redefining
It is important to note that the route monitoring cannot be enabled on automatically added routes. For example, the routes that cOS Core creates at initial startup for physical interfaces are automatically added routes. The reason why monitoring cannot be enabled for these routes is because automatically created routes have a special status in the cOS Core configuration and are treated differently.If route monitoring is required on an automatically created route, the route should first be deleted and then recreated manually as a new route. Monitoring can then be enabled on the new route.
When specifying routes, the administrator should manually set a route's Metric. The metric is a positive integer that indicates how preferred the route is as a means to reach its destination. When two routes offer a means to reach the same destination, cOS Core will select the one with the lowest metric value for sending data (if two routes have the same metric, the route found first in the routing table will be chosen).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").
It is possible to specify more than one failover route. For instance, the primary route could have two other routes as failover routes instead of just one. In this case the metric should be different for each of the three routes: "10" for the primary route, "20" for the first failover route and "30" for the second failover route. The first two routes would have route monitoring enabled in the routing table but the last one (with the highest metric) would not since it has no route to failover to.Failover Processing
Whenever monitoring determines that a route is not available, cOS Core will mark the route as disabled and instigate route failover for existing and new connections. For already established connections, a route lookup will be performed to find the next best matching route and the connections will then switch to using the new route. For new connections, route lookup will ignore disabled routes and the next best matching route will be used instead.The table below defines two default routes, both having all-nets as the destination, but using two different gateways. The first, primary route has the lowest metric and also has route monitoring enabled. Route monitoring for the second, alternate route is not meaningful since it has no failover route.
| Route # | Interface | Destination | Gateway | Metric | Monitoring |
|---|---|---|---|---|---|
| 1 | wan | all-nets | 195.66.77.1 | 10 | On |
| 2 | wan | all-nets | 193.54.68.1 | 20 | Off |
When a new connection is about to be established to a host on the Internet, a route lookup will result in the route that has the lowest metric being chosen. If the primary WAN router should then fail, this will be detected by cOS Core, and the first route will be disabled. As a consequence, a new route lookup will be performed and the second route will be selected with the first one being marked as disabled.
Even if a route has been disabled, cOS Core will continue to check the status of that route. Should the route become available again, it will be re-enabled and existing connections will automatically be transferred back to it.Route Interface Grouping
When using route monitoring, it is important to check if a failover to another route will cause the routing interface to be changed. If this could happen, it is necessary to take some precautionary steps to ensure that policies and existing connections will be maintained.To illustrate the problem, consider the following configuration:
First, there is one IP rule set entry that will NAT all HTTP traffic destined for the Internet through the wan interface:
| Action | Src Iface | Src Net | Dest Iface | Dest Net | Parameters |
|---|---|---|---|---|---|
| Allow/NAT | lan | lan_net | wan | all-nets | http-all |
The routing table consequently contains the following default route:
| Interface | Destination | Gateway | Metric | Monitoring |
|---|---|---|---|---|
| wan | all-nets | 195.66.77.1 | 10 | Off |
Now a secondary route is added over a backup DSL connection and route monitoring is enabled for this. The updated routing table will look like this:
| Route # | Interface | Destination | Gateway | Metric | Monitoring |
|---|---|---|---|---|---|
| 1 | wan | all-nets | 195.66.77.1 | 10 | On |
| 2 | dsl | all-nets | 193.54.68.1 | 20 | Off |
Notice that route monitoring is enabled for the first route but not the backup, failover route.
As long as the preferred wan route is healthy, everything will work as expected. route monitoring will also be functioning, so the secondary route will be enabled if the wan route should fail.
However, there are some problems with this setup: if a route failover occurs, the default route will then use the dsl interface. When a new HTTP connection is established, a route lookup will be made resulting in a destination interface of dsl. The IP rule set will then be evaluated, but the original NAT IP policy assumes the destination interface to be wan so the new connection will be dropped by the rule set.
In addition, any existing connections matching the NAT rule will also be dropped as a result of the change in the destination interface. Clearly, this is undesirable.
To overcome this issue, potential destination interfaces should be grouped together into an Interface Group and the Security/Transport Equivalent option should be enabled for the group so that connections can be moved between interfaces. The interface group is then used as the destination interface when setting policies. For more information on interface groups, see Section 3.4.10, Interface Groups.
By default cOS Core generates a gratuitous ARP request when a route failover occurs. The reason for this is to notify surrounding systems that there has been a route change. This behavior can be controlled by the advanced setting Gratuitous ARP on Fail (this is found in the Web Interface in Network > Routing > Routing Settings). When the route failover feature is used with IPsec tunnels, some extra considerations are required. This topic is covered by an article in the Clavister Knowledge Base at the following link:Overview
To provide a more flexible and configurable way to monitor the integrity of routes, cOS Core provides the additional capability to perform Host Monitoring. This feature means that one or more external host systems can be routinely polled to check that a particular route is available.This is similar in concept to the monitoring used for the Server Load Balancing feature in cOS Core (see Section 11.3.5, SLB Server Monitoring) but there are important differences.
The advantages of host monitoring are twofold:
In a complex network topology it is more reliable to check accessibility to external hosts. Just monitoring a link to a local switch may not indicate a problem in another part of the internal network.
Host monitoring can be used to help in setting the acceptable Quality of Service level of Internet response times. Internet access may be functioning but it may be desirable to instigate route failover if response latency times become unacceptable using the existing route.
Enabling Host Monitoring
Host monitoring can be enabled as a property of a Route object and a single route can have multiple hosts associated with it for monitoring. Multiple hosts can provide a higher certainty that any network problem resides in the local network rather than because one remote host itself is down.In association with host monitoring there are two numerical parameters for a route:
Specifying Hosts
For each host specified for host monitoring, there are a number of property parameters that should be set:Method
The method by which the host is to be polled. This can be one of:
ICMP - ICMP "Ping" polling. An IP address must be specified for this.
TCP - A TCP connection is established to and then disconnected from the host. An IP address must be specified for this.
HTTP - A normal HTTP server request using a URL. A URL must be specified for this as well as a text string which is the beginning (or complete) text of a valid response. If no text is specified, any response from the server will be valid.
IP Address
The IP address of the host when using the ICMP or TCP option.
Port Number
The port number for polling when using the TCP option.
Source IP Selection
The source IP for the outgoing monitoring packets can be set to a specific value. By default, the IP address of the sending interface is used (the Automatic option) but it can be set by setting this property to Manual and specifying an IP address.
Interval
The interval in milliseconds between polling attempts. The default setting is 10,000 and the minimum value allowed is 100 ms.
Sample
The number of polling attempts used as a sample size for calculating the Percentage Loss and the Average Latency. This value cannot be less than 1.
Maximum Failed Poll Attempts
The maximum permissible number of polling attempts that fail. If this number is exceeded then the host is considered unreachable.
Max Average Latency
The maximum number of milliseconds allowable between a poll request and the response. If this threshold is exceeded then the host is considered unreachable. Average Latency is calculated by averaging the response times from the host. If a polling attempt receives no response then it is not included in the averaging calculation.
The Reachability Required Option
An important option that can be enabled for a host is the Reachability Required option. When this is selected, the host must be determined as accessible in order for that route to be considered to be functioning. Even if other hosts are accessible, this option says that the accessibility of a host with this option set is mandatory.Where multiple hosts are specified for host monitoring, more than one of them could have Reachability Required enabled. If cOS Core determines that any host with this option enabled is not reachable, Route Failover is initiated.
HTTP Parameters
If the HTTP polling method is selected then two further parameters can be entered:Request URL
The URL which is to be requested.
Expected Response
The text that is expected back from querying the URL.
Testing for a specific response text provides the possibility of testing if an application is offline. If, for example, a web page response from a server can indicate if a specific database is operational with text such as "Database OK", then the absence of that response can indicate that the server is operational but the application is offline.
A Known Issue When No External Route is Specified
With connections to an Internet ISP, an external network route should always be specified. This external route specifies on which interface the network which exists between the Clavister firewall and the ISP can be found. If only an all-nets route is specified to the ISP's gateway, route failover may, depending on the connected equipment, not function as expected.This issue rarely occurs but the reason why it occurs is that ARP queries arriving on a disabled route will be ignored.
The following advanced routing settings are available for route failover and these can be found in the Web Interface by going to Network > Routing > Routing Settings:
Iface poll interval
The time in milliseconds between polling for interface failure.Default: 500
ARP poll interval
The time in milliseconds between ARP-lookup of hosts. This may be overridden in individual routes.Default: 1000
Ping poll interval
The time in milliseconds between sending a Ping to hosts.Default: 1000
Grace time
The length of time in seconds between startup or reconfigure and monitoring start.Default: 30
consecutive fails
The number of consecutive failures that occurs before a route is marked as being unavailable.Default: 5
Consecutive success
The number of consecutive successes that must occur before a route is marked as being available.Default: 5
Gratuitous ARP on fail
Send a gratuitous ARP on HA failover to alert hosts of the changes in interface Ethernet and IP addresses.Default: Enabled
Overview
As discussed previously in Section 3.5, ARP, the ARP protocol facilitates a mapping between an IP address and the MAC address of a host on an Ethernet network.However, situations may exist where a network running Ethernet is separated into two parts with a routing device such as a Clavister firewall in between. In such a case, cOS Core itself can respond to ARP requests directed to the network on the other side of the firewall using the feature known as Proxy ARP.
The splitting of an Ethernet network into distinct parts so that traffic between them can be controlled is a common usage of the proxy ARP feature. cOS Core rule sets can then be used to impose security policies on the traffic passing between the different network parts.
A Typical Scenario
As an example of a typical proxy ARP scenario, consider a network split into two sub-networks with a Clavister firewall between the two.Host A on one sub-network might send an ARP request to find out the MAC address for the IP address of host B on the other sub-network. With the proxy ARP feature configured, cOS Core responds to this ARP request instead of host B. cOS Core sends its own MAC address in reply, pretending to be the target host. After receiving the reply, Host A then sends data directly to cOS Core which forwards the data to host B. In the process cOS Core checks the traffic against the configured rule sets.
Setting Up Proxy ARP
Setting up proxy ARP is done by specifying the option for a route in a routing table. Suppose there is a network that is divided into two parts called net_1 and net_2.The network net_1 is connected to the interface if1 and the network net_2 is connected to the interface if2. In cOS Core there will be a route configured that says net_1 can be found on if1. This might be called route_1.
For route_1 it is possible to specify the option that this network should be proxy ARPed on interface if2. Now any ARP request issued by a net_2 host connected to if2 looking for an IP address in net_1 will get a positive response from cOS Core. In other words, cOS Core will pretend that the net_1 address is found on if2 and will forward data traffic to net_1.
In the same way, net_2 could be published on the interface if1 so that there is a mirroring of routes and ARP proxy publishing.
| Route # | Network | Interface | Proxy ARP Published |
|---|---|---|---|
| 1 | net_1 | if1 | if2 |
| 2 | net_2 | if2 | if1 |
In this way there is complete separation of the sub-networks but the hosts are unaware of this. The routes are a pair which are a mirror image of each other but there is no requirement that proxy ARP is used in a pairing like this.
Keep in mind that if the host has an ARP request for an IP address outside of the local network then this will be sent to the gateway configured for that host. The entire example is illustrated below.
Transparent Mode as an Alternative
Transparent Mode is an alternative and preferred way of splitting Ethernet networks. Setup is simpler than using proxy ARP since only the appropriate switch routes need to be defined. Using switch routes is fully explained in Section 4.9, Transparent Mode.Proxy ARP depends on static routing where the location of networks on interfaces are known and usually fixed. Transparent mode is more suited to networks whose interface location can change.
Proxy ARP and High Availability Clusters
In HA clusters, switch routes cannot be used and transparent mode is therefore not an option. However, proxy ARP does function with HA and is consequently the only way to implement transparent mode functionality with a cluster. |
Note: Not all interfaces can make use of Proxy ARP |
|---|---|
|
It is only possible to have Proxy ARP functioning for Ethernet and VLAN interfaces. Proxy ARP is not relevant for other types of cOS Core interfaces since ARP is not involved. |
Automatically Added Routes
Proxy ARP cannot be enabled for automatically added routes. For example, the routes that cOS Core creates at initial startup for Ethernet interfaces are automatically added routes. The reason why Proxy ARP cannot be enabled for these routes is because automatically created routes have a special status in the cOS Core configuration and are treated differently.If Proxy ARP is required on an automatically created route, the route should first be deleted and then manually recreated as a new route. Proxy ARP can then be enabled on the new route.
Proxy ARP can be used to divide up a public IPv4 across cOS Core interfaces. The steps to do this are described in an article in the Clavister Knowledge Base at the following link:Broadcast packets are those packets which have the highest IP address in their network and will have an associated MAC address of FF:FF:FF:FF:FF:FF. For example, a broadcast packet for the network 192.168.1.0/24 will have the IPv4 address 192.168.1.255.
By default, cOS Core will drop all such broadcast packets arriving at an interface. In some situations, particularly when using transparent mode, it is desirable for cOS Core to forward these packets to another interface by doing a route lookup and also applying IP rule set entries to determine if the traffic should be forwarded.
Enabling Broadcast Packet Forwarding
To enable broadcast packet forwarding, the administrator should perform the following steps:Enable the Forward Broadcast Traffic property on a Route object (the BroadcastFwd property in the CLI). However, this must always be done on the routes for both the packet's source and destination interface.
For non-transparent mode traffic only, the global IP setting Direct Broadcast must be enabled for broadcast forwarding to work. The setting's value is DropLog by default and it must be set to Ignore or Log for broadcast packets to be forwarded.
Even with broadcast packet forwarding enabled, cOS Core will still perform a check on broadcast packets arriving at an interface to ensure that a broadcast IPv4 address matches with a FF:FF:FF:FF:FF:FF MAC address. Packets with a mismatch are dropped.
Using Address Translation with Broadcast Forwarding
The following should be noted if address translation is used with broadcast forwarded traffic.SAT
SAT translation can be used with broadcast packets if appropriate. With SAT translation the destination address would always be the broadcast address.
NAT
NAT translation cannot be used with broadcast packets in transparent mode. The packets will be dropped and a log message will be generated when they encounter the NAT IP policy.
NAT can be used with broadcast packets in non-transparent mode routing. This might be appropriate in some unusual networking scenarios.
Transparent Mode Broadcast Forwarding is Always Stateless
It is important to note that broadcast packets are always forwarded statelessly by cOS Core when in transparent mode. In other words, even if an IP rule set entry with an action of Allow permits transparent mode broadcast packets to flow, they will be forwarded as though the entry was a Stateless Policy (or a FwdFast IP rule).The reason for enforcing stateless forwarding is because packets may need to be duplicated and transmitted on multiple interfaces. For normal, non-transparent routes where broadcast packets are not duplicated, a normal Allow rule or policy could be used and the traffic will be treated statefully. A stateful IP policy has the advantage of using less processing resources to process broadcast packets when many are coming from the same source.
Only Triggering an IP Policy on Broadcast Packets
When creating an IP policy which triggers only on broadcast packets, the Destination Network property should be set to be the broadcast IP address. However, the Source Network should be the network to which the broadcast address belongs. For example, a broadcast packet for the IPv4 network 10.0.0.0/8 will have the address 10.255.255.255 (the highest IP address in the network). So in an IP rule set entry targeting these packets, the Source Network property should be set to 10.0.0.0/8 and the Destination Network property should be set to 10.255.255.255.Log Messages for Broadcast Packets
Log messages are only generated for broadcast packets that trigger an IP rule set entry when in transparent mode (using switch routes). There are only two messages that can be generated:allow_broadcast
This log message is generated each time a broadcast packet triggers an IP rule set entry with an action of Allow in transparent mode. It indicates that the packet has been forwarded statelessly as though the rule had an action of FwdFast (or the policy was a Stateless Policy). A typical log message of this type will look similar to the following:
prio=Notice id=06000016 rev=1 event=allow_broadcast action=stateless_fwd rule=a recvif=If3 srcip=192.168.100.25 destip=192.168.100.255 ipproto=UDP ipdatalen=58 srcport=137 destport=137 udptotlen=58
It should be noted that this event message will be generated for every interface that the broadcast packet is sent on. For example, if interfaces if1, if2 and if3 are all defined as being on the same network using transparent mode, a broadcast packet for the network could trigger an IP policy twice, generating two log messages. This is because the broadcast packet would arrive on one interface and would need transmitting on the other two.
All these multiple log messages can be turned off by disabling log messages on the triggering IP policy.
broadcast_nat
This is generated when a broadcast packet has triggered a NAT IP policy in transparent mode and has been dropped. A typical log message of this type will look similar to the following:
prio=Notice id=06000014 rev=1 event=broadcast_nat action=drop rule=a recvif=If3 srcip=192.168.100.25 destip=192.168.100.255 ipproto=UDP ipdatalen=58 srcport=137 destport=137 udptotlen=58
Broadcast packets triggering a NAT rule can optionally be dropped silently with a log message being generated. This is controlled by a global setting called TransparentBroadcastNAT. The default value for this setting is DropLog. This should be set to Drop if no log messages are to be generated.
Example 4.4. Enabling Broadcast Forwarding on a Route
This example shows how to enable broadcast packet forwarding on an existing route called my_route which is the third route in the main routing table.
Command-Line Interface
First, enable broadcast forwarding globally for non-transparent mode traffic:
Device:/> set Settings IPSettings DirectedBroadcasts=Log
Next, enable broadcasting forwarding on the relevant route. Change the context to be the main routing table:
Device:/> cc RoutingTable mainAdd the route:
Device:/main> set Route 3 BroadcastFwd=YesReturn to the default CLI context:
Device:/main>ccDevice:/>
InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
First, enable broadcast forwarding globally for non-transparent mode traffic:
Next, enable broadcasting forwarding on the relevant route:
