This section describes initial cOS Core configuration performed directly through the Web Interface, without using the setup wizard. Configuration is done as a series of individual steps, giving the administrator more direct control over the process. Even if the wizard is used, this section can also be read as a good introduction to using the Web Interface for configuring key aspects of cOS Core.

Ethernet Interfaces

The physical connection of external networks to the firewall is through the various Ethernet interfaces which are provided by the hardware platform. In a virtual environment, these are the virtual interfaces provided by the hypervisor. On first-time startup, cOS Core scans for these interfaces and determines which are available and allocates their names. The first interface detected in the scan always becomes the initial default management interface and this cannot be changed beforehand.

All cOS Core interfaces are logically equal for cOS Core and although their physical capabilities may be different, any interface can perform any logical function. With cOS Core under KVM, the virtual If1 interface is always the default management interface. Assuming the normal KVM total of 3 virtual interfaces, the other two virtual interfaces will automatically be given the names If2 and If3 by cOS Core. For this section, we will assume that the If2 interface will be used for connection to the public Internet and the If1 interface will also be used for connection to a protected, local network.

Changing the admin Password

It is strongly recommended to change the password of the admin user as the first task in manual cOS Core setup. This is done by first selecting the System option from the Web Interface toolbar and then Local User Databases from the navigation pane to display the local user database list, as shown below.

Next, select AdminUsers to display the contents of this predefined database.

Select the Users option for the database to display a list of users and then select the default user Admin to open a dialog to change its password.

By default, using a strong admin password will be enforced meaning that the new password must comply with a set of strong password conventions. Activating configuration changes will not be possible while the password does not comply. The only way around this is to first turn off the strong password policy in the configuration but this is not recommended.

Setting the Date and Time

Many cOS Core functions rely on an accurate date and time, so it is important that this is set correctly. To do this, select System > Device > Date and Time. The current system time is displayed and this can be changed by selecting the date and time fields then manually entering the desired figures. Pressing the Set button will then set the time to the entered values.

Also choose the correct time zone from the Location drop-down list. The default location is ClavisterHQ which is Stockholm time.

Alternatively, the Synchronize button can be pressed to get the current date and time from the configured Network Time Protocol (NTP) server. In the default configuration, Clavister's own NTP server is automatically configured. However, accessing this server requires Internet access.

Configuring a custom NTP server configuration is shown below.

Once the values are set correctly, we can press the OK button to save the values while we move on to more steps in cOS Core configuration. Although changed values like this are saved by cOS Core, they do not become active until the entire saved configuration becomes the current and active configuration. We will look at how to do this next.

Activating Configuration Changes

To activate any cOS Core configuration changes made so far, select the Save and Activate option from the Configuration menu (this procedure is also referred to as deploying a configuration).

A dialog is then presented to confirm that the new configuration is to become the running configuration.

After clicking OK, cOS Core reconfiguration will take place and, after a short delay, the Web Interface will try and connect again to the firewall.

If no reconnection is detected by cOS Core within 30 seconds (this length of time is a setting that can be changed) then cOS Core will revert back to the original configuration. This is to ensure that the new configuration does not accidentally lock out the administrator. After reconfiguration and successful reconnection, a success message is displayed indicating successful reconfiguration.

Reconfiguration is a process that the cOS Core administrator may initiate often. Normally, reconfiguration takes a brief amount of time and causes only a slight delay in traffic throughput. Active user connections through the firewall should rarely be lost.

Automatic Logout

If there is no activity through the Web Interface for a period of time (the default is 15 minutes), cOS Core will automatically log the user out. If they log back in through the same web browser session then they will return to the point they were at before the logout occurred and no saved (but not yet activated) changes are lost.

Setting Up Internet Access

Next, we shall look at how to set up public Internet access with the CLI. There are four options for setting up access which are listed below and then described in detail.

A. Static - manual configuration.

B. DHCP - automatic configuration.

C. PPPoE setup

D. PPTP setup

The individual manual steps to configure these connection alternatives with the Web Interface are discussed next.

A. Static - manual configuration

Manual configuration means that there will be a direct connection to the ISP and all the relevant IP addresses for the connecting interface are fixed values provided by the ISP which are entered into cOS Core manually.

The initial step is to set up a number of IPv4 address objects in the cOS Core Address Book. Let us assume that the interface used for Internet connection is to be If2 and that the static IPv4 address for this interface is to be 203.0.113.35, the ISP's gateway IPv4 address is 203.0.113.1, and the network to which they both belong is 203.0.113.0/24.

