This chapter describes the cOS Core setup steps using cOS Core CLI commands. The CLI is accessible using either of the following two methods:

Note that the setup steps listed in this section are grouped so that they closely follow the order of the options in the setup wizard.

Initial CLI Connection and Login Credentials

Once a connection is made to the CLI, pressing the Enter key will cause cOS Core to respond by asking for the console login credentials. By default, these are username admin and password admin. This will be followed by a normal CLI prompt after successful authentication.

Device:/> 

Changing the admin User Password

It is strongly recommended to change the password of the admin user as the first task in manual cOS Core setup. To do this, use the set command to change the current CLI object category (also referred to as the context) to be the LocalUserDatabase called AdminUsers.

Device:/> cc LocalUserDatabase AdminUsers
Device:/AdminUsers> 

Now set a new password for the administrator which is difficult to guess. For example:

Device:/AdminUsers> set User admin Password=Mynew*pass99

The next step is to return the CLI to the default CLI context:

Device:/AdminUsers> cc
Device:/> 

By default, using a strong admin account 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, such as event logging and certificate handling, rely on an accurate system time. It can be set manually using the time command. A typical example might be:

Device:/> time -set 2021-03-24 14:43:00

Note that the date is entered in yyyy-mm-dd format and the time is stated in 24 hour hh:mm:ss format. Automatically setting the time with a time server is discussed at the end of this section.

Ethernet Interfaces

The connection of external networks to the firewall is via the Ethernet interfaces provided by the underlying platform. On first-time startup, cOS Core determines which interfaces are available and allocates their names. One interface is chosen as the initial default management interface and this can only be changed after initial startup.

All cOS Core interfaces are logically equal for cOS Core and although their physical capabilities may be different, any cOS Core interface can perform any logical function. On the 6000 Series, the G1 interface is the default management interface. The other interfaces can be used as required. For this section, it is assumed that the G1 interface will be used for connection to a protected, local client network and the G2 interface will be used for connection to the public Internet.

Setting Up Internet Access

Setting up Internet access manually using the CLI will now be described. There are four options which are listed below.

A. Static - manual configuration.

B. DHCP - automatic configuration.

C. PPPoE setup.

D. PPTP setup.

The steps to configure these Internet connection alternatives with the CLI are discussed next.

A. Static - manual configuration

We first must set or create a number of IPv4 address objects. It is assumed here that the interface used for Internet connection is G2, the ISP gateway IPv4 address is 203.0.113.1, the IPv4 address for the connecting interface will be 203.0.113.35 and the network to which they both belong is 203.0.113.0/24.

First, add the gateway IPv4 address object if it does not already exist:

Device:/> add Address IP4Address wan_gw Address=203.0.113.1

This is the address of the ISP's gateway which is the first router hop towards the public Internet. If this IP object already exists, it can be given the IP address with the command:

Device:/> set Address IP4Address wan_gw Address=203.0.113.1

Now, set the gateway on the G2. interface which is connected to the ISP:

Device:/> set Interface Ethernet G2 DefaultGateway=wan_gw

Next, set the IP address of the G2_ip address object which is the IP assigned to the interface:

Device:/> set Address IP4Address InterfaceAddresses/G2_ip
			Address=203.0.113.35

Now, set the IP object G2_net. which will be the IPv4 network of the connecting interface:

Device:/> set Address IP4Address InterfaceAddresses/G2_net
			Address=203.0.113.0/24

Before continuing, it is recommended to verify the properties of the G2. interface using the following command:

Device:/> show Interface Ethernet G2

The typical output from this will be similar to the following:

                   Property  Value
 --------------------------  --------------------------
                      Name:  G2
                        IP:  InterfaceAddresses/G2_ip
                   Network:  InterfaceAddresses/G2_net
            DefaultGateway:  wan_gw
                 Broadcast:  203.0.113.255                  
                 PrivateIP:  <empty>
                     NOCHB:  <empty>
                       MTU:  1500
                    Metric:  100
               DHCPEnabled:  No
            EthernetDevice:  0:G2  1:<empty>
           AutoSwitchRoute:  No
 AutoInterfaceNetworkRoute:  Yes
   AutoDefaultGatewayRoute:  Yes
   ReceiveMulticastTraffic:  Auto
      MemberOfRoutingTable:  All
                  Comments:  <empty>

Setting the default gateway on the interface has the additional effect that cOS Core automatically creates a route in the default main routing table that has the network all-nets routed on the interface. This means that we do not need to explicitly create this route.

Even though an all-nets route is automatically added, no traffic can flow without the existence of an IP Policy which explicitly allows traffic to flow. Let us assume we want to allow web browsing from the protected network G1_net which is connected to the interface G1.

The following command will add an IP policy called lan_to_wan to allow HTTP and HTTPS traffic from clients to flow to the public Internet:

