NetShield 500 Series Getting Started Guide

Figure 1.1. An Unpacked NetShield 500 Series Unit

This section details the unpacking of a single NetShield 500 Series device. Open the packaging box used for shipping and carefully unpack the contents. The packaging should contain the following:

Note that the NetShield 500 Series is capable of having two power adapters connected for redundancy. As standard, the product comes with only a single power adapter. A second adapter can be ordered separately from a Clavister sales office. An alternative rack mount kit that provides supporting shelves for PSUs is also available from Clavister as an option and this is described further in Section 2.2, Flat Surface and Rack Installation.

	Note: Report any items that are missing
	If any items are missing from the packaging, please contact your sales office.

Support Agreements

The Cold Standby Service

Downloading NetShield 500 Series Resources

Contacting Clavister Product Support

End of Life Disposal

The product, and any of its parts, should not be discarded using a regular refuse disposal method. At end-of-life, the product and parts should be given to an appropriate service that deals with the disposal of such specialist materials.

	WARNING: REPLACE INTERNAL BATTERIES CORRECTLY
	THERE IS A RISK OF EXPLOSION IF AN INTERNAL BATTERY IS REPLACED WITH THE INCORRECT TYPE. DISPOSE OF ANY USED INTERNAL BATTERIES APPROPRIATELY.

This section is an overview of the NetShield 500 Series product's external connectivity options.

Figure 1.2. NetShield 500 Series Interfaces and Ports

	Note: The meaning of the terms "Front" and "Back"
	The term "Front" will be used in this guide to refer to the side of the 500 Series that has the Ethernet ports and the term "Back" to the side that has the status lights.

The NetShield 500 Series features the following connection ports on the front panel:

	Note: The two USB Type A ports are not currently used
	The two USB Type A ports on the 500 Series front panel are for future functionality and are not currently used by cOS Stream.

Figure 1.3.  NetShield 500 Series Ethernet Interfaces

The full connection capabilities of all the NetShield 500 Series Ethernet interfaces are listed at the end of Appendix A, 500 Series Specifications.

RJ45 Ethernet Interface Status LEDs

System Status Indicator LEDs

Note that there is a power status light above both power inlets on the 500 series which indicates if power is applied to that inlet.

The NetShield 500 Series is equipped with sensors that provide cOS Stream with information about operational parameters such as CPU temperature. This information is available to the administrator through the cOS Stream management interfaces.

In addition, log message alerts can be automatically generated if a sensor reaches a value outside of its normal operational range.

Configuring this feature, as well as a list of all the sensors available on each Clavister hardware model and their normal ranges, can be found in the Hardware Monitoring section of the separate cOS Stream Administration Guide.

Follow these general guidelines when installing the NetShield 500 Series appliance:

	Note: The specifications appendix provides more details
	Detailed information concerning power supply range, operating temperature range and other operating details can be found at the end of this document in Appendix A, 500 Series Specifications.

The NetShield 500 Series can be mounted on any appropriate stable, flat, level surface that can safely support the weight of the appliance and its attached cables.

	Important: Always leave space around the appliance
	Always ensure there is adequate space around the appliance for ventilation and for easy access to switches and cable connectors. No objects should be placed on top of the casing.

The NetShield 500 Series can also be rack mounted in a standard 19-inch rack using the kit that is included with the appliance. The kit is installed by attaching the two side-brackets, as shown below.

Figure 2.1. NetShield 500 Series Rack Mount Kit Attachment

Once the brackets are firmly attached on either side, the unit can be mounted in a rack. Rear support is not required.

Figure 2.2. NetShield 500 Series Ready For Rack Mounting

Note that the brackets could instead be attached to the other side of the unit, as shown below.

Figure 2.3. NetShield 500 Series Ready For Rack Mounting

A different, optional kit is available from Clavister with shelf support for a single or a pair of PSUs. The image below shows how this kit is attached on each side.

Figure 2.4. NetShield 500 Series Rack Mount Kit Attachment With PSU Support

Once the kit has been attached, PSUs can be placed on the shelf on either side of the unit with nylon ties securing them in place, as shown below.

Figure 2.5. NetShield 500 Series Ready For Rack Mounting With PSU Support

cOS Stream Starts After Power Up

Clavister's cOS Stream software is preloaded on the NetShield 500 Series and will automatically boot up after power is applied. After the start-up sequence is complete, an external management computer can be used to configure cOS Stream.

cOS Stream Access Methods for Setup

The Default Management Ethernet Interface

For the NetShield 500 Series, the physical default management Ethernet interface is G1.

This network connection could be made via a local switch using standard Ethernet cables, as shown in the illustration below.

Direct local Ethernet connection to the G1 interface can be done without a switch by using a suitable crossover cable. However, all the RJ45 interfaces on the NetShield 500 Series support Automatic MDI-X so a crossover cable is not necessary.

Connection to an ISP for Internet Access