Now, add the gateway IP4 Address object using the address book name wan_gw and assign it the IPv4 address 203.0.113.1. The ISP's gateway is the first router hop towards the public Internet from the firewall. Go to Objects > Address Book in the Web Interface.

The current contents of the address book will be listed and will contain a number of predefined objects automatically created by cOS Core after it scans the interfaces for the first time. The screenshot below shows the initial address book for the firewall.

All the Ethernet interface related address objects are gathered together in an Address Book Folder called InterfaceAddresses. By clicking on this folder, it will be opened and the individual address objects it contains can be viewed. Predefined addresses in the folder are shown below.

On initial startup, two IPv4 address objects are created automatically for each interface detected by cOS Core. One IPv4 address object is named by combining the physical interface name with the suffix "_ip" and this is used for the IPv4 address assigned to that interface. The other address object is named by combining the interface name with the suffix "_net" and this is the network to which the interface belongs.

Now click the Add button at the top left of the list and choose the IP4 Address option to add a new address to the folder.

Enter the details of the object into the properties fields for the IP4 Address object. Below, the IPv4 address 203.0.113.1 has been entered for the address object called wan_gw. This is the IP of the ISP's router which acts as the gateway to the public Internet.

Click the OK button to save the values entered.

Then set up If2_ip to be 203.0.113.35. This is the IPv4 address of the If2 interface which will connect to the ISP's gateway.

Lastly, set the IP4 Address object If2_net to be 203.0.113.0/24. Both the address objects If2_ip and wan_gw must belong to the same network in order for the interface to communicate with the ISP.

Together, these three IPv4 address objects will be used to configure the interface connected to the Internet which, in this example, is If2. Select Network > Interfaces and VPN > Ethernet to display a list of the physical interfaces and address book objects assigned to them. The first lines of the default interface list are shown below.

Click on the interface in the list which is to be connected to the Internet. The properties for this interface will now appear and the settings can be changed including the default gateway.

Press OK to save the changes. Although changes are remembered by cOS Core, the changed configuration is not yet activated and won't be activated until cOS Core is told explicitly to use the changed configuration.

