This section describes manually setting up public Internet access using the CLI and IPv4 addresses.

For the 500 Series, this section may be useful if the predefined DHCP client on the G4 or X1 interface is not going to be automatically assigned IP addresses by an ISP for Internet connection.

For this setup, it will be assumed that the G2 interface will be used for connection to the public Internet and the G1 interface will be used for connection to an internal, local network. However, any of the available Ethernet interfaces could be used for these purposes.

The first step is to set up a number of IPv4 address objects. If the interface used for Internet connection is G2 then this will have the IP address 203.0.113.10 which belongs to the network 203.0.113.0/24. It is also assumed that the ISP gateway's IPv4 address is 203.0.113.1.

Set the IP address of the G2 interface:

Device:/> set Address IPAddress G2_ip Address=203.0.113.10

Also, set the network for this interface:

Device:/> set Address IPAddress G2_net Address=203.0.113.0/24

In addition, it is recommended to set the broadcast IP address for the interface:

Device:/> set Address IPAddress G2_broadcast Address=203.0.113.255

If the broadcast address is not set, it will take the default value of 127.0.2.255.

It is recommended to verify the properties of the G2 interface with the following command:

Device:/> show Interface EthernetInterface G2

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

                     Property  Value
-----------------------------  --------------------
                        Name:  G2
             EthernetAddress:  0:<empty>  1:<empty>
                      HAType:  Critical
              MonitorTargets:  <empty>
                   Backplane:  No
              EthernetDevice:  0:G2  1:<empty>
            VLANOutboundPrio:  0
      VLANOutboundPrioPolicy:  Set (Set priority)
                   PrivateIP:  0:<empty>  1:<empty>
  RouterAdvertisementProfile:  DefaultProfile
                         MTU:  1500
                   IPAddress:  G2_ip
                IP4Broadcast:  G2_broadcast
      RoutingTableMembership:  <all>
SecurityEquivalentInterfaces:  <empty>
                     UseDHCP:  <empty>
                    Comments:  <empty>

Next, add an all-nets-ip4 route to the main routing table. This will route outgoing IPv4 Internet traffic through the G2 interface. This Route object must also specify the IP address of the ISPs gateway (the next router hop), so an IP address object needs to be created for this. If we call the object wan_gw, the command would be:

Device:/> add Address IPAddress wan_gw Address=203.0.113.1

Now, create the route. This is done by changing the CLI context to be main routing table:

Device:/> cc RoutingTable main

Then, add the route to this routing table:

Device:/RoutingTable/main> add Route
			Interface=G2
			Network=all-nets-ip4
			Gateway=wan_gw

Change back to the default context:

Device:/RoutingTable/main> cc
Device:/> 

Even though an all-nets-ip4 route exists, no traffic can flow without the addition of at least one IPRule object to allow the flow. Assume that web browsing to the Internet is to be allowed from the protected network on the interface G1. To do this, add an IP rule called lan_to_wan.

A default cOS Stream IP rule set called main always exists by default. Change the CLI context to be this rule set:

Device:/> cc RuleSet IPRuleSet main
Device:/IPRuleSet/main> 

Now, add the required IPRule object:

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

This IP rule would be correct if the internal network hosts have public IPv4 addresses but in most scenarios this will not be true and internal hosts will have private IPv4 addresses. In that case, we must use NAT to send out traffic so that the apparent source IP address is the IP of the interface connected to the ISP. To do this, keep the Action property as Allow but add the SourceTranslation and SetSourceAddress properties to specify that NAT will be used and the address of the outgoing interface will be used as the source address:

Device:/IPRuleSet/main> add IPRule
			Action=Allow
			SourceInterface=G1
			SourceNetwork=G1_net
			DestinationInterface=G2
			DestinationNetwork=all-nets
			Service=http
			SourceTranslation=NAT
			SetSourceAddress=InterfaceAddress
			Name=lan_to_wan

The service used in the IP rule is http and this will allow basic web browsing. Note that this service does not include the HTTPS protocol, so a custom service will need to be created for HTTPS and then this is used in a new ServiceGroup object which will be associated with an IP rule.

