Description

In Clavister cOS Core there are many functions/features that require an active internet connection in order to function properly. This also includes license verification and without a working internet connection the firewall risk going into lockdown mode due to failure to verify the license status. To list functions/features that require access to the CSPN network:

• License verification (SECaaS / MSSP)
• Web Content Filtering (WCF)
• Intrusion Detection and Protection (IDP)
• Anti-Virus (AV)
• IP reputation (IPRep)
• Distributed Checksum Clearinghouses (DCC)

Scenario

We want to use a Clavister cOS Core firewall in transparent mode in a network and use Web Content Filtering to control which webpage category our users should be allowed access to. In the configuration we have made a single switch route between the internal and the external interfaces using all-nets as network.

In this scenario, the Web Content Filtering system is unable to contact Clavisters CSPN network to lookup URLs in the database. White listed URLs will work because a white listed URL does not need to be checked against the CSPN servers.

The reason why it does not work is because in such a transparent mode setup cOS Core will not be able to determine the following:

• The path to the DNS server
• The path to the CSPN server (if DNS works)

As an example, cOS Core will not be able to determine if access to a public IP should go through a gateway or not.

Note: WCF is just an example, the same would be applicable for all the other functions/features that requires CSPN access.

Solution

This is not a problem for users connected on either side of the switch route, but it will cause problems when cOS Core itself wants to communicate with something beyond it’s external or internal network. Since we do not have a gateway or anything configured in the main routing table, the Clavister does not know where to send the requests for addresses “beyond” the network/hosts local machines are communicating with, in this case the web content filtering server(s).

The Clavister need to have a real IP on the interface that points towards the Internet Service Providers (ISP) (the Wan_IP assigned to the Wan interface). If the Wan interface does not have a designated IP address, it would need one.

There are two ways to solve this problem (there may be others as well but these would be the most common solutions):

Solution-1: Static Routing

Add a static route for the WCF server IP’s and use the ISP’s gateway as gateway, an example:

Interface=Wan
Network=202.152.177.32
Gateway=Wan_gw

To find the IP addresses of the CSPN servers, use the CLI command “updatecenter -servers”.

But cOS Core would need access to a DNS server in order to find the CSPN server list and if the firewall is unable to resolve DNS it would be a bit of a catch-22 problem. But the same solution could also be applied for the DNS server. Example:

Interface=Wan
Network=8.8.8.8
Gateway=Wan_gw

Solution-2: A route with higher Metric than the switch route

Setup a route with a higher metric than the Switch Route by adding a route that looks something like this example:

Interface=Wan
Network=All-nets
Gateway=Wan_gw
Metric=201

(Assuming the default interface metric used by the switch route is 200 or below).

This means that for any IP address that is not included in the Switch route, the Clavister will consult the ISP’s gateway, and the MAC address of the gateway will be easy to find in the switch route (CAM/L3 Cache).

Note: This method is only possible if the Switch route is not defined as “All-nets”, but rather a specific network such as “Lannet” or “Wannet”, e.g. 192.168.10.0/16.

Related articles