Device:/> add IPPolicy Name=lan_to_wan
			SourceInterface=G1
			SourceNetwork=InterfaceAddresses/G1_net
			DestinationInterface=G2
			DestinationNetwork=all-nets
			Service=http-all
			Action=Allow

IP policies have a default value of Auto for the type of source translation. This means that if the source is a private IPv4 address and the destination is a public address, NAT translation will be performed automatically using the IP address of the outgoing interface as the new source address. Therefore the above IP policy will work both for connection to another private IP address or to public addresses on the Internet.

Instead of relying on the Auto option, NAT translation can be specified explicitly. For this, the previous IP policy definition with explicit NAT translation becomes the following:

Device:/main> add IPPolicy Name=lan_to_wan
			SourceInterface=G1
			SourceNetwork=InterfaceAddresses/G1_net
			DestinationInterface=G2
			DestinationNetwork=all-nets
			Service=http-all
			Action=Allow
			SourceAddressTranslation=NAT
			NATSourceAddressAction=OutgoingInterfaceIP

Specifying NATSourceAddressAction=OutgoingInterfaceIP is not necessary as this is the default value but it is included here for clarity.

The service used in the above is http-all which will allow web browsing from the protected network but this does not include the DNS protocol to resolve URIs into IP addresses. To solve this problem, a custom service could be used in the above IP policy which combines http-all with the dns-all service. However, the recommended method, which provides the most clarity to a configuration, is to create a separate IP policy just for DNS traffic:

Device:/main> add IPPolicy Name=lan_to_wan_dns
			SourceInterface=G1
			SourceNetwork=InterfaceAddresses/G1_net
			DestinationInterface=G2
			DestinationNetwork=all-nets
			Service=dns-all
			Action=Allow
			SourceAddressTranslation=NAT
			NATSourceAddressAction=OutgoingInterfaceIP

It is 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 URIs, which will be the case when an FQDN is specified in a configuration instead of an IP address. If we assume an IP address object called dns1_address has already been defined for the first DNS server, the command to specify the first DNS server is:

Device:/> set DNS DNSServer1=dns1_address

Assuming a second IP object called dns2_address has been defined, the second DNS server is specified with:

Device:/> set DNS DNSServer2=dns2_address

B. DHCP - automatic configuration

Alternatively, all required IP addresses can be automatically retrieved from the ISP's DHCP server by enabling DHCP on the interface connected to the ISP.

If the interface on which a DHCP client is to be enabled is G2 then the command to do this is:

Device:/> set Interface Ethernet G2 DHCPEnabled=Yes

Once the required IP addresses are retrieved with DHCP, cOS Core automatically sets the relevant address objects in the address book with these addresses.

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. Automatic route generation is a setting for each interface that can be manually enabled and disabled.

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 until an IP rule set entry is defined that allows the flow. As was done in the previous option (A) above, we must therefore manually define an IP policy that will allow traffic from a designated source network and source interface (in this example, the network G1_net and interface G1) to flow to the destination network all-nets and the destination interface G2.

C. PPPoE setup

For PPPoE connection, define a PPPoE tunnel interface on the interface connected to the ISP. The interface G2. is assumed to be connected to the ISP in the command shown below which creates a PPPoE tunnel object called wan_ppoe:

Device:/> add Interface PPPoETunnel wan_ppoe
			EthernetInterface=G2
			Username=pppoe_username
			Password=pppoe_password
			Network=all-nets

Your 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 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 and source interface (in this example, the network G1_net and interface G1) to flow to the destination network all-nets and the destination interface, which is the PPPoE tunnel.

D. PPTP setup

For PPTP connection, first define the PPTP tunnel interface. The following command will create a PPTP tunnel object called wan_pptp with the remote endpoint 203.0.113.1:

Device:/> add Interface L2TPClient wan_pptp
			Network=all-nets
			username=pptp_username
			Password=pptp_password
			RemoteEndpoint=203.0.113.1
			TunnelProtocol=PPTP

Your 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 an Ethernet 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.

As with all automatically added routes, if the PPTP tunnel object is deleted then 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 and source interface (in this example, the network G1_net and interface G1) to flow to the destination network all-nets and destination interface, which is the PPTP tunnel.

Activating and Committing Changes

After any changes are made to a cOS Core configuration, they will form a new configuration but will not yet be activated. To activate new configuration changes, the following command must be entered:

Device:/> activate

Although the new configuration is now activated, it does not become permanently saved until the following command is issued within 30 seconds following the activate:

Device:/> commit

The reason for having a two command sequence is to prevent the new configuration accidentally locking out the administrator. If a lock-out occurs then the commit command cannot be received and cOS Core will automatically revert back to the original configuration after the 30 second time period (this time period is a setting that can be changed).