Note that in the default cOS Stream configuration for the NetShield 500 Series, the G4 and X1 interfaces already have a DHCP client enabled so an IP addresses can be automatically assigned by an ISP on connection.

Tip: Connect the Internet before the management computer

If the G4 or X1 interface is connected to an ISP before the management computer is connected to the G1 interface, DNS addresses for resolving URIs will be received from the ISP and then relayed in the DHCP lease sent to a connecting management computer. If the management computer is connected first, it may get its IP assigned by the firewall with a DHCP lease that will not contain DNS addresses and the lease lifetime will be 24 hours. Renewing the lease, for example with a management computer restart, may be necessary to get DNS addresses after they are received on the G4 or X1 interface. Alternatively, DNS addresses could be entered into the management computer manually.

Management Computer Ethernet Interface Setup

If the management computer is configured manually, the following settings could be used:

	Tip: Using another management interface IP address
	The IPv4 address assigned to the management computer's Ethernet interface could be any address from the 192.168.1.0/24 network. However, the IP chosen must be different from 192.168.1.1 which is used by cOS Stream's default management interface.

The local console port allows direct management connection to the NetShield 500 Series unit from an external computer acting as a console terminal. This local console access can then be used for both management of cOS Stream with CLI commands or to enter the boot menu in order to access firmware loader options. The boot menu is described further in the separate cOS Stream Administration Guide.

The local console port is the physical RJ45 RS-232 port on the left-hand side of the NetShield 500 Series's connector panel and is marked |O|O|.

Figure 2.6. NetShield 500 Series RJ45 Local Console Port Connection

Note that the NetShield 500 Series has both an RJ45 console port and a micro-USB port (described in Section 2.5, Micro-USB Console Port Connection). Both can be used but if both are connected then the micro-USB port will automatically take precedence.

Requirements for NetShield 500 Series Local Console Connection

Connection Steps

Remote Console Connection Using SSH

The local console port allows direct management connection to the 500 Series hardware from an external computer acting as a console terminal. Local console access can then be used for both management of cOS Stream with CLI commands or to enter the boot menu in order to access 500 Series firmware loader options. The boot menu is described further in the separate cOS Stream Administration Guide.

There is a physical micro-USB port (type micro-B) on the 500 Series hardware that allows local console connection. This is an alternative to using the RJ45 local console port on the appliance (described in Section 2.4, RJ45 Console Port Connection). However, the micro-USB port will automatically take precedence if both are connected.

Figure 2.7. The NetShield 500 Series Micro-USB Local Console Port

Connection Steps

Issuing CLI Commands

Remote Console Connection Using SSH

This section describes connecting power. As soon as power is applied, the NetShield 500 Series will boot-up and cOS Stream will start.

	Important: Review the safety information
	Before connecting power, please review the electrical safety information found in Chapter 7, Safety Precautions.

Figure 2.8. Front View of a NetShield 500 Series Unit

Note that the NetShield 500 Series is capable of having two power adapters connected for redundancy through the power inlets labeled DC1 and DC2. As standard, the product comes with only a single power adapter. A second, optional adapter can be purchased as a separate item.

Note that there is a power status light above both power inlets on the 500 Series which indicates if power is applied to that inlet.

Connecting AC Power

Important: Consider power surge protection

It is recommended to consider the purchase and use of a separate surge protection unit from a third party for the power connection to the NetShield 500 Series hardware. This is to ensure that the appliance is protected from damage by sudden external electrical power surges through the power cable. Surge protection is particularly important in locations where there is a heightened risk of lightning strikes and/or power grid spikes. Any surge protection unit should be installed exactly according to the manufacturer's instructions since correct installation of such units is vital for them to be effective.

This section describes the predefined entries in the default cOS Stream configuration that are unique to the NetShield 500 Series.

Ethernet Interface DHCP settings

The Predefined IP Rule Set

The Predefined all-nets Routes

Changing the Default Configuration

The cOS Stream CLI is accessible using either of the following two methods:

Confirming the CLI Connection

Device:/> 

When these are accepted by cOS Stream, a normal CLI prompt will appear and CLI commands can be entered.

Changing the admin Password

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

	Tip: Using tab completion with the CLI
	The tab key can be pressed at any time so that cOS Stream gives a list of possible options in a command.

Next, set a new password for the administrator. Both are case sensitive. In the example below, the the password is set to the value my_new_password.

Device:/AdminUsers> set User admin Password=my_new_password

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

Device:/AdminUsers> cc
Device:/> 

Setting the Date and Time

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

The Management Ethernet Interface

All Ethernet interfaces are logically equal in cOS Stream and although their physical capabilities may be different, any interface can perform any logical function. One of the interfaces will be automatically assigned as the default management interface (this management interface can be changed later). This is the G1 interface on the 500 Series.

