Table of Contents
Note: This document is also available in other formats | |
---|---|
A PDF version of this document along with all current and older documentation in PDF format can be found at https://my.clavister.com. It is also available in a framed HTML version. |
Important: Only cOS Core version 14.00.00 or later is supported | |
---|---|
The NetWall 6000 Series hardware product can run any cOS Core version from 14.00.00 onwards. Earlier versions are not supported and a downgrade should not be attempted. |
This section details the unpacking of a single NetWall 6000 Series device. Open the packaging box used for shipping and carefully unpack the contents. The packaging should contain the following:
The NetWall 6000 Series appliance.
Power cable for the single PSU supplied in the base unit.
Rack mount kit.
Note that the NetWall 6000 Series comes with only a single power supply unit (PSU) installed as standard. This can be for AC (the default) or DC power. A second PSU for redundancy can be ordered separately from a Clavister sales office and fitted on-site into the unused PSU slot on the back of the unit. This topic is discussed further in Chapter 5, PSU Replacement. Note that the fan units in the NetWall 6000 Series are not field replaceable and so the fans will not discussed further in this document.
Note: Report any items that are missing | |
---|---|
If any items are missing from the packaging, please contact your sales office. |
Support Agreements
All purchasers of a new NetWall hardware product must also subscribe to one of the available cOS Core support agreements. These provide access to cOS Core updates and provide a hardware replacement service in the event of a hardware fault. The terms of warranty are described in Chapter 9, Warranty Service, along with a description of the hardware replacement procedure.The Cold Standby Service
To ensure maximum uptime, a Cold Standby (CSB) Service is available from Clavister as an addition to certain cOS Core support agreements. This service allows a second, identical NetWall 6000 Series unit to be purchased at a discount so that it can quickly substitute for the original unit in case of failure, with the ability to quickly reassign the original cOS Core license to the standby unit. When the faulty unit is returned to Clavister, a new cold standby unit is immediately sent back. More details about the CSB service can be found in the separate NetWall Hardware Replacement Guide publication.Downloading NetWall 6000 Series Resources
All documentation, version upgrades and other resources for the NetWall 6000 Series can be downloaded from the Clavister website after logging into the relevant MyClavister account.Contacting Clavister Product Support
Clavister customer support can be contacted by logging into https://my.clavister.com and reporting an issue online. Alternatively, the direct support telephone number is +46 (0)660-29 77 55 (answered 24/7). Sales enquiries should be directed to the head office number +46 (0)660-29 92 00 or a local sales office during the relevant business hours.End of Life Disposal
The NetWall 6000 Series appliance is marked with the European Waste Electrical and Electronic Equipment (WEEE) directive symbol which is shown below.
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 NetWall 6000 Series product's external connectivity options.
The NetWall 6000 Series features the following connection ports:
An RJ45 RS-232 local console port
This port can used for direct access to the cOS Core Boot Menu and the cOS Core Command Line Interface (CLI). Connecting to this port is described in Section 3.5, RJ45 Console Port Connection.
A micro-USB (type micro-B) local console port
This port provides an alternative means for a local console connection and is marked with the letter C. Like the RJ45 console port, this is used for direct access to the cOS Core Boot Menu and the cOS Core Command Line Interface (CLI). Connection to this port is discussed in Section 3.6, Micro-USB Console Port Connection.
If local console connections are made to the RJ45 and micro-USB ports at the same time, the micro-USB port will automatically take precedence.
8 x RJ45 Gigabit Ethernet interface ports
These ports have sequential logical cOS Core interface names from G1 to G8. They all support 10BaseT, 100BaseTx and 1000BaseT.
The G1 interface is the default interface for management access over a network. However, it can also be used for other purposes. The G8 interface has a DHCP client enabled on it in the default cOS Core configuration so it can be automatically assigned an IP address by an ISP on connection.
Note that G1 interface does not have a DHCP server already set up in the default cOS Core configuration so the management computer's Ethernet interface address must be manually configured for network connection to the appliance. Doing this is described in Section 3.4, Management Computer Connection.
2 x 10 Gigabit SFP+ Ethernet interfaces
These ports have the logical cOS Core interface names X1 and X2. They both support 10 Gigabit Enhanced Small Form-factor Pluggable (SFP+) modules.
Note that only the SFP+ modules available from Clavister have been tested to function correctly with the 6000 Series hardware. Clavister cannot guarantee that others will function correctly.
2 x Ethernet interface expansion slots
These slots are on the right side of the front panel and, in a new unit, are covered with a removable panel since they will be empty. Expansion modules can be ordered separately for these slots and the following module options are available:
4 x SFP+ 10 Gigabit interfaces with QAT.
The QAT feature will be automatically used by cOS Core for IPsec acceleration.
Module installation is discussed further in Chapter 6, Interface Expansion Modules as well as details about logical name assignment in cOS Core.
Connecting to the Internet and Using InControl Zero Touch
Any Ethernet interface could be used for Internet connection but the G8 interface has a DHCP client enabled in the default cOS Core configuration. This means it can automatically receive a DHCP lease from an ISP if used for connection to the Internet. Note that this interface must be used for Internet connection when the unit is automatically managed on initial startup by InControl using the Zero Touch feature. This is discussed further in Section 1.3, Zero Touch Support.Note: The two USB Type A ports are not currently used | |
---|---|
The two USB Type A ports on the 6000 Series front panel are for future functionality and are not currently used by cOS Core. |
The full connection capabilities of all the NetWall 6000 Series Ethernet interfaces are listed at the end of Appendix A, NetWall 6000 Series Specifications.
RJ45 Ethernet Interface Status LEDs
The status lights on the sides of the NetWall 6000 Series RJ45 Ethernet interface sockets indicate the following states for each interface:Left LED:
Right LED:
Display and Keypad
The NetWall 6000 Series features a display and keypad on the front panel. This is not used by the current version of cOS Core and is intended for use by future versions.The NetWall 6000 Series product is able to support the Zero Touch feature in the Clavister InControl management software product. This means that it is possible to power up a brand new NetWall 6000 Series, connect it to the Internet, and the NetWall 6000 Series device will automatically register itself with an InControl server. The device can then be remotely brought under centralized InControl management and configured remotely, without any local configuration needing to be done.
However, this feature will only work if the following prerequisites are true:
The version of InControl being used for device management is 2.00.00 or later.
The FQDN or IP address of the management InControl server has been set in the MyClavister account associated with the NetWall 6000 Series device. This is done by logging in to the relevant MyClavister account, selecting Settings and then selecting the Zero Touch tab. Only one InControl server address can be associated with one MyClavister account.
The zero touch feature has been enabled for the license associated with the NetWall 6000 Series device. This in the MyClavister account by selecting Licenses and then enabling the Zero Touch button next to the relevant license. If the zero touch button is grayed out then the feature is not available with that device. There is an option in the previous step to always enable zero touch by default for all new licenses.
The cOS Core configuration is in its "factory default" state. Following an upgrade to a version that supports zero touch or any configuration change, this will require a manual reset to the default cOS Core configuration. In the Web Interface this is done by going to:
Status > Maintenance > Reset & Restart
And then selecting the following option:
Reset the configuration to current core default
Note that a full hardware reset to factory defaults will undo any cOS Core version upgrade and this should therefore not be done. Also note that any configuration change that is saved after a reset to the default configuration will disable the zero touch feature.
The NetWall 6000 Series can be connected to an ISP or other network that can provide Internet access and that has a DHCP server enabled which can provide a public DNS server address to the device. Note that physical connection to the Internet should be performed only after the device is running a zero touch supporting version of cOS Core with the factory default configuration.
Access is not blocked by surrounding network equipment for TCP traffic on port 998. This traffic is required for the NetWall 6000 Series to communicate with the InControl server. DNS traffic between the NetWall 6000 Series and public DNS servers must also not be blocked.
Internet Connections Must Use a Specific Interfaces for Zero Touch
When the NetWall 6000 Series is running a version of cOS Core that supports the zero touch feature, the initial connection to the Internet for InControl management should be made via the G8 interface for the feature to function.Zero Touch Can Also Simplify Hardware Replacement
In addition to simplifying the addition of a new NetWall 6000 Series, the zero touch feature can also simplify hardware replacement of a NetWall 6000 Series with another NetWall 6000 Series. When the replacement hardware is connected to the Internet, InControl can automatically install the correct license as well as the correct cOS Core version. In addition, InControl will upload its copy of the cOS Core configuration from the old hardware.A complete description of the zero touch feature and how it functions can be found in the separate InControl Administration Guide in the chapter titled Zero Touch.
The NetWall 6000 Series is equipped with sensors that provide cOS Core with information about operational parameters such as CPU temperature. This information is available to the administrator through the cOS Core 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 Core Administration Guide.
Before applying power to the NetWall 6000 Series and starting cOS Core, it is important to understand the customer and product registration procedures. There are two types of registration:
Registering as a Clavister Customer
This involves registering basic contact and company information on the Clavister website and establishing login credentials. Later, these credentials can also be used by cOS Core for automatically registering the 6000 Series hardware unit and automatically downloading the correct license.
This is a mandatory requirement for all new customers and needs to be done only once. A description of doing this can be found below. Even if registration is not done before starting the cOS Core wizard, the wizard will provide a link to the registration page so it can be done while the wizard is running.
Registration of a NetWall 6000 Series Hardware Unit
This is mandatory for every hardware unit before a license can be downloaded. It can be done in the following ways:
Automatic registration after cOS Core starts - This can done by the Setup Wizard which starts automatically in the Web Interface when cOS Core is started for the first time. The wizard is described in Section 4.1, Web Interface and Wizard Setup.
Manual registration of the NetWall 6000 Series on the Clavister website - This is described in the last half of this chapter. Manual registration may be necessary if the appliance does not have Internet access.
A. Registering as a Clavister Customer
The NetWall 6000 Series registration steps for a first time user of Clavister hardware are as follows:Go to the URL https://my.clavister.com in a web browser.
The MyClavister login page is presented. If you are already registered, log in and skip to part B below. If you are a new customer accessing MyClavister for the first time, click the Create Account link.
The registration page is now presented. The required information should be filled in. In the example below, a user called John Smith is registering.
When the registration details are accepted, an email is sent to the email address given so that the registration can be confirmed.
Below is an example of the heading in the email that would be received.
The confirmation link in the email leads back to the Clavister website to show that confirmation has been successful and logging in is now possible.
After logging in, the customer name is displayed with menu options for changing settings and logging out. Note also that multi-factor authentication can be enabled for increased security in Settings.
B. Registration of the NetWall 6000 Series
This section can be skipped if the NetWall 6000 Series unit has access to the Internet. With Internet access available, registration can be performed automatically by the cOS Core Setup Wizard which will appear as a browser popup window in the Web Interface when cOS Core starts for the first time. The wizard is described in Section 4.1, Web Interface and Wizard Setup.If the unit does not have Internet access then manual registration is required and this is done using the following steps:
Now, log into the MyClavister website and select the Register License menu option.
Select the NetWall option.
The registration fields will be displayed. After selecting the product type, enter the Hardware Serial Number and Service Tag. These two codes are found on a label which should be attached to the NetWall 6000 Series hardware itself. The label is usually found on the hardware unit's underside but may be found in another position.
The image below shows an example identification label which illustrates the typical layout of labels found on Clavister hardware products.
After Successful Hardware Registration
Once the NetWall 6000 Series unit is registered, a cOS Core license for the unit becomes available for download and installation from Clavister servers. This installation can be done automatically through the cOS Core Setup Wizard which is described in Section 4.1, Web Interface and Wizard Setup.If the NetWall 6000 Series is not connected to the Internet, the license must be manually downloaded from the cOS Core website and then manually uploaded.
All license installation options are listed and discussed in Section 4.4, License Installation.
Follow these general guidelines when installing the NetWall 6000 Series appliance:
Safety
Take notice of the safety guidelines laid out in Chapter 10, Safety Precautions. These are specified in multiple languages.
Caution: Noise levels can be elevated from fans | |
---|---|
The NetWall 6000 Series can emit elevated levels of fan noise and caution should be taken to protect hearing if spending periods of time in proximity to the appliance. It is also recommended that the NetWall 6000 Series operates within an acoustically contained area, such as a special computer room. |
Power
Make sure that the power source circuits are properly grounded and then use the power cord supplied with the appliance to connect it to the power source.
Using Other Power Cords
If your installation requires a different power cord than the one supplied with the appliance, be sure to use a cord displaying the mark of the safety agency that defines the regulations for power cords in your country. Such marks are an assurance that the cord is safe.
Power Overload
Ensure that the appliance does not overload the power circuits, wiring and over-current protection.
To determine the possibility of overloading the supply circuits, add together the ampere ratings of all devices installed on the same circuit as the appliance and compare the total with the rating limit for the circuit. The maximum ratings for the 6000 Series are listed in Appendix A, NetWall 6000 Series Specifications.
Surge Protection
A third party surge protection device should be considered and is strongly recommended as a means to prevent electrical surges reaching the appliance. This is mentioned again in Section 3.7, Connecting Power.
Temperature
Do not install the appliance in an environment where the ambient temperature during operation might fall outside the specified operating range. This range is documented in Appendix A, NetWall 6000 Series Specifications.
The intended operating temperature range is "room temperature". That is to say, the temperature most commonly found in a modern office and in which humans feel comfortable. This is usually considered to be between 20 and 25 degrees Celsius (68 to 77 degrees Fahrenheit). Special rooms for computer equipment may use a lower range and this is also acceptable.
Airflow
Make sure that airflow around the appliance is not restricted.
Dust
Do not expose the appliance to environments with elevated dust levels.
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, NetWall 6000 Series Specifications. |
The NetWall 6000 Series can be mounted on any appropriate stable, flat, level surface that can safely support the weight of the appliance and its attached cables. However, the NetWall 6000 Series is designed to be rack mounted and operation on a flat surface should be avoided, except when done for testing purposes and if only for a short period of time.
The NetWall 6000 Series can emit elevated levels of fan noise and caution should be taken to protect hearing when spending time in proximity to the appliance if it is being operated on a flat surface. It is not recommended to operate the unit outside of an acoustically isolated space.
Rack mounting is described next in Section 3.3, Rack Installation.
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. |
Once the brackets are firmly attached on either side, the unit can be mounted in a rack. Rear support is not required.
The NetWall 6000 Series is designed to be installed in most standard 19-inch equipment racks. The following general guidelines for racks should be followed:
The rack or cabinet used for mounting should be adequately secured to prevent it from becoming unstable and/or falling over.
Devices installed in the rack or cabinet should be mounted as low as possible, with the heaviest devices at the bottom and progressively lighter devices installed above.
The Rack Mounting Kit
Included in the 6000 Series packaging are the following:A front bracket kit.
A side-rail kit.
The ordering of kit attachment is not important but both the components listed above should be correctly installed before mounting the NetWall 6000 Series in a rack.
The front bracket kit consists of two brackets, each of which has three screws for attachment to the front-sides of the 6000 Series, as shown in the image below. There are pre-drilled holes already in the sides of the unit which are used for attaching these brackets.
A bracket should be attached to each side of the 6000 Series casing with a screwdriver using the screws supplied.
Attaching the side-rails is described next.
The side-rail kit consists of two side-rails with screws for fitting to the sides of the NetWall 6000 Series so it can be slid into a 1U rack mount.
Using a suitable screwdriver and the screws provided, attach a rail to both sides of the NetWall 6000 Series unit. There are pre-drilled holes in the unit for this.
The unit is now ready for sliding into a rack. After positioning the unit, the front brackets should be attached to the rack so the unit cannot slide out.
cOS Core Starts After Power Up
It is assumed that the NetWall 6000 Series unit is now unpacked, positioned correctly and power is applied. If not, the earlier chapters in this manual should be referred to before continuing.Clavister's cOS Core software is preloaded on the NetWall 6000 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 Core. The management computer's operating system can be any kind as long it can run a standard modern web browser for configuration using the cOS Core WebUI.
cOS Core Access Methods for Setup
Initial cOS Core software configuration can be done in one of the following ways:Using a web browser across a network connection
A standard web browser running on a standalone management computer (sometimes referred to as the management workstation) can be used to access the cOS Core Web Interface. This provides an intuitive graphical interface for cOS Core management. When this interface is accessed for the first time, a setup wizard runs automatically to guide a new user through key setup steps. The wizard can be closed if the administrator wishes to go directly to the Web Interface to perform setup manually.
The wizard is recommended for its simplification of initial setup and is described in detail in Section 4.1, Web Interface and Wizard Setup. The wizard assumes that configuring public Internet access is one of the tasks to be performed and has a step for this.
Using CLI commands across a network connection
The setup process can be performed using CLI commands which are input into a remote management computer running an SSH client. The management computer is linked across a network to an Ethernet interface on the firewall.
Once a network link to the CLI has been established, the manual configuration steps using the CLI are described in Section 4.3, Manual CLI Setup.
The CLI allows step by step control of the setup process and should be used by administrators who fully understand both the CLI and the setup steps required.
Using CLI commands via the local console
Alternatively, CLI access is possible using console emulation software running on an external computer connected directly to either the micro-USB console port on the 6000 Series hardware or via the RS-232 RJ45 console port. The USB port has precedence when both are connected. Micro-USB connection is described in Section 3.6, Micro-USB Console Port Connection and RJ45 connection is described in Section 3.5, RJ45 Console Port Connection.
In the default NetWall 6000 Series configuration, login credentials are enabled for the local console. These are a username of admin and a password of admin. These credentials come from the predefined cOS Core admin user, which is also used for SSH and Web Interface access.
The Default Management Ethernet Interface
After first-time startup, cOS Core automatically makes network management access available on a single predefined Ethernet interface and assigns to it the private IPv4 address 192.168.1.1 and network 192.168.1.0/24.For the NetWall 6000 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 NetWall 6000 Series support Automatic MDI-X so a crossover cable is not necessary.
Connection to an ISP for Internet Access
For access to the public Internet, another 6000 Series Ethernet interface should be selected for connection to an ISP. For example, G8 could be selected, although any other available interface could be used instead. In the cOS Core setup wizard, this interface used is always generically referred to as the WAN interface. cOS Core setup for Internet access is discussed further in Chapter 4, cOS Core Configuration.Note that in the default cOS Core configuration for the NetWall 6000 Series, the G8 interfaces already has a DHCP client enabled so an IP addresses can be automatically assigned by an ISP on connection.
Management Computer Ethernet Interface Setup
Traffic can flow between the designated management computer's Ethernet interface and the firewall's default management Ethernet interface if they are on the same IP network. This means the management computer's Ethernet interface should be first assigned the following static values:IP address: 192.168.1.30
Subnet mask: 255.255.255.0
Default gateway: 192.168.1.1
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 Core's default management interface. |
The following appendices at the end of this guide describe how to set up the management computer IP with different operating systems:
Tip: Skip this section if using the Web Interface for set up | |
---|---|
Console port connection can be skipped if cOS Core setup is going to be done using the cOS Core Web Interface since neither CLI or boot menu access will be needed. |
The local console port allows direct management connection to the NetWall 6000 Series unit from an external computer acting as a console terminal. This local console access can then be used for both management of cOS Core 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 Core Administration Guide.
Note that the NetWall 6000 Series has both an RJ45 console port and a micro-USB port (described in Section 3.6, 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 NetWall 6000 Series Local Console Connection
To get management access via the local console port, the following is needed:Connection Steps
To connect a terminal to the local console port, perform the following steps:Check that the console connection settings are configured as described above.
Connect one of the connectors on the cable directly to the local console port on the 6000 Series.
Connect the other end of the cable to a console terminal or to the serial connector of a computer running console emulation software.
The Default Local Console Login Credentials
The console user credentials for logging in are specified by the predefined admin user and are the same as the credentials for initial network access via the management Ethernet interface:It is recommended to change the password for this user during initial cOS Core configuration.
Remote Console Connection Using SSH
An alternative to using the local console port for CLI access is to connect remotely over a network via a physical Ethernet interface and using a Secure Shell (SSH) client on the management computer to issue CLI commands. This is discussed further in Section 3.4, Management Computer Connection.Tip: Skip this section if using the Web Interface for set up | |
---|---|
Console port connection can be skipped if cOS Core setup is going to be done using the cOS Core Web Interface since neither CLI or boot menu access will be needed. |
The local console port allows direct management connection to the 6000 Series hardware from an external computer acting as a console terminal. Local console access can then be used for both management of cOS Core with CLI commands or to enter the boot menu in order to access 6000 Series firmware loader options. The boot menu is described further in the separate cOS Core Administration Guide.
There is a physical micro-USB port (type micro-B) on the 6000 Series hardware that allows local console connection. This is an alternative to using the RJ45 local console port on the appliance (described in Section 3.5, RJ45 Console Port Connection). However, the micro-USB port will automatically take precedence if both are connected.
Connection Steps
To connect a computer to the local console port, perform the following steps:After connection to a PC, Windows will try to recognize the device and automatically install the appropriate driver through the Windows Update™ feature. If Windows is unable to do this automatically, the driver should be downloaded and installed manually.
To download micro-USB drivers manually, log into the relevant MyClavister account at https://my.clavister.com and go to Downloads > Tools & Utilities.
The Default Local Console Login Credentials
The console user credentials for logging in are specified by the predefined admin user and are the same as the credentials for initial network access via the management Ethernet interface:It is recommended to change the password for this user during initial cOS Core configuration.
Issuing CLI Commands
CLI commands can be issued via the local console port for both initial cOS Core setup as well as for ongoing system administration.Remote Console Connection Using SSH
An alternative to using the local console port for CLI access is to connect over a network via a physical Ethernet interface and using a Secure Shell (SSH) client on the management computer to issue CLI commands. This is discussed further in Section 3.4, Management Computer Connection.This section describes connecting power. As soon as power is applied, the NetWall 6000 Series will boot-up and cOS Core will start.
Important: Review the safety information | |
---|---|
Before connecting power, please review the electrical safety information found in Chapter 10, Safety Precautions. |
As standard, the 6000 Series is delivered with only a single PSU and the second PSU slot is occupied by a dummy slot filler. The filler is necessary so the PSU alarm is not activated. A second PSU must be ordered separately. The 6000 Series can operate with just one PSU installed and a second can be added if required. When two PSUs are installed, the 6000 Series runs using power from only one of the PSUs and the other delivers power only in the case of a failure by the primary unit. Installing and swapping PSUs is discussed further in Chapter 5, PSU Replacement.
Connecting AC Power
To connect power, follow these steps:There is a hinged silver metal plug retaining bracket on the PSU. This should be lifted up before inserting the power cable. Once the power cable is plugged in, it should be moved back over the plug to prevent it slipping out.
Plug the other end of the power cord into a grounded power outlet.
If a second PSU is to be used for redundancy, the dummy PSU should be removed and the actual PSU should be inserted in its place. The procedure for inserting the power cable should then be repeated for this second PSU.
Power is controlled by the rocker switch to the left of the PSU slots. To switch on, depress the switch and then immediately release it. To switch off, hold the switch depressed for at least 5 seconds. A green LED on each PSU will illuminate to show that the PSU has power and is functioning correctly.
The 6000 Series will boot up as soon as power is applied and cOS Core will start. The progress of the process can be seen on a CLI console connected to the local console port.
After a brief period of time, cOS Core will be fully initialized and the NetWall 6000 Series is then ready for configuration using a direct console connection or via a network connection to the default management Ethernet interface.
Initial cOS Core configuration is described in Chapter 4, cOS Core Configuration.
Connecting DC Power
The option exists to fit a DC PSU into the NetWall 6000 Series which can be connected to a DC power source. If required, a second DC PSU can be installed for redundancy. Make sure any AC PSU that is already installed is removed.A NetWall 6000 Series PSU has a single DC input supporting +/- 48VDC and return feed. A dedicated circuit breaker supporting the labeled current requirements is needed for each PSU if two are installed.
It is common that DC power is routed through DC power distribution panels on each rack in a typical site, and using battery backups providing 48 VDC. These might be located at the top of each rack in which the NetWall 6000 Series is to be installed. Two pairs of suitable cables connected to each set of terminal studs on the power distribution panel are required.
Make sure to connect the input and return feed to the correct power distribution feed since there is no standard coloring scheme for DC power cables. The 6000 Series appliance must be connected to earth ground during operation. Connect a cable to an earth ground from the cabinet or other suitable grounding point to the chassis by fastening a U-type lug to the end of the ground wire and fasten it to the chassis with the power supply retaining screw.
Important | |
---|---|
The power feed ground and chassis ground must be connected to the same earth point at an installation site. |
The following procedure is required for connecting power to a PSU:
Connect the 6000 Series appliance to an earth ground with the following steps:
Ensure a suitably qualified electrician has correctly installed the wiring.
Connect one end of a suitable cable to the chassis ground point.
Connect the other end of the cable to an earth ground. For example, to the rack cabinet in which the 6000 Series appliance is installed.
Connect suitable DC cables to the first PSU with the following steps:
Make sure that the voltage from all DC power source cables is 0V before and during installation. Take precautions so that power cannot accidentally be restored during installation.
Ensure a suitably qualified electrician has correctly installed all power connections.
Connect the 6000 Series DC power connector cable U-type lugs to the power distribution panel:
Fasten the positive (yellow) cable lug to the "+" distribution panel.
Fasten the black (negative) cable lug to the "-" distribution panel.
Connect the DC power cable to the DC terminal port on the PSU.
Repeat the previous 2 steps for a second DC PSU, if it is installed.
The DC distribution panel should now be powered on and then the following checks performed:
Verify that the first PSU's LED is illuminated.
If a second DC PSU is installed, power on the second power distribution.
Verify the second PSU's LED is illuminated.
Verify cOS Core startup.
Restarting the 6000 Series
In order to restart the 6000 Series hardware manually, the On/Off rocker switch should be held in and then released. This will restart the 6000 Series and reinitialize cOS Core so that it boots up again. This process can also be initiated through cOS Core. For example, using the CLI shutdown command.Important: Protecting against power surges | |
---|---|
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 NetWall 6000 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 chapter discusses initial cOS Core configuration for the 6000 Series. The initial setup sections consist of:
Section 4.1, Web Interface and Wizard Setup describes using a web browser with the cOS Core Setup Wizard over a network connection.
Section 4.2, Manual Web Interface Setup describes using a web browser over a network connection to perform setup manually (without the wizard).
Section 4.3, Manual CLI Setup describes manual setup using the cOS Core CLI either over an SSH network connection or directly through a local console connection to cOS Core.
In all the above cases, it is assumed that the requirement is to set up cOS Core so that traffic from a protected network can enter one firewall Ethernet interface, be filtered, and then exit another Ethernet interface towards the Internet or other wide area network.
Tip: Upgrade to the latest cOS Core version | |
---|---|
A new NetWall 6000 Series unit may not have the very latest cOS Core version pre-installed. After initial setup, it is recommended to upgrade to the latest available cOS Core version. The procedure for upgrading is described in the separate cOS Core Administration Guide. |
This section describes the setup when accessing cOS Core for the first time through a web browser. The cOS Core user interface accessed in this way is called the Web Interface (or WebUI). It is assumed that a physical network connection has been set up from a management computer to the default management Ethernet interface (described in Section 3.4, Management Computer Connection).
Note: Some screenshots have been rearranged | |
---|---|
Some of the screenshot images in this section have been rearranged to better fit the page size. However, all relevant details in the images have been preserved. |
Connect to cOS Core By Browsing to https://192.168.1.1
Using a modern web browser, enter the address https://192.168.1.1 into the navigation window.
Note: HTTP access is disabled | |
---|---|
HTTP management access is disabled in the default cOS Core configuration and HTTPS must be used. Unencrypted HTTP access can be enabled by the administrator but this is not recommended. |
Troubleshooting
If there is no response from cOS Core and the reason is not clear, refer to the checklist in Section 4.6, Setup Troubleshooting .Important: Do not access cOS Core via a proxy server | |
---|---|
Make sure the web browser doesn't have a proxy server configured for the cOS Core management IP address. |
The cOS Core Self-signed Certificate
When responding to the first https:// request in a browser session, cOS Core will send a self-signed certificate to the browser. Browsers will automatically flag this self-signed certificate as posing a potential security risk. For example, the following message might be displayed by the browser.
The browser should now be told to accept the Clavister certificate to continue.
Note: Sending a CA signed certificate can be configured | |
---|---|
It is possible to configure cOS Core to use a CA signed certificate instead of its default self-signed certificate for the management login. Doing this is described in the cOS Core Administration Guide. |
The Login Dialog
cOS Core will next respond with the initial login dialog page, as shown below.
The available Web Interface language options are selectable at the bottom of this dialog. This defaults to the language set for the browser if cOS Core supports that language.
Enter the default administrator username credentials of username admin and password admin.
Starting the Setup Wizard
After logging in for the first time, the cOS Core Web Interface will appear and the cOS Core setup wizard will begin automatically in a popup window. If the wizard is blocked by the browser, it can be started manually by pressing the Setup Wizard button in the Web Interface toolbar (shown below).
Once the wizard is started, the first dialog displayed is the wizard welcome screen.
Canceling the Wizard
The setup wizard can be canceled at any point before the final Activate screen. It can be run again by pressing the Setup Wizard button in the Web Interface toolbar. Once any configuration changes have been made and activated, either through the wizard, Web Interface or CLI, then the wizard cannot be run since this requires that cOS Core has its factory defaults.The Wizard Assumes Internet Access Is Possible
The wizard assumes that Internet access will be configured. If this is not the case, for example if the firewall is being used in Transparent Mode between two internal networks, then the configuration setup is best done using the manual Web Interface steps or through the CLI instead and these methods are explained in subsequent sections.Advantages of the Wizard
The wizard makes setup easier because it automates what would otherwise be a more complex set of individual setup steps. It also reminds the administrator to perform important tasks such as setting the date and time and configuring a log server.The steps that the wizard goes through following the welcome screen are listed next.
Wizard step 1: Enter a new admin password and optionally change the username
The first step in setup with the wizard is to enter a new password for the admin user. The admin username can also be changed if required, as shown in the screenshot below.The Enforce Strong Passwords option is present in cOS Core versions from 11.05 onwards. This is a global setting that will enforce the listed strong passwords rules for all users in any local user database in the configuration. If required, this option can be disabled later. However, it is recommended to leave this option enabled, which means that the default admin password must be changed to a conforming strong password before the wizard can move on to the next step.
Note that restoring cOS Core to factory defaults will restore the original admin/admin credential combination for management access.
Wizard step 2: Set the date and time
Many cOS Core functions rely on an accurate date and time, so it is important that this is set correctly in the fields shown below. The default time zone location is ClavisterHQ which means the default location and time zone will be Stockholm. If this is not correct it should be changed to another location and timezone using the drop-down list.
Wizard step 3: Select transparent mode interfaces
This step allows any transparent mode interfaces to be set up. If no transparent mode interfaces are required, leave this dialog in the default Normal Mode and go to the next step. Transparent mode interfaces can be configured at any time later, outside of the wizard.
Wizard step 4: Select the WAN interface
Next, you will be asked which interface that will be used to connect to an ISP for Internet access.
Wizard step 5: Select the WAN interface settings
This step selects how the WAN connection to the Internet will function. It can be one of Manual configuration, DHCP, PPPoE or PPTP as shown below.
These four different connection options are discussed next in the subsections 5A to 5D that follow.
5A. Static - manual configuration
Information supplied by the ISP should be entered in the next wizard screen. All fields need to be entered except for the Secondary DNS server field.
5B. DHCP - automatic configuration
All required IP addresses will automatically be retrieved from the ISP's DHCP server with this option. No further configuration is required for this so it does not have its own wizard screen.
5C. PPPoE settings
The username and password supplied by an ISP for PPPoE connection should be entered. The Service field should be left blank unless the ISP supplies a value for it.
DNS servers are set automatically after connection with PPPoE.
5D. PPTP settings
The username and password supplied by an ISP for PPTP connection should be entered. If DHCP is to be used with the ISP then this should be selected, otherwise Static should be selected followed by entering the static IP address supplied by the ISP.
DNS servers are set automatically after connection with PPTP.
Wizard step 6: DHCP server settings
If the firewall is to function as a DHCP server, it can be enabled here in the wizard on a particular interface or configured later.The range of IPv4 addresses that can be handed out must be specified in the form n.n.n.n-n.n.n.n, where n is a number between 0 and 255 and n.n.n.n is a valid IPv4 address within a subnet local to the firewall.
For example, the private IPv4 address range might be specified as 192.168.1.50 - 192.168.1.150 with a netmask of 255.255.255.0.
For the default gateway, it is recommended to specify the IPv4 address assigned to the internal network interface. The DNS server specified should be the DNS supplied by an ISP.
Wizard step 7: Helper server settings
Optional NTP and Syslog servers can be enabled here in the wizard or configured later. Network Time Protocol servers keep the system date and time accurate. Syslog servers can be used to receive and store log messages sent by cOS Core. By selecting the Clavister option, the current time will be updated over the Internet from Clavister's own timeserver.
When specifying a hostname as a server instead of an IP address, the hostname should be prefixed with the string dns:. For example, the hostname host1.company.com should be entered as dns:host1.company.com.
Wizard step 8: Activate setup
The final step for the configuration is to save and activate it by pressing the Activate button. After this step the Web Interface returns to its normal appearance and the administrator can continue to configure the system.
Wizard step 9: License Activation
This last and optional step is to install a license which is fetched automatically from Clavister servers. Internet access must have been set up in previous wizard steps for this option to function. The only input required is the MyClavister username and password for the Clavister website. This also creates a lasting link between the 6000 Series and the Clavister servers so that any future license updates can be installed automatically.
If customer registration has not been previously been done, a link is provided to open a browser window to complete registration. After registration, come back to this step.
Alternatively, this step can be skipped and license installation can be done later, in which case cOS Core will run in demo mode with a 2 hour time limit. After the 2 hour period, only management access will be allowed.
If a license is installed at this point, the wizard will then ask if a reconfigure or restart operation should be performed. To ensure that the 6000 Series can make use of the full capabilities of the license, the restart option should be chosen.
Running the Wizard Again
Once the wizard has been successfully finished and activated, it cannot be run again. The one exception to this is if cOS Core has its default configuration restored as part of a factory reset. In this case, cOS Core will behave as though it were being started for the first time.This section describes initial cOS Core configuration performed directly through the Web Interface, without using the setup wizard. Configuration is done as a series of individual steps, giving the administrator more direct control over the process. Even if the wizard is used, this section can also serve as a good introduction to using the Web Interface for configuring key aspects of cOS Core.
Ethernet Interfaces
The physical connection of external networks to the firewall is through the various Ethernet interfaces which are provided by the hardware platform. On first-time startup, cOS Core scans for these interfaces and determines which are available and allocates their names. The first interface detected in the scan always becomes the initial default management interface and this cannot be changed beforehand.All cOS Core Ethernet interfaces are logically equal for cOS Core and, although their physical capabilities may be different, any cOS Core interface can perform any logical function.
The NetWall 6000 Series uses the G1 interface as its default management interface. To describe manual Internet setup, it is assumed here that the G1 interface will also be used for connection to a protected internal client network and the G2 interface will be used for connection to the public Internet. Note that the G8 interface has a DHCP client enabled in the default configuration for automatic Internet configuration.
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. This is done by first selecting the System option from the Web Interface toolbar and then Local User Databases from the navigation pane to display the local user database list, as shown below.
Next, select AdminUsers and then the Users tab to display the contents of this predefined database
Select the default user Admin to open a dialog to change its password.
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 is weak. 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 rely on an accurate date and time, so it is important that this is set correctly. To do this, select System > Device > Date and Time. The current system time is displayed and this can be changed by selecting the date and time fields then manually entering the desired figures. Pressing the Set button will then set the time to the entered values.
Also choose the correct time zone from the Location drop-down list. The default location is ClavisterHQ which is Stockholm time.
Alternatively, the Synchronize button can be pressed to get the current date and time from external Network Time Protocol (NTP) servers. Clavister's own NTP server is also an option. Using NTP servers will require Internet access.
An example of configuring a custom NTP server configuration is shown below.
Note: Use an FQDN address for a time server | |
---|---|
An FQDN Address object must be used when specifying a time server address. See the relevant cOS Core Administration Guide section for more explanation. |
Once the values are set correctly, press the OK button to save the values temporarily. Configuration changes will not become active until the new configuration becomes the current and active configuration. Doing this is discussed next.
Activating Configuration Changes
To activate any cOS Core configuration changes made so far, select the Save and Activate option from the Configuration menu (this procedure is also referred to as deploying a configuration).
A dialog is then presented to confirm that the new configuration is to become the running configuration.
After clicking OK, cOS Core reconfiguration will take place and, after a short delay, the Web Interface will try to reconnect to the firewall.
If no reconnection is detected by cOS Core within 30 seconds (this length of time is a setting that can be changed) then cOS Core will revert back to the original configuration. This is to ensure that a new configuration does not accidentally lock out the administrator. After reconfiguration and reconnection, a success message will be displayed.
Reconfiguration is a process that the cOS Core administrator may initiate often. Normally, reconfiguration takes a brief amount of time and causes only a slight delay in traffic throughput. Active user connections through the firewall should rarely be lost.
Tip: How frequently to commit configuration changes | |
---|---|
It is up to the administrator how many changes to make before activating a new configuration. Activating changes in small batches can be the best approach in order to check that a small set of changes work as planned. However, it is not advisable to leave changes uncommitted for long periods of time, such as overnight, since any system outage will result in the pending changes being lost. |
Automatic Logout
If there is no activity through the Web Interface for a period of time (the default is 15 minutes), cOS Core will automatically log the user out. If they log back in through the same web browser session then they will return to the point they were at before the logout occurred and no pending changes are lost.Setting Up Internet Access
Setting up public Internet access manually using the Web Interface 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 Web Interface are discussed next.
Note that on the NetWall 6000 Series, a DHCP client is enabled in the default configuration on the G8 interface so that usually method B is used. The other methods are included here in case they are needed.
A. Static - manual configuration
Manual configuration means that there will be a direct connection to the ISP and all relevant IP addresses for the connecting interface are fixed values that will be entered into cOS Core manually.Note: The interface DHCP option should be disabled | |
---|---|
For static configuration of the Internet connection, the DHCP option must be disabled in the properties of the Ethernet interface that will connect to the ISP. . |
The initial step is to set up a number of IPv4 address objects in the cOS Core Address Book. Let us assume that the interface used for Internet connection is to be G2 and that the static public IPv4 address for this interface is to be 203.0.113.35, the ISP's gateway IPv4 address is 203.0.113.1, and the network to which they both belong is 203.0.113.0/24.
Now, add the gateway IP4 Address object using the address book name wan_gw and assign it the IPv4 address 203.0.113.1. The ISP's gateway is the first router hop towards the public Internet from the firewall. Go to Objects > Address Book in the Web Interface.
The current contents of the address book will be listed and will contain a number of predefined objects automatically created by cOS Core after it scans the interfaces for the first time. The screenshot below shows the initial address book for the NetWall 6000 Series.
Note: The all-nets address | |
---|---|
The IPv4 address object all-nets is a wildcard address that should never be changed and can be used in many types of cOS Core rules to refer to any IPv4 address or network range. |
All the Ethernet interface related address objects are gathered together in an address book folder called InterfaceAddresses. By clicking on this folder, it will be opened and the individual address objects it contains can be viewed. A screenshot of the first few lines of predefined addresses in the folder is shown below.
On initial startup, two IPv4 address objects are created automatically for each Ethernet interface detected by cOS Core. One IPv4 address object is named by combining the physical interface name with the suffix "_ip" and this is used for the IPv4 address assigned to that interface. The other address object is named by combining the interface name with the suffix "_net" and this is the network to which the interface belongs.
Tip: Creating address book folders | |
---|---|
New folders can be created when needed and provide a convenient way to group together related IP address objects. The folder name can be chosen to indicate the folder's contents. |
Now click the Add button at the top left of the list and choose the IP4 Address option to add a new address to the folder.
Enter the details of the object into the properties fields for the IP4 Address object. Below, the IPv4 address 203.0.113.1 has been entered for the address object called wan_gw. This is the IP of the ISP's router which acts as the gateway to the public Internet.
Click the OK button to save the values entered.
Then set up G2_ip to be 203.0.113.35. This is the IPv4 address of the G2 interface which will connect to the ISP's gateway.
Lastly, set the IP4 Address object G2_net to be 203.0.113.0/24. Both the address objects G2_ip and wan_gw must belong to the same network in order for the interface to communicate with the ISP.
Together, these three IPv4 address objects will be used to configure the Ethernet interface connected to the Internet which, in this example, is G2. Select Network > Interfaces and VPN > Ethernet to display a list of the physical interfaces and address book objects assigned to them. The first lines of the default interface list for the NetWall 6000 Series are shown below. Note that this list includes E1-1 to E1-4 which correspond to Ethernet interfaces in the first expansion module.
Click on the interface in the list which is to be connected to the Internet. The properties for this interface will now appear and the settings can be changed including the default gateway.
Press OK to save the changes. Although changes are remembered by cOS Core, the changed configuration is not yet activated and won't be activated until cOS Core is told explicitly to use the changed configuration.
Remember that DHCP should not be enabled when using static IP addresses and also that the IP address of the Default Gateway (which is the ISP's router) must be specified. As explained in more detail later, specifying the Default Gateway also has the additional effect of automatically adding a route for the gateway in the cOS Core routing table.
At this point, the connection to the Internet is configured but no traffic can flow to or from the Internet since all traffic needs a minimum of the following two cOS Core configuration objects to exist before it can flow through the firewall:
A route defined in a cOS Core routing table which specifies on which interface cOS Core can find the traffic's destination IP address.
If multiple matching routes are found, cOS Core uses the route that has the smallest (in other words, the narrowest) IP range.
An IP policy therefore needs to exist that will allow traffic from clients to the Internet.
To add an IP policy, go to Policies > Firewalling > Main IP Rules. The main IP rule set will now be displayed. Press the Add button and select IP Policy from the menu.
The properties for the new object will appear. In this example, the policy will be called lan_to_wan. The Service is set to http-all which is suitable for web browsing (it allows HTTP and HTTPS connections).
The destination network is specified as the predefined IP4 Address object all-nets. This is used since it cannot be known in advance to which IP address web browsing will be directed and all-nets allows browsing to any IP address. IP rule sets are processed in a top down fashion, with the search ending at the first matching entry. An all-nets entry like this should be placed towards the end of the rule set since other rules with narrower destination addresses should trigger first.
In addition to entering the above for the policy, the Source Translation should be set to NAT and the Address Action left as Outgoing Interface IP. Note that the default source translation value for an IP policy is Auto and this would also provide NAT translation between a private and public IP address but NAT is specified explicitly in this section for clarity.
By using NAT, cOS Core will use the destination interface's IP address as the source IP. This means that external hosts will send their responses back to the interface IP and cOS Core will automatically forward the traffic back to the originating local host. Only the outgoing interface therefore needs to have a public IPv4 address and the internal network topology is hidden.
For web browsing, public DNS lookup also needs to be allowed in order to resolve URIs into IP addresses. The service http-all does not include the DNS protocol so a similar IP rule set entry that allows this if needed. This could be done with a single IP policy that uses a custom service which combines the HTTP and DNS protocols. However, the recommended method is to create an entirely new IP set entry that specifies the service as dns-all. This provides more clarity when the configuration is examined for problems. The screenshot below shows a new IP policy called lan_to_wan_dns being created to allow DNS.
As was done for HTTP, NAT should also be enabled with this IP policy so all DNS queries are sent out by cOS Core with the outgoing interface's IP address as the source IP.
For the Internet connection to work, a route also needs to be defined so that cOS Core knows on which interface web browsing traffic should leave the firewall. This route defines the interface where the network all-nets (in other words, any network) will be found. If the default main routing table is opened by going to Network > Routing > Routing Tables > main, the route needed should appear as shown below.
This all-nets route is added automatically when the Default Gateway for an Ethernet interface is specified, as was done earlier when setting up the required IP4 Address objects.
Note: Disabling automatic route generation | |
---|---|
Automatic route generation is enabled and disabled with the setting "Automatically add a default route for this interface using the given default gateway" which can be found in the properties of the interface. |
As part of the setup, it is also recommended that at least one DNS server is also defined in cOS Core. A DNS server or servers (a maximum of three can be configured) will be used when cOS Core itself needs to resolve URIs, such as with FQDN address objects. It can also be important for certificate handling.
Assume an IPv4 address object called wan_dns1 has already been defined in the address book and this is the address for the first DNS server. By choosing System > Device > DNS, the DNS server dialog will open and this object from the address book can be assigned as the first server.
B. DHCP - automatic configuration
All the required IP addresses for Internet connection can, alternatively, be automatically retrieved from an ISP's DHCP server by enabling the DHCP Client option for the interface connected to the ISP.Note that on the NetWall 6000 Series, a DHCP client is enabled in the default cOS Core configuration on the G8 interface. Enabling DHCP is described here in case it needs to be manually enabled.
A DHCP client is enabled by first selecting Network > Interfaces and VPN > Ethernet to display a list of all the interfaces.
Click the G2 interface in the list to display its properties and select the option to enable the interface as a DHCP client.
Usually, a DHCP Host Name does not need to be specified but can sometimes be needed by an ISP to uniquely identify the firewall as a particular DHCP client for the ISP's DHCP server.
On connection to the ISP, all required IP addresses are retrieved automatically from the ISP via DHCP and 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.
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 define a rule set entry that will allow traffic from the source network and source interface to flow to the destination network all-nets and the destination interface.
C. PPPoE setup
For PPPoE connection, we must create a PPPoE tunnel interface associated with an Ethernet interface. Assume that the Ethernet interface is G2 and the PPPoE tunnel object created is called wan_pppoe. Go to Network > Interfaces and VPN > PPPoE and select Add > PPPoE Tunnel. These values can now be entered into the PPPoE tunnel properties dialog.
An 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 we go to Network > Routing > Routing Tables > main we can see this route.
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 rule set entry that will allow traffic from the source network and source interface to flow to the destination network all-nets and the destination interface. Here, the destination interface is the PPPoE tunnel that has been defined.
D. PPTP setup
For PPTP connections, a PPTP client tunnel interface object needs to be created. Let us assume that the PPTP tunnel will be called wan_pptp with a remote endpoint 203.0.113.1 which has been defined as the IP4 Address object pptp_endpoint. Go to Network > Interfaces and VPN > PPTP/L2TP Clients and select Add > PPTP/L2TP Client. The values can now be entered into the properties dialog and the PPTP option should be selected.
Your ISP will supply the correct values for pptp_username, pptp_password and the remote endpoint. An Ethernet 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 entries 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. For the public Internet this should be all-nets.
If we go to Network > Routing > Routing Tables > main we can see this route.
If the PPTP 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 a rule set entry 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, which is the PPTP tunnel.
DHCP Server Setup
If a NetWall 6000 Series interface is to have a DHCP server enabled on it, first create an IP4 Address object which defines the address range to be handed out. Here, it is assumed that this has the name dhcp_range. It is also assumed that another IP4 Address object dhcp_netmask has been created which specifies the netmask.We now create a DHCP server object called my_dhcp_server which will only be available on, for example, the G1 interface. To do this, go to Network > Network Services > DHCP Servers and select Add > DHCP Server. The server properties can now be specified.
An example IP pool range might be 192.168.1.10 - 192.168.1.20 with a netmask of 255.255.0.0.
In addition, it is important to specify the Default gateway for the server. This will be handed out to DHCP clients on the internal networks so that they know where to find the public Internet. The default gateway is always the IPv4 address of the interface on which the DHCP server is configured. In this case, G1_ip.
To set the default gateway, select the Options tab.
Also in the Options tab, we should specify the DNS address which is handed out with DHCP leases. This could be set, for example, to be the IPv4 address object dns1_address.
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.To send logs to Syslog server, first create an IP4 Address object called, for example, syslog_ip which is set to the IPv4 address of the server. Next, select System > Device > Log and Event Receivers and choose Add > Syslog Receiver.
The Syslog server properties dialog will appear. Specify a name, for example my_syslog, and specify the address as the syslog_ip object.
Tip: Address book object naming | |
---|---|
The cOS Core address book is organized alphabetically so when choosing names for IP address objects it is best to have the descriptive part of the name first. In this case, use syslog_ip as the name and not ip_syslog. |
Allowing ICMP Ping Requests
As another example of setting up IP rule set entries, it can be useful to allow outgoing ICMP ping messages to pass through the firewall. To allow hosts on the internal network G1_net. to send ping messages to any hosts on the Internet, select Policies > Firewalling > Main IP Rules > Add and enter the values shown below for the IP policy called allow_ping_outbound. This uses the predefined service called ping-outbound.
As with previous policy definitions, NAT should also be enabled if the protected local hosts have private IPv4 addresses. The ICMP messages will then be sent out from the firewall with the IP address of the interface connected to the ISP as the source. Responding hosts will send back ICMP responses to this address and cOS Core will then forward the traffic to the correct private IPv4 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, as shown in the example below.
Logging is enabled by default for an IP rule set entry which means that a log message will be sent to all configured log servers whenever the entry triggers. Only log events that have a specified severity or above will be sent. The administrator can choose the minimum severity for log messages in each IP rule set entry, as shown below.
If this IP policy were the only one defined, the main IP rule set listing would be as shown below.
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.This chapter describes the cOS Core setup steps using cOS Core CLI commands. The CLI is accessible using either of the following two methods:
Using the Local Console
An external computer running a console emulator can be physically connected directly to the firewall's local console port on the NetWall 6000 Series.
Using a Network Connection
An SSH client on an external computer can be used to connect across a network to the IPv4 address 192.168.1.1 on the default management Ethernet interface.
The physical network connection setup to the computer running the client is described in Section 3.4, Management Computer Connection and is the same as that used in Section 4.1, Web Interface and Wizard Setup. If there is a problem with the management computer connection, a help checklist can be found in Section 4.6, Setup Troubleshooting .
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 AdminUsersDevice:/AdminUsers>
Tip: Tab completion makes CLI usage easier | |
---|---|
The tab key can be pressed at any time so that cOS Core either completes a command portion or provides a list of possible command options. |
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 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
Note: Qualifying the names of IP objects in folders | |
---|---|
On initial startup of the 6000 Series, cOS Core automatically creates and fills the InterfaceAddresses folder in the cOS Core address book with Ethernet interface related IPv4 address objects. Note that when an IP address object which is located in a folder is specified in the CLI, the object name must be qualified with the name of its parent folder. For example, to reference the address G2_ip, it must be qualified with the folder name InterfaceAddresses so it becomes InterfaceAddresses/G2_ip. If an object is not contained in a folder and is at the top level of the address book then no qualifying parent folder name is needed. |
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:
The typical output from this will be similar to the following:
Device:/>
show Interface Ethernet G2 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.Without a valid license installed, cOS Core will run in demo mode (demonstration mode) which means that it will cease to function after two hours of operation. Restarting cOS Core will re-enable cOS Core for another two hours. To remove this 2 hour restriction, a valid license must be installed.
Licenses are files which are made available for download from the Clavister servers but before they become available, the user must have registered themselves with Clavister and doing this is described in Chapter 2, Registering with Clavister.
The NetWall 6000 Series Uses a SECaaS License
When cOS Core runs on the NetWall 6000 Series hardware it requires a subscription based Security as a Service (SECaaS) license. The SECaaS license is managed in the same way as an older non-SECaaS license but requires the following to be configured in cOS Core:Internet Access.
A public DNS server.
SECaaS licenses require periodic access to Clavister license servers to check validity and for automatic updates. If cOS Core cannot reach the license servers within a certain period of time then throughput is reduced to a maximum limit of 1 Mbps.
Installation Methods
The following methods can be used for installing the first cOS Core license in the 6000 Series unit:Automatically through the Setup Wizard
As described in Section 4.1, Web Interface and Wizard Setup, when the wizard is used for initially configuring Clavister hardware, the administrator can choose to install a license as one of the wizard steps.
Automatically through the Web Interface
Go to Status > Maintenance > License and enter the customer's login credentials for the Clavister website, then press Activate. The license is fetched automatically across the public Internet and installed.
Automatically through the CLI
In the CLI, enter the command:
Device:/>
license -activate -request -username=myname -password=mypass
The customer username and password login are included in the command and the license is fetched automatically across the Internet. The login credentials are the same ones that are used for Clavister website login. The reconf or shutdown command should be used to complete installation.
Manually through the Web Interface or SCP
This method is the only choice when the hardware does not have a connection to the public Internet. The procedure consists of the following steps:
Using a web browser, go to https://my.clavister.com and log in to the relevant MyClavister account. This will require registration if this has not been done already.
Go to Licenses > Register License.
Select the option Register by Service Tag and Hardware Serial Number.
Enter the Serial Number and Service Tag codes. For Clavister hardware products, these codes are found on a label on the unit.
Download a license from the license list to the computer's local disk.
The license file can be uploaded using SCP. cOS Core automatically recognizes an uploaded license file but it is then necessary to manually to perform a reconfigure or reboot operation to complete installation.
Alternatively, the license file can be uploaded to the firewall through the cOS Core Web Interface by going to Status > Maintenance > License and pressing the Upload button to select the license file. Following upload, cOS Core will install the file.
Important: Restart is recommended after license installation | |
---|---|
After installing a license, a restart of cOS Core is recommended. This will ensure that cOS Core memory is correctly configured for the license parameters. When installing a license through the Web Interface or when using the startup wizard, the options to restart or reconfigure are presented to the administrator. With the CLI and SCP, these options are not presented and restart must be initiated by the administrator. For restarting via the Web Interface, go to Status > Maintenance > Reset & Restart. With the CLI, use the command:
|
Installing Licenses Updates
Installing license updates can be done using one of the following methods:Automatically, by creating a permanent link between the 6000 Series and the associated MyClavister account on the Clavister website. Doing this is one of the last options in the setup wizard. Alternatively, the link can be established later by going to the Status > Maintenance > MyClavister in the Web Interface and entering the login credentials for the Clavister website.
The link can also be created in the CLI with the following command:
Device:/>
license –myclavister –username=myuser –password=mypass
Once the link is established, cOS Core will alert the administrator in the Web Interface when a license update is available. The update process is then initiated by pressing the Update button in the license page.
Manually, by logging into and downloading from the Clavister website and then uploading manually to cOS Core.
Automatically through the separate InControl software product which is used for managing cOS Core configurations. This method can also be used to install the first license.
Licenses and license installation are described further in the separate cOS Core Administrators Guide.
Entering the Boot Menu
When the 6000 Series starts up, and before it has finished initializing, the startup process can be suspended and the boot menu entered by repeatedly pressing the Esc key on the keyboard of cOS Core's local console (connecting this is described in Section 3.4, Management Computer Connection). The boot menu provides a number of options related to the loading of cOS Core.Boot Menu Options
The choices displayed in the boot menu are the following:Boot system <version-number>
This will exit the boot menu and initialization of cOS Core will resume.
Boot-failure recovery
The NetWall 6000 Series will boot using its own internal system memory. cOS Core will then run in a safe mode. This means the the system will function but only limited resources will be available. However, these resources are sufficient for cOS Core to be used with a full CLI command set to troubleshoot problems.
Reset system to factory default
This restores both the current configuration and the cOS Core version to the factory settings. Any cOS Core version upgrades that have been installed will be lost.
Using this option is discussed further in Chapter 8, Resetting to Factory Defaults. However, note this reset will only affect cOS Core and will not reset the whole 6000 Series system.
Restore system default configuration
This restores only the default configuration. No cOS Core version upgrades that have been installed will be lost. This is the recommended option unless a full reset is required.
The boot menu is also discussed in the separate cOS Core Administration Guide.
This section deals with connection problems that might occur when connecting an external management computer to cOS Core. It is assumed that the 6000 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 6000 Series has powered up and cOS Core 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 Core is will allow the initial management connection after cOS Core 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 Core 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 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 Core to suit the requirements of a particular networking scenario.
The primary reference documentation for cOS Core consists of:
Other available documents are:
In addition, each cOS Core 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 Core release. Alternatively, documentation for the latest cOS Core release can be read in HTML format at https://docs.clavister.com.
The cOS Core Administrators Guide
This guide is a comprehensive description of all cOS Core features and includes a detailed table of contents with a comprehensive index to quickly locate particular topics.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 Core Objects and Rules
As a minimum, the new administrator should become familiar with the cOS Core Address Book for defining IP address objects and with the cOS Core IP rule set for defining IP Rule objects which allow or block different traffic and which can also be used to set up NAT address translation.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 Next Generation Firewall.
An alternative to IP Rule objects is to use IP Policy objects and this is the recommended object to use to control which traffic can flow through the firewall. These have essentially the same function but simplify the setting up of address translation and the use of important functions such as application control, virus scanning and web content filtering.
In addition to IP 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 rule and route to exist in order for it to traverse the firewall. A number of routes are automatically defined in cOS Core that route the network configured on an interface to that interface.
ALGs
Once the address book and IP rules are understood, the various ALGs will probably be relevant for managing higher level protocols such as HTTP. For example, for management of web browsing, the HTTP ALG provides a number of important features such as content filtering. Using IP Policy objects is the recommended method of applying ALGs to traffic since the ALG does not need to be created as a separate configuration object.VPN Setup
A common requirement is to quickly setup VPN networks based on Clavister Next Generation Firewalls. The cOS Core Administration Guide includes an extensive VPN section and as part of this, a VPN Quick Start section which goes through a checklist of setup steps for nearly all types of VPN scenarios.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
By default, certain events will generate log messages and at least one log server should be configured in cOS Core to capture these messages. However, a cOS Core feature called memlog will capture recent log messages in local cOS Core memory. The administrator should review what events are important to them and at what severity. The cOS Core Log Reference Guide provides a complete listing of the log messages that cOS Core is capable of generating.The CLI Reference Guide
The CLI Reference Guide provides a complete listing of the available CLI commands with their options. A CLI overview is also provided as part of the cOS Core Administration Guide.cOS Core Education Courses
For details about classroom and online cOS Core education as well as cOS Core certification, visit the Clavister company website at https://www.clavister.com or contact your local sales representative.Staying Informed
Notifications of new cOS Core releases are sent out to the email address associated with MyClavister accounts. Email preferences can be adjusted by choosing the Settings option after logging into the relevant account at the following URL:The NetWall 6000 Series can be fitted with dual hot-swappable Power Supply Units (PSUs), both of which are capable of acting as a sole power supply for the appliance and which, together, provide redundancy against PSU failure. There is one type of PSU for AC power and another for DC power.
As standard, the NetWall 6000 Series is delivered with only a single PSU fitted and the second PSU slot is occupied by a dummy slot filler which suppresses the second slot's failure alarm. A second PSU must be ordered as a separate item if it is required. The NetWall 6000 Series is capable of operating with only one PSU fitted but that provides no redundancy.
A second PSU is fitted into the second PSU slot after taking out the dummy slot filler. Each PSU module is secured by a lock which is internal to the PSU and this is opened with a black sliding locking lever. There is also a silver metal hinged retaining bracket on each PSU which is used for preventing the power cable from pulling out accidentally.
With two PSUs installed, only one of the PSUs is active and supplying power. If the active PSU fails then the other PSU will become active with no disruption to traffic throughput. The failed PSU can then be replaced with a new PSU and this can be done while the NetWall 6000 Series is processing live traffic.
Symptoms of PSU Failure
If two PSUs are fitted to provide redundancy and there is a single PSU failure, an audible alarm will be heard coming from the appliance. This alarm can be switched off by pressing the red button located to the right of the PSUs. This is shown in the image shown below.In normal operation there is a green LED light that is illuminated on the back of each PSU. This LED will not be illuminated if power is available and its PSU has failed. The LED is shown illuminated in the image shown below.
Monitoring PSU Status with cOS Core Hardware Monitoring
The current PSU status and therefore failure can be detected by using the cOS Core Hardware Monitoring feature and this is fully described in the separate cOS Core Administration Guide. This feature can confirm for the administrator that a PSU has failed and which PSU it is.Steps for Swapping a PSU (AC Power)
To swap a PSU, use the following steps:If the metal retaining bracket is covering the PSU's power supply cord connector, push this upwards and fully back.
Remove the power supply cord from the PSU.
Push the PSU's locking lever to one side and pull the PSU out.
Insert the new PSU, making sure that it is fixed securely in place by the locking lever.
Reinsert the power cord into the new PSU and apply power. The green status LED on the PSU should illuminate and cOS Core hardware monitoring should also indicate the presence and positive status of the new PSU.
Move the PSU's hinged metal retaining bracket back so that it covers the cable connector to prevent it being accidentally pulled out.
Note: Having a spare PSU available on-site | |
---|---|
Having a spare PSU on-site and available will mean no delay if a replacement is required. These can be ordered from your Clavister sales representative. |
The NetWall 6000 Series has two expansion slots, each of which can accept an interface expansion module. There are a number different module options available and these are purchased separately to the NetWall 6000 Series unit. Each of the module types provides different connection capabilities and can be one of the following:
8 x RJ45 Gigabit Ethernet interfaces with PoE.
PoE installation is discussed further in Chapter 7, Power over Ethernet Setup.
4 x SFP+ 10 Gigabit interfaces with QAT.
The QAT feature will be automatically used by cOS Core for IPsec acceleration.
These optional modules are shown below:
The full connection capabilities of all the Ethernet interface types are listed in Appendix A, NetWall 6000 Series Specifications.
Adding an Expansion Module
A 6000 Series expansion module is added using a cold swap procedure. The steps are as follows:Check the Ethernet interface list in cOS Core through one of its management interfaces to make sure the module's interfaces have been correctly added. As explained in detail below, any new Ethernet interfaces will be automatically detected by cOS Core and will be added to the configuration with a logical name derived from the chassis slot number and interface position in the module.
The inserted module may be removed or swapped with a different expansion module by following the same procedure.
Ethernet Interface and Address Object Naming in cOS Core
After startup, cOS Core will detect the presence of the extra interfaces and add them to the configuration. No action from the administrator is needed for this to happen. The interfaces will be named according to the slot they are in (some hardware products have more than one slot) and their position on the expansion module.The assigned interface name will always have the following form: En-m. The name always begins with the letter E. The number n is the slot number and the number m is the position on the expansion module. For example, the second interface of an expansion module in the first slot will have the name E1-2.
For the NetWall 6000 Series, the slot numbers go from left to right when looking at the front of the device. In other words, slot number 1 is the left hand slot.
cOS Core will also automatically add an IP and network address object into the configuration's address book using the normal convention for interfaces. For example, the interface E1-2 will get an IPv4 address object called E1-2_ip and an IPv4 network object called E1-2_net.
Removing Interfaces
An expansion module can also be removed after powering off the NetWall 6000 Series. When cOS Core is then started again, the cOS Core configuration will be unchanged. However, no data can be received or sent on any Ethernet interfaces that do not physically exist. When details of such a missing interface are displayed (for example, with the show EthernetInterface CLI command), the EthernetDriver value will be shown as NullEthernetDriver.If another expansion module is then fitted later and it contains an Ethernet interface that has the same internal bus position as the removed one (in other words, it's logical cOS Core name is the same), traffic will be able to flow through that new interface since the configuration references will now have a corresponding physical interface.
Installing SFP/SFP+ Modules
NetWall 6000 Series expansion module options can provide connectivity for Small Form Pluggable (SFP) and Small Form Pluggable Plus (SFP+) modules. The NetWall 6000 Series does not come as standard with any SFP or SFP+ modules included but these can be ordered separately from a Clavister sales office.Note that only the SFP and SFP+ modules available from Clavister have been tested to function correctly with the 6000 Series hardware.
Clavister does not use a vendor lock so other, third-party SFP/SFP+ modules could be used but Clavister cannot accept responsibility for such modules functioning correctly when installed on Clavister hardware products.
Installation of the different types of SFP/SFP+ modules is performed in a similar way. The module slides into position by gently pressing it inwards, as illustrated below.
Caution: Insert SFP/SFP+ modules in the correct sockets | |
---|---|
An SFP module must not be inserted in an SFP+ socket. Similarly, SFP+ modules must not be inserted in an SFP socket. |
The full connection capabilities of all the NetWall 6000 Series Ethernet interfaces are listed at the end of Appendix A, NetWall 6000 Series Specifications.
One of the NetWall 6000 Series expansion slot options is a module that can provide 8 x RJ45 Gigabit Ethernet port connectivity with each port also capable of supplying Power over Ethernet (PoE) at the same time. Each PoE capable port can provide up to 30 Watts of DC power to an external device over a suitable Ethernet cable (Cat 5a or better) up to a distance of 100 meters. An uninstalled PoE-capable 6000 Series expansion module is shown below.
The above image shows a small LED at the center-bottom that will illuminate if the maximum PoE load is exceeded. The LEDs on the left and right sides will illuminate if the port indicated by the number next to the LED is actively supplying PoE power.
The expansion module comes with a separate PSU that provides the PoE power to the module by plugging into a special PoE power port on the back of the NetWall 6000 Series. This PSU is shown below.
Use the following steps when setting up PoE on the NetWall 6000 Series appliance:
Ensure the PoE enabled expansion module is correctly installed into the second expansion slot on the NetWall 6000 Series (located on the far right-hand side). Module installation is discussed generally in Chapter 6, Interface Expansion Modules.
Ensure that power is applied to the NetWall 6000 Series appliance and the module's interfaces appear in cOS Core's interface list. All interface ports on the expansion module will have the PoE feature enabled automatically and this does not need to be configured in cOS Core.
Connect up the PoE PSU by plugging its power cable into an external power socket and then connect the PSU's other cable to the PoE power inlet at the rear of the NetWall 6000 Series appliance. This is shown below.
Using a suitable Ethernet cable (Cat 5e or better), connect an external device to the first Ethernet interface port (top-left) on the expansion module. The maximum load drawn from a single interface port should never be more than 30 Watts.
Attach additional external devices in a similar way using sequential port numbers. Connections can be a mix of 15 Watts (802.3af) and the maximum of 30 Watts (802.3at Type 2).
The total loading across all Ethernet ports should never exceed 120 Watts and a maximum load distribution across the ports should ideally follow one of the patterns shown in the table below.
Port 1 | Port 2 | Port 3 | Port 4 | Port 5 | Port 6 | Port 7 | Port 8 |
---|---|---|---|---|---|---|---|
30W | 30W | 30W | 30W | 0 | 0 | 0 | 0 |
30W | 30W | 30W | 15W | 15W | 0 | 0 | 0 |
30W | 30W | 15W | 15W | 15W | 15W | 0 | 0 |
30W | 15W | 15W | 15W | 15W | 15W | 15W | 0 |
15W | 15W | 15W | 15W | 15W | 15W | 15W | 15W |
If the maximum loading is exceeded, the load warning LED on the module will light up. If this happens, remove PoE connections until the LED is no longer lit.
In some circumstances, it may be necessary to reset the NetWall 6000 Series appliance to the state it was in when it left the factory and before it was delivered to a customer. This process is known as a reset to factory defaults or simply a factory reset.
Caution: cOS Core upgrades and current configuration are lost | |
---|---|
Resetting to defaults means that the default cOS Core configuration will be restored as well as the original version of cOS Core that the product left the factory with. The will mean the following:
|
With the NetWall 6000 Series, a reset can be done in one of the following ways:
Using the Web Interface
A reset is possible through a web browser over a network connection using the cOS Core Web Interface (WebUI). The steps to do this are the following:
Open a web browser and enter the IP address of the management interface. The cOS Core web interface login dialog should be displayed. Connecting with a browser is described further in Section 3.4, Management Computer Connection.
Log into cOS Core as an administrator.
Go to: Status > Maintenance > Reset & Restart
Select the option: Reset the entire unit to factory defaults.
Press the Reset button.
Note that this will reset all the IP addresses on Ethernet interfaces to their defaults which might mean that the network connection will be lost.
Using the CLI
The cOS Core CLI can be used by connecting to one of the NetWall 6000 Series's Ethernet interfaces using an SSH client over a network. A reset is performed by entering the reset -unit command twice in succession:
Device:/>
reset -unitDevice:/>
reset -unit
Entering the command twice is a safeguard against accidental use. Note that this will reset all the IP addresses on Ethernet interfaces to their defaults which may mean that the SSH connection will be lost.
Using the Boot Menu
The boot menu can be accessed through the local CLI console by repeatedly pressing the Esc key while cOS Core is starting up. The resetting of Ethernet interface IP addresses will not affect the local console connection. The complete procedure is performed with the following steps:
Make sure a separate management computer running as a console is attached to the local console port of the NetWall 6000 Series.
Power up the NetWall 6000 Series unit. This may require a restart if the hardware is already powered up.
As console output appears, repeatedly press the Esc key before cOS Core has fully started.
The boot menu will now be displayed on the console.
Choose the Reset system to factory default option.
Boot menu options are described further in Section 4.5, The Boot Menu and in the separate cOS Core Administration Guide.
Performing a Reset Manually
The 6000 Series can be reset manually with the following steps:
The progress of the reset can be followed using a local console connection. If that is required, open a console display window connected to the NetWall 6000 Series local console port.
While the unit is powered up, push in the recessed reset button on the unit with a suitable pointed tip tool and keep it pushed in. A suitable paper-clip could be used to do this. The button can be found above the power LED.
Continue holding the button in for at least 10 seconds. The status LED will blink and when the blinking stops the reset is being performed.
If a console was connected in step 1, the console output will indicate that the hardware has successfully been reset to its factory defaults.
After completion of the reset, the NetWall 6000 Series unit can now be set up again as though it had never been previously configured.
Caution: Local console login credentials will be reset | |
---|---|
The local console login credentials will be reset to the default values of username admin and password admin. Changing the cOS Core admin user password as soon as possible is recommended. |
Limitation of Warranty
Clavister warrants to the customer of the 6000 Series Appliance that the Hardware components will be free from defects in material and workmanship under normal use for a period of two (2) years from the Start Date (as defined below). The warranty will only apply to failure of the product if Clavister is informed of the failure not later than two (2) years from the Start Date or thirty (30) days after that the failure was or ought to have been noticed by the customer.The warranty will not apply to products from which serial numbers have been removed or to defects resulting from unauthorized modification, operation or storage outside the environmental specifications for the product, in-transit damage, improper maintenance, defects resulting from use of third-party software, accessories, media, supplies, consumables or such items not designed for use with the product, or any other misuse. Any replacement Hardware will be warranted for the remainder of the original warranty period or thirty days, whichever is longer.
Note that the term "Start Date" means the earlier of the product registration date OR ninety (90) days following the day of shipment by Clavister.
Obtaining Warranty Service with an RMA
Warranty service can be obtained within the warranty period with the following steps:Obtain a Return Material Authorization (RMA) Number from Clavister. This number must be obtained before the product is sent back.
An RMA number can be obtained online by logging in to the Clavister website (http://www.clavister.com/login) and selecting the Help Desk option.
Note: The cold standby service uses a different procedure | |
---|---|
If the defective unit is subject to a Clavister Cold Standby (CSB) agreement then the procedure to follow is described in the relevant section of the separate NetWall Hardware Replacement Guide which is part of the cOS Core documentation set for each release. This guide also describes the steps for swapping any Clavister firewall with a replacement unit. |
The defective unit should be packaged securely in the original packaging or other suitable shipping packaging to ensure that it will not be damaged in transit.
The RMA number must be clearly marked on the outside of the package.
The package is then shipped to Clavister with all the costs of mailing/shipping/insurance paid by the customer. The address for shipping is:
Clavister AB
Sjögatan 6J
891 60 Örnsköldsvik
SWEDEN
If the product has not yet been registered with Clavister through its website, some proof of purchase (such as a copy of the dated purchase invoice) must be provided with the shipped product.
Important: An RMA Number must be obtained before shipping! | |
---|---|
Any package returned to Clavister without an RMA number will be rejected and shipped back at the customer's expense. Clavister reserves the right in such a case to levy a reasonable handling charge in addition to mailing and/or shipping costs. |
Note that the procedures for swapping any NetWall hardware model with an identical or different model type are described in the separate NetWall Hardware Replacement Guide.
Data on the Hardware
Note that Clavister is not responsible for any of the software, firmware, information, or memory data contained in, stored on, or integrated with any product returned to Clavister pursuant to a warranty claim.Contacting Clavister
Should there be a problem with the online form then Clavister support can be contacted by going to: https://www.clavister.com/support/.Customer Remedies
Clavister's entire liability according to this warranty shall be, at Clavister's option, either return of the price paid, or repair or replacement of the Hardware that does not meet Clavister's limited warranty and which is returned to Clavister with a copy of your receipt.Limitations of Liability
Refer to the legal statement at the beginning of the guide for a statement of liability limitations.Safety Precautions
Clavister NetWall 6000 Series devices are Safety Class I products and have protective ground terminals. There must be an uninterrupted safety earth ground from the main power source to the product’s input wiring terminals, power cord, or supplied power cord set. Whenever it is likely that the protection has been impaired, disconnect the power cord until the ground has been restored.For LAN cable grounding:
If your LAN covers an area served by more than one power distribution system, be sure their safety grounds are securely interconnected.
LAN cables may occasionally be subject to hazardous transient voltage (such as lightning or disturbances in the electrical utilities power grid). Handle exposed metal components of the network with caution.
There are no user-serviceable parts inside these products. Only service-trained personnel can perform any adjustment, maintenance or repair.
Säkerhetsföreskrifter
Dessa produkter är säkerhetsklassade enligt klass I och har anslutningar för skyddsjord. En obruten skyddsjord måste finnas från strömkällan till produktens nätkabelsanslutning eller nätkabel. Om det finns skäl att tro att skyddsjorden har blivit skadad, måste produkten stängas av och nätkabeln avlägnas till dess att skyddsjorden har återställts.För LAN-kablage gäller dessutom att:
Om LAN:et täcker ett område som betjänas av mer än ett strömförsörjningssystem måste deras respektive skyddsjord vara ihopkopplade.
LAN kablage kan vara föremål för farliga spänningstransienter (såsom blixtnedslag eller störningar i elnätet). Hantera metallkomponenter i förbindelse med nätverket med försiktighet.
Det finns inga delar i produkten som kan lagas av användaren. All service samt alla justeringar, underhåll eller reparationer får endast utföras av behörig personal.
Informations concernant la sécurité
Cet appareil est un produit de classe I et possède une borne de mise à la terre. La source d’alimentation principale doit être munie d’une prise de terre de sécurité installée aux bornes du câblage d’entree, sur le cordon d’alimentation ou le cordon de raccordement fourni avec le produit. Lorsque cette protection semble avoir été endommagée, débrancher le cordon d’alimentation jusqu’à ce que la mise à la terre ait été réparée.Mise à la terre du câble de réseau local:
Si votre réseau local s’étend sur une zone desservie par plus d’un système de distribution de puissance, assurez-vous que les prises de terre de sécurité soint convenablement interconnectées.
Les câbles de réseaux locaux peuvent occasionnellement être soumis à des surtensions transitoires dangereuses (telles que la foudre ou des perturbations dans le réseau d’alimentation public). Manipulez les composants métalliques du réseau avec précautions.
Aucune pièce contenue à l’intérieur de ce produit ne peut être réparée par l’utilisateur. Tout dépannage, réglage, entretien ou réparation devra être confié exclusivement à un personnel qualifié.
Hinweise zur Sicherheit
Dies ist ein Gerät der Sicherheitsklasse I und verfügt über einen schützenden Erdungsterminal. Der Betrieb des Geräts erfordert eine ununterbrochene Sicherheitserdung von der Hauptstromquelle zu den Geräteingabeterminals, den Netzkabeln oder dem mit Strom belieferten Netzkabelsatz voraus. Sobald Grund zur Annahme besteht, dass der Schutz beeinträchtigt worden ist, das Netzkabel aus der Wandsteckdose herausziehen, bis die Erdung wiederhergestellt ist.Für LAN-Kabelerdung:
Wenn Ihr LAN ein Gebiet umfasst, das von mehr als einem Stromverteilungssystem beliefert wird, müssen Sie sich vergewissern, dass die Sicherheitserdungen fest untereinander verbunden sind.
LAN-Kabel können gelegentlich gefährlichen Übergangsspannungen ausgesetz werden (beispielsweise durch Blitz oder Störungen in dem Starkstromnetz des Elektrizitätswerks). Bei der Handhabung exponierter Metallbestandteile des Netzwerkes Vorsicht walten lassen.
Dieses Gerät enthält innen keine durch den Benutzer zu wartenden Teile. Wartungs-, Anpassungs-, Instandhaltungs- oder Reparaturarbeiten dürfen nur von geschultem Bedieningspersonal durchgeführt werden.
Considerazioni sulla sicurezza
Questo prodotte è omologato nella classe di sicurezza I ed ha un terminale protettivo di collegamento a terra. Dev’essere installato un collegamento a terra di sicurezza, non interrompibile che vada dalla fonte d’alimentazione principale ai terminali d’entrata, al cavo d’alimentazione oppure al set cavo d’alimentazione fornito con il prodotto. Ogniqualvolta vi sia probabilità di danneggiamento della protezione, disinserite il cavo d’alimentazione fino a quando il collegaento a terra non sia stato ripristinato.Per la messa a terra dei cavi LAN:
Se la vostra LAN copre un’area servita da più di un sistema di distribuzione elettrica, accertatevi che i collegamenti a terra di sicurezza siano ben collegati fra loro;
I cavi LAN possono occasionalmente andare soggetti a pericolose tensioni transitorie (ad esempio, provocate da lampi o disturbi nella griglia d’alimentazione della società elettrica); siate cauti nel toccare parti esposte in metallo della rete.
Nessun componente di questo prodotto può essere riparato dall’utente. Qualsiasi lavoro di riparazione, messa a punto, manutenzione o assistenza va effettuato esclusivamente da personale specializzato.
Consideraciones sobre seguridad
Este aparato se enmarca dentro de la clase I de seguridad y se encuentra protegido por una borna de puesta a tierra. Es preciso que exista una puesta a tierra continua desde la toma de alimentacíon eléctrica hasta las bornas de los cables de entrada del aparato, el cable de alimentación hasta haberse subsanado el problema.Puesta a tierra del cable de la red local (LAN):
Si la LAN abarca un área cuyo suministro eléctrico proviene de más de una red de distribución de electricidad, cerciorarse de que las puestas a tierra estén conectadas entre sí de modo seguro.
Es posible que los cables de la LAN se vean sometidos de vez en cuando a voltajes momentáneos que entrañen peligro (rayos o alteraciones en la red de energía eléctrica). Manejar con precaución los componentes de metal de la LAN que estén al descubierto.
Este aparato no contiene pieza alguna susceptible de reparación por parte del usuario. Todas las reparaciones, ajustes o servicio de mantenimiento debe realizarlos solamente el técnico.
Dimensions, Weight and MTBF
Height x Width x Depth (mm) | 44 x 438 x 508 |
Hardware Unit Weight | 7.5 kg (no expansion modules, single PSU) |
Hardware Form Factor | 1U |
19-inch Rack Mountable | Yes, using rack mount kit |
MTBF | 165,648 hours @ 20° C |
Regulatory and Safety Standards
Safety | UL, CB, TUV |
EMC | FCC, CE, VCCI |
Environmental
Operating and Storage Humidity | 0% to 95% (non-condensing) |
Operating Temperature | 0 to 40° C |
Power Specifications
Redundant Hot-Swappable Power Supply (AC) | 100-240 VAC, 50-60 Hz |
PSU Rated Power (AC Input) | 300W (100VAC/≤5A - 240VAC/≤2.5A) |
PSU Rated Power (DC) | 300W (-36VDC/≤11A - -72VDC/≤6A) |
Maximum Power Consumption | 140.3W |
Typical Current | 0.48A @AC input (0.6A at load) |
BTU | 460 BTU (at load) |
PoE to external devices | 802.3at and 802.3af from expansion module |
PoE supply source | External power adapter |
Ethernet Interface Support
Gigabit RJ45 interfaces |
Automatic MDI-X 1000BASE-T (copper RJ45 100m) 100BASE-TX (copper RJ45 100m) 10BASE-T (copper RJ45 100m) |
SFP interfaces (if expansion module installed) | 1000BASE-SX (multi-mode 550m) 1000BASE-LX (single-mode 10,40,80km) 1000BASE-T (copper RJ45 100m) |
SFP+ interfaces (including any expansion module) |
10GBASE-SR (multi-mode 300m) 10GBASE-LR (single-mode 10km) 10GBASE-ER (single-mode 40km) 10GBASE-ZR (single-mode 80km) 10GBASE-CR (direct attach) Note that only Clavister supplied SFP+ modules have been tested to function correctly with the 6000 Series. |
For more information about Clavister products, go to: https://www.clavister.com
If a computer running Microsft Windows™ is being used as the cOS Core management computer and a DHCP server is not enabled on the cOS Core management interface, the management computer's Ethernet interface connected to the Clavister Next Generation Firewall should be configured with an IPv4 address which belongs to the network 192.168.1.0/24. That address must be different from the firewall's default management interface address of 192.168.1.1.
it is assumed that the IPv4 address 192.168.1.30 will be used for this purpose and the steps to set this up with Windows versions 8, 8.1 or 10 are as follows:
Select Network & Internet from the control panel.
Then, select the Network & Sharing Center option.
Now, select the Change adapter settings option.
A list of adapters will appear and will include the Ethernet interfaces. Select the interface that will connect to the firewall.
The properties for the selected interface will appear.
Select and display the properties for Internet Protocol Version 4 (TCP/IPv4).
DNS addresses can be entered later once Internet access is established.
An Apple Mac can be used as the management computer for initial setup of a Clavister Next Generation Firewall. To do this, a selected Ethernet interface on the Mac must be configured correctly with a static IP. The setup steps for this with Mac OS X are:
Click on Network.
Select Manually in the Configure pull down menu.