Remember that DHCP should not be enabled when using static IP addresses and also that the IP address of the Default Gateway (which is the ISP's router) must be specified. As explained in more detail later, specifying the Default Gateway also has the additional effect of automatically adding a route for the gateway in the cOS Core routing table.

At this point, the connection to the Internet is configured but no traffic can flow to or from the Internet since all traffic needs a minimum of the following two cOS Core configuration objects to exist before it can flow through the firewall :

An IP policy therefore needs to be defined that will allow traffic from clients to the Internet. In this case, that web browsing is to be allowed from the protected private network If1_net connected to the interface If1.

To do this, first go to Policies > Firewalling > Main IP Rules. The main IP rule set will now be displayed.

To add a new IP policy, press the Add button and select IP Policy from the menu.

The properties for the new object will appear. In this example, the policy will be called lan_to_wan. The Service is set to http-all which is suitable for most web browsing (it allows both HTTP and HTTPS connections).

The destination network is specified as the predefined IP4 Address object all-nets. This is used since it cannot be known in advance to which IP address web browsing will be directed and all-nets allows browsing to any IP address. IP rule sets are processed in a top down fashion, with the search ending at the first matching entry. An all-nets entry like this should be placed towards the end of the rule set since other rules with narrower destination addresses should trigger first.

In addition to entering the above for the policy, the Source Translation should be set to NAT and the Address Action left as Outgoing Interface IP. Note that the default source translation value for an IP policy is Auto and this would also provide NAT translation between a private and public IP address but NAT is specified explicitly in this section for clarity.

By using NAT, cOS Core will use the destination interface's IP address as the source IP. This means that external hosts will send their responses back to the interface IP and cOS Core will automatically forward the traffic back to the originating local host. Only the outgoing interface therefore needs to have a public IPv4 address and the internal network topology is hidden.

For web browsing, public DNS lookup also needs to be allowed in order to resolve URLs into IP addresses. The service http-all does not include the DNS protocol so a similar IP rule set entry that allows this is needed. This could be done with a single IP policy that uses a custom service which combines the HTTP and DNS protocols but the recommended method is to create an entirely new IP set entry that specifies the service as dns-all. This method provides the most clarity when the configuration is examined for any problems. The screenshot below shows a new IP policy called lan_to_wan_dns being created to allow DNS.

As was done for HTTP, NAT should also be enabled with this IP policy so all DNS queries are sent out by cOS Core with the outgoing interface's IP address as the source IP.

For the Internet connection to work, a route also needs to be defined so that cOS Core knows on which interface the web browsing traffic should leave the firewall. This route will define the interface where the network all-nets (in other words, any network) will be found. If the default main routing table is opened by going to Network > Routing > Routing Tables > main, the route needed should appear as shown below.

This required all-nets route is, in fact, added automatically after specifying the Default Gateway for a particular Ethernet interface and this was done earlier when setting up the required IP4 Address objects.

As part of the setup, it is also recommended that at least one DNS server is also defined in cOS Core. This DNS server or servers (a maximum of three can be configured) will be used when cOS Core itself needs to resolve URLs which is the case when a URL is specified in a configuration object instead of an IP address. It is also important for certificate handling

Assume an IPv4 address object called wan_dns1 has already been defined in the address book and this is the address for the first DNS server. By choosing System > Device > DNS, the DNS server dialog will open and this object from the address book can be assigned as the first server.

B. DHCP - automatic configuration

All the required IP addresses for Internet connection can, alternatively, be automatically retrieved from an ISP's DHCP server by enabling the DHCP Client option for the interface connected to the ISP. This option is enabled by first selecting Network > Interfaces and VPN > Ethernet to display a list of all the interfaces.

Click the If2 interface in the list to display its properties and select the option to enable the interface as a DHCP client.

Usually, a DHCP Host Name does not need to be specified but can sometimes be used by an ISP to uniquely identify this firewall as a particular DHCP client to the ISP's DHCP server.

On connection to the ISP, all required IP addresses are retrieved automatically from the ISP via DHCP and cOS Core automatically sets the relevant address objects in the address book with this information.

For cOS Core to know on which interface to find the public Internet, a route has to be added to the main cOS Core routing table which specifies that the network all-nets can be found on the interface connected to the ISP and this route must also have the correct Default Gateway IP address specified. This all-nets route is added automatically by cOS Core during the DHCP address retrieval process.

After all IP addresses are set via DHCP and an all-nets route is added, the connection to the Internet is configured but no traffic can flow to or from the Internet since there is no IP rule set entry defined that allows it. As was done in the previous option (A) above, we must therefore define an IP policy that will allow traffic from the source network If1_net and source interface If1 to flow to the destination network all-nets and the destination interface If2.

C. PPPoE setup

For PPPoE connection, we must create a PPPoE tunnel interface associated with the physical Ethernet interface. Assume that the physical interface is If2 and the PPPoE tunnel object created is called wan_pppoe. Go to Network > Interfaces and VPN > PPPoE and select Add > PPPoE Tunnel. These values can now be entered into the PPPoE Tunnel properties dialog.

An ISP will supply the correct values for pppoe_username and pppoe_password in the dialog above.

The PPPoE tunnel interface can now be treated exactly like a physical interface by the policies defined in cOS Core rule sets.

There also has to be a route associated with the PPPoE tunnel to allow traffic to flow through it, and this is automatically created in the main routing table when the tunnel is defined. If we go to Network > Routing > Routing Tables > main we can see this route.

If the PPPoE tunnel object is deleted, this route is also automatically deleted.

At this point, no traffic can flow through the tunnel since there is no IP rule set entry defined that allows it. As was done in option A above, we must define an IP policy that will allow traffic from the source network If1_net and source interface If1 to flow to the destination network all-nets and the destination interface. Here, the destination interface is the PPPoE tunnel that has been defined.

D. PPTP setup

For PPTP connections, a PPTP client tunnel interface object needs to be created. Let us assume that the PPTP tunnel will be called wan_pptp with a remote endpoint 203.0.113.1 which has been defined as the IP4 Address object pptp_endpoint. Go to Network > Interfaces and VPN > PPTP/L2TP Clients and select Add > PPTP/L2TP Client. The values can now be entered into the properties dialog and the PPTP option should be selected.

An ISP will supply the correct values for pptp_username, pptp_password and the remote endpoint. An interface is not specified when defining the tunnel because this is determined by cOS Core looking up the Remote Endpoint IP address in its routing tables.

The PPTP client tunnel interface can now be treated exactly like a physical interface by the policies defined in cOS Core rule sets.

There also has to be an associated route with the PPTP tunnel to allow traffic to flow through it, and this is automatically created in the main routing table when the tunnel is defined. The destination network for this route is the Remote Network specified for the tunnel and for the public Internet this should be all-nets.

If we go to Network > Routing > Routing Tables > main we can see this route.

If the PPTP tunnel object is deleted, this route is also automatically deleted.

At this point, no traffic can flow through the tunnel since there is no IP rule entry defined that allows it. As was done in option A above, we must define an IP policy that will allow traffic from a designated source network and source interface (in this example, the network If1_net and interface If1) to flow to the destination network all-nets and the destination interface which is the PPTP tunnel that has been defined.

DHCP Server Setup

If the firewall is to act as a DHCP server then this can be set up in the following way:

First, create an IP4 Address object which defines the address range to be handed out. Here, it is assumed that this has the name dhcp_range. It is also assumed that another IP4 Address object dhcp_netmask has been created which specifies the netmask.

We now create a DHCP server object called my_dhcp_server which will only be available on the If1 interface. To do this, go to Network > Network Services > DHCP Servers and select Add > DHCP Server. The server properties can now be specified.

An example IP pool range might be 196.168.1.10 - 192.168.1.20 with a netmask of 255.255.0.0.

In addition, it is important to specify the Default gateway for the server. This will be handed out to DHCP clients on the internal networks so that they know where to find the public Internet. The default gateway is always the IPv4 address of the interface on which the DHCP server is configured, in this case, If1_ip. To set the default gateway, select the Options tab.

Also in the Options tab, we should specify the DNS address which is handed out with DHCP leases. This could be set, for example, to be the IPv4 address object dns1_address.

Syslog Server Setup

Although logging may be enabled, no log messages are captured unless at least one log server is set up to receive them and this is configured in cOS Core. Syslog is one of the most common server types.

First we create an IP4 Address object called, for example, syslog_ip which is set to the IPv4 address of the server. We then configure the sending of log messages to a Syslog server from cOS Core by selecting System > Device > Log and Event Receivers and then choosing Add > Syslog Receiver.

The Syslog server properties dialog will now appear. We give the server a name, for example my_syslog, and specify its IPv4 address as the syslog_ip object.

Allowing ICMP Ping Requests

As a further example of setting up IP rule set entries, it can be very useful to allow ICMP Ping requests to flow through the firewall. As discussed earlier, the cOS Core will drop any traffic unless a rule set entry explicitly allows it. Let us suppose that we wish to allow the pinging of external hosts with the ICMP protocol by computers on the internal network G1_net.

There can be several IP rule sets defined in cOS Core but there is only one rule set defined by default and this is called main. To add an entry to it, first select Policies > Firewalling > Main IP Rules.

The main rule set list contents are now displayed. Press the Add button and select IP Policy.

The properties for a new IP policy will appear and we can add the entry, in this case called allow_ping_outbound.

As with previous policy definitions, NAT should also be enabled if the protected local hosts have private IPv4 addresses. The ICMP requests will then be sent out from the firewall with the IP address of the interface connected to the ISP as the source interface. Responding hosts will send back ICMP responses to this single IP and cOS Core will then forward the response to the correct private IPv4 address.

Adding a Drop All Policy

The top-down nature of the IP rule set scanning has already been discussed earlier. If no matching entry is found for a new connection then the default rule is triggered. This entry is hidden and cannot be changed. Its action is to drop all such traffic as well as generate a log message for the drop.

In order to gain control over the logging of dropped traffic, it is recommended to create a drop all policy as the last entry in the main IP rule set. This policy will have the source and destination network set to all-nets and the source and destination interface set to any. The service should be set to all_services in order to capture all types of traffic.

Logging is enabled by default for an IP rule set entry which means that a log message will be sent to all configured log servers whenever the entry triggers. Only log events that have a specified severity or above will be sent. The administrator can choose the minimum severity for log messages in each IP rule set entry, as shown below.

If this IP policy were the only one defined, the main IP rule set listing would be as shown below.

A Valid License Must Be Installed

If not done already, a valid license should be installed to remove the cOS Core two hour demo mode limitation. Without a license installed, cOS Core will have full functionality during the two hour period following startup, but after that, only management access will be possible. Installing a license is described in Section 6.5, Installing a License.