Connecting to CSPN when using cOS Core in transparent mode

Last modified on 13 Apr, 2023. Revision 5
In cOS Core there are many functions and features that require access to the Clavister Service Provisioning Network (CSPN) such as Web Content Filtering, Anti-Virus, Intrusion Detection, license verifications and more. This guide will discuss how to solve the connectivity problem to CSPN when using the firewall in transparent mode.
Up to date for
cOS Core 14.00.09
Supported since
cOS Core 9.30.xx
Status OK
Author
Peter Nilsson


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

Setup of a Layer-3 bridge over IPsec in cOS Core
12 Apr, 2023 core proxyarp arp ipsec routing
cOS Core IKEv2 split tunneling with Windows and local user database.
28 Mar, 2023 ikev2 windows vpn routing splittunneling
Problem with auto-created Core routes
22 Mar, 2021 core ipsec routing
Setting up OSPF with IPsec in cOS Core
21 Dec, 2023 core routing ospf ipsec
Using /31 network masks in cOS Core (RFC-3021)
1 Jun, 2022 core routing management
Using Multicast DNS with cOS Core
24 May, 2021 core howto mdns multicast transparentmode airprint igmp dns
The meaning of the Default_Access_Rule log entry
7 Nov, 2022 core arp log routing
Transparent mode & L2TPv3 unavailable in cOS Core HA clusters
17 Feb, 2023 core ha cluster transparentmode l2tpv3
Troubleshooting cOS Core rules/routes with ping simulation
17 Mar, 2023 core routing rules ping icmp cli
Is Statless (FwdFast) faster than a normal IP policy?
27 Jan, 2021 core stateless routing brokenlink
Route failover with IPsec tunnels in cOS Core
13 Feb, 2023 ipsec core routing failover
Public network transparency using cOS Core Proxy ARP instead of subnetting
18 Apr, 2023 core routing transparentmode proxyarp