If the admin account password has not been changed earlier to a strong password and strong passwords are enabled (by default, they are) then activating configuration changes will not be allowed by cOS Core. The solution to this is either to change the admin account password to a strong one or turn off strong passwords with the following command:

Device:/> set Settings MiscSettings EnforceStrongPasswords=No

Note that if activation fails because of a weak password, the old admin password must be reset anyway, even if the new value is the same as the old.

DHCP Server Setup

Any interface on the NetWall 6000 Series can be set up with a DHCP server so connecting clients can be automatically allocated an IP address from a predefined range.

First, define an IPv4 address object which has the address range that can be handed out. In this example, we will use the IPv4 range 192.168.1.10 - 192.168.1.20 and this will be made available on the G1 interface which is connected to the protected network G1_net.

Device:/> add Address IP4Address dhcp_range
			Address=192.168.1.10-192.168.1.20

The DHCP server is then configured with this IP address object on the appropriate interface. In this case we will call the created DHCP server object my_dhcp_server.

Device:/> add DHCPServer my_dhcp_server
			IPAddressPool=dhcp_range
			Interface=G1
			Netmask=255.255.255.0
			DefaultGateway=InterfaceAddresses/G1_ip
			DNS1=dns1_address

It is important to specify the default gateway for the DHCP server since this will be handed out to DHCP clients on the internal network so that they know where to find the public Internet. The default gateway is always the IP address of the interface on which the DHCP server is configured. In this case, G1_ip.

NTP Server Setup

Network Time Protocol (NTP) servers can be configured to maintain the accuracy of the system date and time. By default, no time server is configured. Clavister provides its own time server which can be used with the following command:

Device:/> set DateTime TimeSynchronization=Clavister

Alternatively, a custom time server can be configured. Suppose that synchronization is to be setup with the two NTP servers at hostname pool.ntp.org and IPv4 address 203.0.113.5. First, an FQDNAddress object needs to set up for the hostname:

Device:/> add Address FQDNAddress ts1_fqdn Address=pool.ntp.org

Next, set the servers to use for date and time synchronization:

Device:/> set DateTime TimeSynchronization=Custom
		TimeSyncServer1=ts1_fqdn
		TimeSyncServer2=203.0.113.5

External Syslog Server Setup

By default, only cOS Core's internal memlog feature will capture generated log messages. To send logs to an external Syslog server, a log receiver object must be configured. For example, the following command will send logs to a Syslog server at the IP address 192.0.2.10:

Device:/> add LogReceiverSyslog my_syslog IPAddress=192.0.2.10

Allowing ICMP Ping Requests

As a further example of setting up IP policies, it can be useful to allow ICMP ping messages to flow through the firewall. As discussed earlier, cOS Core will drop any traffic unless an IP rule set entry explicitly allows it. Suppose that we wish to allow the pinging of external hosts by hosts located on the protected network G1_net. The command to define an IP policy called allow_ping_outbound to allow this traffic would be the following:

Device:/> add IPPolicy Name=allow_ping_outbound
			SourceInterface=G1
			SourceNetwork=InterfaceAddresses/G1_net
			DestinationInterface=G2
			DestinationNetwork=all-nets
			Service=ping-outbound
			Action=Allow
			SourceAddressTranslation=NAT
			NATSourceAddressAction=OutgoingInterfaceIP

The IP policy above assumes NAT will be used and this is necessary if the protected local hosts have private IPv4 addresses. The ICMP requests will be sent out to the Internet with the IP address of the firewall interface connected to the ISP. Responding hosts will send back ICMP responses to this single IP and cOS Core will then forward the traffic to the correct private IP address.

Adding a "Drop All" Policy is Recommended

Scanning of IP rule sets is done in a top-down fashion. If no matching rule set entry is found for traffic then a hidden, implicit default rule is triggered. This rule cannot be changed and its action is to drop all such traffic as well as generate a log message when it is triggered.

In order to gain more control over dropped traffic and its logging, it is recommended to create an explicit "drop all" IP policy as the last entry in the main IP rule set. This policy has both the source and destination network set to all-nets and both the source and destination interface set to any. The service would be set to all_services in order to trigger on all traffic types.

The following command defines an explicit "drop all" policy with logging disabled:

Device:/> add IPPolicy Name=drop_all
			SourceInterface=any
			SourceNetwork=any
			DestinationInterface=any
			DestinationNetwork=all-nets
			Service=all_services
			Action=Deny
			LogEnabled=No

A Valid License Should Be Installed

Lastly, a valid license should be installed to remove the cOS Core 2 hour demo mode limitation. Without a license installed, cOS Core will have full functionality during the 2 hour period following startup (except for subscription based features), but after that only management access will be possible. Installing a license is described in Section 4.4, License Installation.