Interfaces in Clavister FW

In every network device there is source and destination interface. In clavister there is also Core interface which refers to the clavister fw itself. cOS Core supports a number of interface types, which can be divided into the following four major groups:

  • Ethernet Interfaces – Each Ethernet interface represents a physical Ethernet interface on a cOS Core-based product.
  • Sub-interfaces – Some interfaces require a binding to an underlying physical interface in order to transfer data. This group of interfaces is called Physical Sub-Interfaces. There are two subinterfaces, the VLAN subint and PPPoE subint.
  • Tunnel Interface – Tunnel interfaces are used when network traffic is being tunneled between the system and another tunnel end-point in the network, before it gets routed to its final destination. VPN tunnels are often used to implement virtual private networks (VPNs) which can secure communication between two security gateways. cOS Core supports following tunnel interfaces – IPsec, PPTP/L2TP, GRE. To set up gre or ipsec interface check the administration guide for further details.
  • Loopback Interfaces – A loopback interface is a special type of interface that will take all packets sent through it and pass them on out through the loopback interface configured as the one to loop to. These are almost exclusively used for Virtual Routing scenarios.

All Interfaces are Logically Equivalent

Even though the different types of interfaces may be very different in the way they function, cOS Core treats all interfaces as logically equivalent. This is an important and powerful concept and
means that all types of interfaces can be used interchangeably in the various cOS Core rule sets and other configuration objects. This results in a high degree of flexibility in how traffic can be
examined, controlled and routed.

Interfaces have Unique Names

Each interface in cOS Core is given a unique name to be able to identify and select it for use with other cOS Core objects in a configuration. Some interface types, such as physical Ethernet interfaces, are already provided by cOS Core with relevant default names that are possible to modify if required. New interfaces defined by the administrator will always require a user-provided name to be specified.

The any and core Interfaces

In addition, cOS Core provides two special logical interfaces which are named any and core. The meaning of these are:

  • any represents all possible interfaces including the core interface.
  • core indicates that it is cOS Core itself that will deal with traffic to and from this interface. Example of using core interface is when you creating ICMP reply rules for FW or your FW is VPN gateway.

Using CLI for Interfaces

Device:/> show Address IP4Address<tab>

Device:/> show EthernetDevice

Link Aggregation

Where individual physical Ethernet interfaces of a Clavister Security Gateway cannot provide the bandwidth required for a specific stream of traffic, it is possible to use the cOS Core Link Aggregation feature to combine two or more physical interfaces together so they act as one logical cOS Core interface. A logical Link Aggregation object could then be created which combines the capacities of three physical interfaces. This object can then be used in the cOS Core configuration like any other interface and can be part of the Route and the IPRule or IPPolicy objects that govern the traffic flow.

Link aggregation modes are like in Cisco – Static and LACP. Static is not recommended as if one interface is not working properly the FW still forward traffic to this interface. There is no negotiation in place between cOS Core FW and switch. LACP is negotiated mode. If you bundle interfaces together you must refer the bundle in policy rules.

Interface groups

Any set of cOS Core interfaces can be grouped together into an Interface Group. This then acts as a single cOS Core configuration object which can be used in creating security policies in the place of a single group. When a group is used, for example, as the source interface in an IP rule, any of the interfaces in the group could provide a match for the rule.