On the 500 Series, this default management interface is enabled as an IPv4 DHCP server and will automatically assign an IPv4 address to a connecting client. The interface is also enabled to send out IPv6 router advertisements so that a connecting IPv6 client can be assigned an IPv6 address automatically.

Note that a DNS server address for clients is also usually automatically allocated. However, if the client interface is IPV6 only (not in dual-stack mode) then the DNS address will have to be manually assigned to the address object called WAN_ip6_dns.

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.

	Note
	Each installation's IP addresses for Internet connection will be different from the example IP addresses used in this section.

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

Device:/> activate

Device:/> commit

DHCP Server Setup

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

Device:/> set DateTime TimeSyncEnabled=Yes

Device:/> cc DateTime
Device:/DateTime> 

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

Device:/DateTime> cc
Device:/> 

Syslog Server Setup

Device:/> add LogReceiverSyslog my_syslog IPAddress=192.0.2.55

Allowing ICMP Ping Requests

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

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

Entering the Boot Menu

Boot Menu Options

The boot menu is also discussed in the separate cOS Stream Administration Guide.

This section deals with connection problems that might occur when connecting an external management computer to cOS Stream. It is assumed that the 500 Series system has been successfully powered up and initial management connection is first being attempted over a network to a physical Ethernet interface.

If the management Ethernet interface does not respond after the 500 Series has powered up and cOS Stream has started, the following steps can be used to help troubleshoot connection problems:

1. Check that the correct Ethernet interface is being used.

The most obvious problem is that the wrong Ethernet interface has been used for the initial connection. Only the first interface found by cOS Stream is will allow the initial management connection after cOS Stream starts for the first time.

2. Check that interface characteristics match.

If a firewall's Ethernet interface characteristics are configured manually then the interface on an external computer or switch to which it is connected should be configured with the same characteristics. For example, link speed settings should match. This problem will not occur if the interfaces are set for automatic configuration on both sides.

3. Check that the management computer IP/Network is configured correctly.

Check that the IP address and network of the management computer Ethernet interface is configured correctly so it can communicate with the management interface of the firewall.

4. Is the management interface properly connected?

Where relevant, check the link LED lights on the connected Ethernet interface. This can identify a cable problem.

5. Using the ifstat CLI command.

To investigate a connection problem further, connect a computer running console emulation software directly to the local console port on the firewall. Once cOS Stream has started, it should respond with the standard CLI prompt when the enter key is pressed. Now enter the following command once for each interface:

Device:/> ifstat <if-name>

Where <if-name> is the name of the management interface. This will display a number of counters for that interface. The ifstat command on its own can list the names of all the interfaces.

If the Input counters in the hardware section of the output are not increasing then the error is likely to be in the cabling. However, it may simply be that the packets are not getting to the firewall in the first place. This can be confirmed with a packet sniffer, if it is available.

If the Input counters are increasing, the management interface may not be attached to the correct physical network. There may also be a problem with the routing information in any connected hosts or routers.

6. Using the arpsnoop CLI command.

A diagnostic test to try with IPv4 connections is using the console command:

Device:/> arpsnoop all

This will display console messages that show all the ARP packets being received on the different interfaces and confirm that the correct cables are connected to the correct interfaces. To look at the ARP activity only a particular interface, follow the command with the interface name:

Device:/> arpsnoop <interface>

To switch snooping off, use the command:

Device:/> arpsnoop none

7. Check the management access rules for a network connection.

When connecting to the default management interface over a network connection, check that the management access rules are correctly configured to allow access through the interface and from the desired source IP range. These rules can be displayed with the CLI command:

Device:/> show RemoteManagement

After initial setup is complete, the administrator is ready to go further with configuring cOS Stream to suit the requirements of a particular networking scenario.

The primary reference documentation consists of:

Other available documents in PDF format are:

In addition, each cOS Stream release has an associated Release Notes document that lists new features, fixes and known issues.

All documents can be downloaded in PDF format by logging into https://my.clavister.com and going to the downloads for the relevant cOS Stream release. Alternatively, documentation for the latest cOS Stream release can be read in HTML format at https://docs.clavister.com.

The cOS Stream Administrators Guide

Examples of the setup for various scenarios are included but screenshots are kept to a minimum since the user has a variety of management interfaces to choose from.

Basic cOS Stream Objects and Rules

IP rules identify the targeted traffic using combinations of the source/destination interface/network combined with protocol type. By default, no IP rules are defined so all traffic is dropped. At least one IP rule needs to be defined before traffic can traverse the Clavister Firewall.

In addition to rules, Route objects need to be defined in a Routing Table so that traffic can be sent on the correct interface to reach its final destination. Traffic will need both a relevant IP rule and route to exist in order for it to traverse the firewall.

VPN Setup

Included with the quick start section is a checklist for troubleshooting and advice on how best to deal with the networking complications that can arise with certificates.

Log Messages

The CLI Reference Guide

cOS Stream Education Courses

Staying Informed

https://my.clavister.com