This chapter describes the setup steps using CLI commands instead of the setup wizard.

The CLI is accessible using either one of two methods:

Confirming the Connection

Once connection is made to the CLI, pressing the Enter key will cause cOS Core to respond. The response will be a normal CLI prompt if connecting directly through the local console and a username/password combination will not be required (a password for this console can be set later).

Device:/> 

If connecting remotely through an SSH (Secure Shell) client, an administration username/password must first be entered and the initial default values for these are username admin and password admin. When these are accepted by cOS Core, a normal CLI prompt will appear and CLI commands can be entered.

Manually Assigning a Management Interface IP Address

By default, cOS Core will enable a DHCP client on all Ethernet interfaces, including the default management interface If1. If an external DHCP server is not used to assign an IP address to the management interface, it must be manually assigned using CLI commands entered via the local cOS Core console. First, the DHCP client must be disabled:

Device:/> set Interface Ethernet If1 DHCPEnabled=No

This same command form can be used to disable DHCP on another interface, if required. For example:

Device:/> set Interface Ethernet If2 DHCPEnabled=No

Next, assign an IP address to the management interface. For example:

Device:/> set Address IP4Address InterfaceAddresses/If1_ip
			Address=192.168.1.1

This is followed by setting a network for the management interface. For example:

Device:/> set Address IP4Address InterfaceAddresses/If1_net
			Address=192.168.1.0/24

This is the IP address and network that can be now be used for both CLI and WebUI management access over a network to the If1 interface. This section will continue with manual CLI configuration.

Changing the admin Account 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 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 date and time. It is therefore important that this is set correctly using the time command. A typical usage of this command might be:

Device:/> time -set 2017-06-24 14:43:00

Notice that the date is entered in yyyy-mm-dd format and the time is stated in 24 hour hh:mm:ss format.

Ethernet Interfaces

The connection of external networks to the firewall is via the various Ethernet interfaces which are provided by the hardware platform. On first-time startup, cOS Core determines which interfaces are available and allocates their logical 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 interface can perform any logical function. However, the If1 interface is the default management interface. The other interfaces can be used as required. For this section, it is assumed 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 client network.

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 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 If2, 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 If2. interface which is connected to the ISP:

Device:/> set Interface Ethernet If2 DefaultGateway=wan_gw

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

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

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

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

It is recommended to verify the properties of the If2. interface using the following command:

Device:/> show Interface Ethernet If2

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

                   Property  Value
 --------------------------  --------------------------
                      Name:  If2
                        IP:  InterfaceAddresses/If2_ip
                   Network:  InterfaceAddresses/If2_net
            DefaultGateway:  wan_gw
                 Broadcast:  203.0.113.255                  
                 PrivateIP:  <empty>
                     NOCHB:  <empty>
                       MTU:  1500
                    Metric:  100
               DHCPEnabled:  No
            EthernetDevice:  0:If2  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 addition of an IP rule set entry which explicitly allows traffic to flow. Let us assume we want to allow web browsing from the protected network If1_net which is connected to the interface If1.

The following command will add an IP policy called lan_to_wan to allow traffic from If1_net through to the public Internet:

Device:/> add IPPolicy Name=lan_to_wan
			SourceInterface=If1
			SourceNetwork=InterfaceAddresses/If1_net
			DestinationInterface=If2
			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 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, this section will specify NAT translation explicitly for clarity. The above IP policy with explicit NAT translation becomes the following:

Device:/main> add IPPolicy Name=lan_to_wan
			SourceInterface=If1
			SourceNetwork=InterfaceAddresses/If1_net
			DestinationInterface=If2
			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 is http-all which will allow web browsing but does not include the DNS protocol to resolve URLs into IP addresses. To solve this problem, a custom service could be used in the above 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 for DNS:

Device:/main> add IPPolicy Name=lan_to_wan_dns
			SourceInterface=If1
			SourceNetwork=InterfaceAddresses/If1_net
			DestinationInterface=If2
			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 URLs which will be the case when a URL 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 DHCP is to be enabled is If2, then the command is:

Device:/> set Interface Ethernet If2 DHCPEnabled=Yes

Once the required IP addresses are retrieved with DHCP, 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. 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 since there is no IP rule set entry defined that allows it. 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 If1_net and interface If1) to flow to the destination network all-nets and the destination interface If2.

C. PPPoE setup

For PPPoE connection, create the PPPoE tunnel interface on the interface connected to the ISP. The interface If2. 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=If2
			username=pppoe_username
			Password=pppoe_password
			Network=all-nets

The 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 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 PPPoE tunnel that has been defined.

D. PPTP setup

For PPTP connection, first create the PPTP tunnel interface. It is assumed below that we 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.

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 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.

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 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.

Activating and Committing Changes

After any changes are made to a cOS Core configuration, they will be saved as a new configuration but will not yet be activated. To activate all the configuration changes made since the last activation of a new configuration, the following command must be issued:

Device:/> activate

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

Device:/> commit

The reason for two commands is to prevent a configuration accidentally locking out the administrator. If a lock-out occurs then the second command will not be received and cOS Core will 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, before activation, 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

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

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

First define an IPv4 address object which has the address range that can be handed out. Here, we will use the IPv4 range 192.168.1.10 - 192.168.1.20 as an example and this will be made available on the If1 interface which is connected to the protected internal network If1_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=If1
			Netmask=255.255.255.0
			DefaultGateway=InterfaceAddresses/If1_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, If1_ip.

NTP Server Setup

Network Time Protocol (NTP) servers can optionally be configured to maintain the accuracy of the system date and time. 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 TimeSyncEnable=Yes
		TimeSyncServer1=ts1_fqdn
		TimeSyncServer2=203.0.113.5

Syslog Server Setup

Although logging may be enabled, no log messages are captured unless a server is set up to receive them and Syslog is the most common server type. If the Syslog server's address is 192.0.2.10 then the command to create a log receiver object called my_syslog which enables logging is:

Device:/> add LogReceiverSyslog my_syslog IPAddress=192.0.2.10

Allowing ICMP Ping Requests

As a further example of setting up IP rule set entries, it can be useful to allow ICMP Ping requests to flow through the firewall. As discussed earlier, 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 If1_net network. The commands to allow this are as follows.

Add an IP policy called allow_ping_outbound to allow ICMP pings to pass:

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

This IP policy uses NAT and this is necessary if the protected local hosts have private IPv4 addresses. The ICMP requests will 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 IP address.

Adding a Drop All Policy

Scanning of IP rule sets is done in a top-down fashion. If no matching rule set entry is found for a new connection then the default rule is triggered. This rule is hidden and cannot be changed and 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.

The following IP policy will drop all remaining traffic as well as turning off logging for that traffic:

Device:/main> 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 6.5, Installing a License.