The http service also does not include the DNS protocol to resolve URIs into IP addresses. For configuration clarity, it is recommended to create a separate IP rule for DNS:

Device:/IPRuleSet/main> add IPRule
			Action=Allow
			SourceInterface=G1
			SourceNetwork=G1_net
			DestinationInterface=G2
			DestinationNetwork=all-nets
			Service=dns-all
			SourceTranslation=NAT
			SetSourceAddress=InterfaceAddress
			Name=lan_to_wan_dns

Finally, change the CLI context back to the default context (this is sometimes called the root context):

Device:/IPRuleSet/main> cc
Device:/> 

When adding IP rules later in this section, the changing between CLI contexts will not be explicitly stated. The context is indicated by the command prompt.

It is recommended that at least one DNS server is also defined in cOS Stream. This DNS server or servers (a maximum of three can be configured) will be used when cOS Stream itself needs to resolve URIs, which will be the case when a URI is specified in a configuration instead of an IP address. If we assume IP address objects called dns1_address and dns2_address have already been defined, the command to specify these as DNS servers is:

Device:/> set DNS DNSServers=dns1_address,dns2_address

Activating and Committing Changes

After any changes are made to a cOS Stream 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 Stream will revert back to the original configuration after the 30 second time period (this time period is a setting that can be changed).

DHCP Server Setup

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

First, define an IPv4 address object with the address range that will be handed out. Here, we will use the IPv4 range 192.168.1.10 - 192.168.1.20 as an example and this range will be available on the G1 interface which is connected to the protected internal network:

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

A DHCPServerRule is now configured using this IP address object for the relevant interface. In this case the G1 interface:

Change the CLI context to be DHCPServer:

Device:/> cc DHCPServer

Add a DHCPServerRule object:

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

Change back to the default context:

Device:/DHCPServer> cc
Device:/> 

It is assumed that the IP address object dns1_address for the DNS server was created previously.

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, the address G1_ip.

NTP Server Setup

Network Time Protocol (NTP) servers can optionally be configured to maintain the accuracy of the system date and time. The following commands set up synchronization with the NTP server at IPv4 address 10.5.4.76:

Device:/> set DateTime TimeSyncEnabled=Yes

Change to the DateTime context:

Device:/> cc DateTime
Device:/DateTime> 

Add the time server:

Device:/DateTime> add TimeServer IP=10.5.4.76 Name=my_tsrv

Change back to the default (root) context:

Device:/DateTime> cc
Device:/> 

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

Allowing ICMP Ping Requests

As a further example of setting up IP rules, it can be useful to allow ICMP Ping requests to flow through the firewall. It should be remembered that cOS Stream will drop any traffic unless an IP rule explicitly allows it. Let us suppose that we wish to allow the pinging of external hosts on the Internet by computers on the internal network G1_net network.

To set this up, add an IPRule object called allow_ping_outbound. This will be done in the IPRuleSet/main CLI context:

Device:/IPRuleSet/main> add IPRule
			Action=Allow
			SourceInterface=G1
			SourceNetwork=G1_net
			DestinationInterface=G2
			DestinationNetwork=all-nets
			Service=ping-outbound
			SourceTranslation=NAT
			SetSourceAddress=InterfaceAddress
			Name=allow_ping_outbound

The IP rule again has the NAT action and this is necessary if the protected local hosts have private IPv4 addresses. The ICMP requests will be sent out from the Clavister 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 Stream will then forward the response to the correct private IP address.

Adding a Drop All Rule

Scanning of the IP rule set is done in a top-down fashion. If no matching IP rule 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 rule as the last rule in the main IP rule set. This rule has an Action of Drop with the source and destination network set to all-nets and the source and destination interface set to any.

The service for this rule must also be specified and this should be set to all_services in order to capture all types of traffic. The command for creating this rule in the IPRuleSet/main CLI context is the following:

Device:/IPRuleSet/main> add IPRule
			Action=Deny
			SourceInterface=any
			SourceNetwork=all-nets
			DestinationInterface=any
			DestinationNetwork=all-nets
			Service=all_services
			OnDeny=DropSilent
			Name=drop_all