This chapter describes the setup steps using CLI commands instead of the setup wizard.
The CLI is accessible using either one of two methods:
Using the KVM virtual machine command console. This is equivalent to what is described as the cOS Core local console. This access method must be used if the management interface does not yet have an IP address assigned to it.
If the management interface has an IPv4 address assigned to it, access is possible using an SSH (Secure Shell) client, across a network connection to the management interface. The physical network connection setup to the computer running the client is described in Section 6.1, Management Computer Connection.
If there is a problem with the network connection, a problem checklist can be found in Section 6.6, Setup Troubleshooting .
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 AdminUsersDevice:/AdminUsers>
![]() |
Tip: Using tab completion with the CLI |
---|---|
The tab key can be pressed at any time so that cOS Core gives a list of possible options in a command. |
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>
ccDevice:/>
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.