Skip to content

System Administration Guide

Introduction

About this Document

This document serves as a reference source for technical personnel and system administrators who are responsible for licensing and configuring AXS Guard appliances. Explanations of various concepts, e.g. AXS Guard users and groups, are provided together with instructions on how to configure their relevant settings.

Topics covered in this document:

  • How to access the AXS Guard web-based administrator tool
  • How to configure your appliance using the various configuration wizards
  • Creating a user with administrative privileges
  • Licensing your appliance
  • Quick navigation reference
  • How to use the AXS Guard system menu
  • Activating software options
  • System backup and restore
  • Software updates
  • Server-Side SSL and TLS options
  • Security levels and policies
  • User and group management
  • Computer management
  • Network configuration (Network devices, VLANs, DNS, DHCP, Routing, NAT, etc.)
  • NTP
  • System health & status
  • Reporting & GDPR
  • System logging
  • Remote syslog management & the Sumo Logic Collector
  • Introduction to authentication settings

Examples used in this Guide

All setups and configuration examples in this guide are executed as an advanced administrator. Some options are not available if you log in as a full administrator or a user with lower access privileges.

As software development and documentation are ongoing processes, the screenshots shown in this guide may slightly deviate from the current user interface.

Accessing the Administrator Tool

Overview

The administrator tool is a web-based interface to configure your AXS Guard appliance. Once the appliance is connected to your network, you can access the administrator tool with a standard web browser from any workstation in its network. Connections are secured (HTTPS) and require you to accept the AXS Guard self-signed certificate.

For instructions on how to connect the AXS Guard to your network, please refer to the Installation Guide, supplied with the AXS Guard. Instructions on accessing the Administrator Tool are explained in this section.

System Default IP Address

The address for accessing the Administrator Tool depends on whether the AXS Guard appliance is configured as the browser’s proxy server.

Used as a Proxy Server? Address to navigate to:
Not used as a Proxy Server https://IP address:82, e.g. https://192.168.250.254:82 (AXS Guard system default LAN IP address)
Used as a Proxy Server Enter the secure LAN IP address of your AXS Guard as the browser’s proxy and 3128 as the port number. In the browser’s URL field, enter tool.

Important

Proxy settings

  • If the connection fails, check your browser’s proxy settings. Remove any previous settings and try again.

  • If Single Sign-On (SSO) is used, the browser’s proxy settings are set automatically. For more information, please refer to the document, AXS Guard Single Sign-On How To, available through the permanently on-screen Documentation button in the Administrator Tool.

  • For more information on using the AXS Guard Proxy server, please refer to the document, AXS Guard Web Access How To, available through the permanently onscreen Documentation button in the Administrator Tool.

image

Logging in to the Administrator Tool

Supported Browsers

Browser Version
Chrome Current versions only
Edge Current versions (Windows 8, 8.1 & 10)
Firefox Current versions only
Safari Current versions only
Opera Current versions only

Login Procedure

As of version 7.7.0, the AXS Guard uses the SHA-256 algorithm to sign digital certificates. SHA-256 is only supported by Windows XP SP3 and later versions. Logging in to the web-based administrator tool will no longer be possible with older versions of Windows.

To log in to the AXS Guard web-based administrator tool, you need a web browser (see the list of supported browsers). The web-based administrator tool listens on port 82. If you can’t access the login page, verify your browser’s proxy settings.

Access is secured by SSL encryption over the HTTP protocol. The AXS Guard is secured with a self-signed certificate, which means the browser will show a warning asking you to accept the certificate (also see the image below). The procedure for accepting self-signed certificates varies between browsers. After accepting the certificate, the login screen will appear.

  1. Start your favorite Internet browser.

  2. Enter the default URL for the Administrator Tool, i.e. https://192.168.250.254:82

  3. Accept the self-signed certificate before you continue. After the certificate has been accepted, the AXS Guard login screen will appear.

    image

    Important

    • Include the port number after the IP address or the connection will fail.
    • If the AXS Guard is configured as the browser’s proxy, your may enter tool as the URL instead of the appliance’s default IP address and port number.
  4. Enter the default system administrator’s username (sysadmin) and password (sysadmin).

  5. Press enter or click on the log in button to proceed.

    image

  6. Complete the first wizard to create a user with full or advanced administrative privileges. This is required to license and further configure your appliance.

    image

    Important

    Changing the factory default sysadmin password is critical for security. It should be changed ASAP to prevent non-authorized users from accessing the AXS Guard administrator tool.

sysadmin Access Rights

The sysadmin allows you to:

  • Create and modify new AXS Guard users.

  • Assign rights to the new AXS Guard users.

  • Change the sysadmin password.

To license your appliance and configure other features, you must log in as an advanced administrator.

Configuration Wizards

Overview

The configuration wizards walk you through the essential configuration steps to get your system up and running in no time. Each wizard must be completed before the next one becomes available. In this section, we explain the following wizards:

  • Setup wizard: Includes creating a new administrator, configuring initial system settings and network devices.

  • Licensing wizard: During this stage, you will be invited to enter your customer information and upload your system license to get your appliance to full operational, in-service status.

  • Group and user wizard: Allows you to easily create new users and groups and also to synchronize users and groups from your Directory Server (if applicable).

Click on the Help button if you need assistance.

image

Starting the Wizards

  1. Log in to the AXS Guard.

  2. If you are logging in for the first time, the wizards will start automatically. Otherwise, click on Wizards.

  3. Follow the on-screen instructions.

    Important

    Do not skip any wizards. Start from the top one and work your way down the list.

Basic System Configuration

Creating a new System Administrator

Follow the on-screen instructions to create a new system administrator with full or advanced privileges (required to license your appliance). Fields with descriptions in bold are required, other fields are optional. Click on help for assistance.

image

System Setup

Follow the on-screen instructions to set up your system.

Change the default sysadmin password to prevent unauthorized access to the appliance. Use a secure, complex password.

Basic System Configuration

Setting up your Network Devices

Follow the on-screen instructions to set up your network devices.

Network Device Configuration

License Wizard

Customer Information

Follow the on-screen instructions to enter your customer information.

Entering your Customer Information

Licensing your Appliance

Follow the on-screen instructions to license your appliance.

License Wizard

Microsoft Cloud

The Office 365 FAST Lane wizard will help you to securely connect your network with the Microsoft Office 365 cloud and configure the optimal bandwidth settings for your Office 365 applications and services. An Internet speed test will be executed to calculate the optimal bandwidth settings. Please note that users will be temporarily disconnected from the Internet for the duration of the speed test. Their connection will be restored after completion of the test.

Office 365 FAST Lane Wizard

Groups and Users

Creating Users

Follow the on-screen instructions to create new users.

Creating new Users

Creating Groups

Follow the on-screen instructions to create new groups.

Creating new Groups

Synchronizing your Directory Server

Follow the on-screen instructions to import and synchronize the users and groups from your Directory Server (LDAP sync).

Directory Server Synchronization

Creating a User with Administrative Privileges

Change the factory default sysadmin password to prevent unauthorized access to the appliance.

With the sysadmin user, you can create new user accounts, including accounts with administrative privileges. However, it won’t allow you to configure and manage your appliance. To further configure and manage your appliance, you must create a new user with full or advanced administrative privileges. This also facilitates troubleshooting and monitoring, since all actions performed by administrators are logged by username (under System > Logs > Admin Tool).

  1. Log in to the AXS Guard.

  2. Navigate to Users & Groups > Users.

  3. Click on the + sign to add a new user.

    Creating a System Administrator User

  4. Enter a username.

  5. Enter the user’s full name (optional).

  6. Enter and confirm the user’s password. Make sure to use a secure, complex password.

  7. Under the AXS Guard Administration tab, select Full Administration.

  8. Click on Update / Save.

  9. Log off and log in with the newly created administrator account. Use this account to further configure your appliance.

Licensing your Appliance

Overview

Licensing is the process of identifying an issued AXS Guard to Able for the issue of a License file to make the appliance fully operational. After installation, and before licensing, the Administrator Tool is accessible for configuration and management, but no services, such as authentication, are available.

The licensing process requires registering information on the Able Product Registration website. This information identifies the appliance to Able for the issue of a License file. Two types of licenses are possible:

  • a commercial license, which supports full functionality permanently.

  • an evaluation license, which supports full functionality for 30 days only.

First time licensing, viewing license information and re-licensing are described here.

First time licensing

Overview

Licensing your AXS Guard to make all features operational requires three steps:

  1. Downloading a System Info file from your AXS Guard. This file contains information specific to the AXS Guard, including the:

    • Host Key, which is specific to the appliance

    • Configuration Key, which is specific to the configuration and may therefore change for an appliance, when:

  2. Acquiring a License file from Able’s Product Registration website, using the:

    • System Info file

    • Maintenance Reference (for a commercial license only)

    • Serial Number (for a commercial license only)

    • details of your organization

  3. Uploading the License file to the AXS Guard.

After Licensing, configuration by the sysadmin user in the Administrator Tool is restricted to creating and modifying users. To access and configure all AXS Guard features, therefore, requires creating a new user with full administrative rights.

Downloading a System Info file

System Info File

  1. Log in to the AXS Guard as explained in Accessing the Administrator Tool .

  2. Navigate to System > Status > System Info.

  3. Click on the Export button (see image below).

  4. Download and save the systeminfo.txt file. You will need this file to acquire a license file from the Able Product Registration website.

    Downloading the System Info file

Acquiring a License file

To acquire a license file for your AXS Guard appliance, you need to upload the systeminfo.txt file on the product registration site and follow the on-screen instructions. The systeminfo.txt file allows us to identify your appliance before issuing a license file.

There are two types of licenses:

  • A commercial license, which remains valid indefinitely.

  • An evaluation license which is free. It allows you to test and evaluate the appliance for a period of 30 days.

Uploading your License File

  1. Log in to the AXS Guard.

  2. Navigate to System > Licence > Import.

  3. Click on "browse" to locate the license.dat file.

  4. Click on "Update" to upload the license.dat file.

    Uploading the License file in the Administrator Tool

    Important

    After licensing your appliance, the factory default sysadmin user will be restricted to the creation and modification of user accounts. Create a new account with full or advanced administrative privileges to further configure your appliance.

Viewing License information

After licensing, four new screens become available under the License menu:

  • General: this screen lists generic license information, retrieved by the AXS Guard from the License .dat file (see image below).

License > General

  • Maintenance: this screen provides information about the type of contract purchased (see image below).

License > Maintenance

When your contract is about to expire, a status message is shown on this screen.

  • Content Scanning: this screen provides information about optional software options related to content scanning (see image below).

License > Content Scanning

  • DIGIPASS: this screen provides information about purchased DIGIPASS devices to be used with the AXS Guard (see image below).

License > DIGIPASS

Re-licensing

Overview

Re-licensing is necessary under the following circumstances:

  • after restoring an AXS Guard to factory default without restoring a back-up.

  • after restoring a back-up from another AXS Guard (e.g. for a Spare Unit.

  • when upgrading from an Evaluation to a Commercial License.

Important

  • Buying new software options or changing the contract does not require relicensing. The AXS Guard automatically contacts the Able back-office to retrieve the new license information. New options need to be activated.
  • A status message with a confirmation link is automatically generated for canceled software options or maintenance contracts. Canceled options for which the cancellation remains unconfirmed are terminated after a 30 day grace period.

Factory default without restoring a back-up

Restoring an appliance to Factory Default state cleans the system and changes the Configuration Key. In this case the running License is bound to the previous Configuration Key, so that re-licensing is not allowed. The System Administrator needs to contact Able support (support@axsguard.com) for release of the License, thus allowing re-licensing. Re-licensing then requires the same procedure as for first-time licensing.

Restoring a back-up from another appliance

Restoring a backup created by the same appliance does not require re-licensing, as the Host Key and Configuration Key remain the same as those supplied in the original System Info file for License issue.

Restoring a backup created by a different appliance, (for example restoring to a Spare Unit), requires relicensing, as the Host Key is different to that supplied in the original System Info file for License issue. After the back-up is restored, there is a Grace Period of 30 days, during which time all services remain available; after this period, all services stop, although the Administrator Tool remains accessible for minimal configuration and management. The grace period allows System Administrators time to contact Able support (support@axsguard.com) for release of the appliance from its initial license, and to re-license the appliance. Re-licensing then requires the same procedure as for first-time licensing.

Upgrading from an Evaluation to a Commercial License

With an Evaluation License, a grace period of 30 days is imposed, during which time all services remain available; after this period, all services stop, although the Administrator Tool remains accessible for minimal configuration and management. System Administrators therefore need to re-license with a Commercial License before the Evaluation License expires.

It is not necessary to contact Able support to upgrade from an Evaluation to a Commercial license.

Re-licensing requires the same procedure as for first-time licensing.

Quick Navigation Reference

Overview

The Administrator Tool interface has three panes (numbered in the image below): the top pane is static; the left pane allows you to access the menus of the features that are enabled on your appliance. The right pane displays the configuration settings of the selected menu for viewing and modifying. The functionality offered in each pane is explained in the following sections. A search function is available for quick and easy access to menu items.

image

System Information and Permanently On-Screen Buttons

The system information (version number, revision number, etc.) is permanently visible in the left pane. The standard Dashboard, Wizards, Documentation and the Logout button are located in the top pane. The functionality provided by these buttons is described in the table below.

Permanently On-Screen Buttons and System Version

Info / Button Description
Version / Revision (left pane) AXS Guard version and revision numbers (important for troubleshooting and support).
Dashboard Shows vital information about your system’s health, e.g. configuration warnings, the system load, the uptime, etc.
Wizards Provides access to the various configuration wizards.
Documentation Provides access to all available documentation (HTML and PDF format).
System Time Shows the AXS Guard system time, which is important for time-sensitive processes such as DIGIPASS authentication.
Administrator Name and Level The username and the corresponding access level of the person who is logged in to the administrator tool.
Logout Logs the user out of the AXS Guard.

The AXS Guard administrator tool has a treelike menu structure. Selecting a menu or submenu item will show the corresponding configuration in the right pane.

Some menu items, such as Computers, don’t have submenus. Feature-specific submenu items are explained separately in the AXS Guard documentation.

image

Main Menu Item Description
System This menu displays several system-critical tools, system settings and system logs. Examples are: the AXS Guard Feature Activation tool, the AXS Guard DNS name, Domain name, System Update Settings, System Backup and Restore functions, and System Status, etc.
Users and Groups This menu displays AXS Guard user and group settings for viewing or modification, e.g. Web access rights, firewall rights, etc.
Computers This menu displays computer-specific settings for viewing or modification, e.g. firewall rights assigned to a specific server in the network.
Authentication This menu displays authentication-related settings for viewing or modification. All available authentication methods, such as two-factor authentication (DIGIPASS), RADIUS authentication and other authentication methods are configured through this menu.
Feature-related Feature-specific sub menus are available if the features have been activated. Examples are: advanced mail filtering, VPN solutions, HTTP Proxy and Reverse Proxy, Intrusion Prevention (IPS), Firewall, Directory Services, Bandwidth Management (QoS), Advanced Monitoring and Reporting, etc.
Add-ons This menu supports installation of add-on programs, such as the AXS Guard Single Sign-On Tool (for more information, please refer to the document AXS Guard Single Sign-On How To available through the permanently on-screen Documentation button).
Sub Menu Item Description
General Main configuration settings for a feature can be viewed or modified in the General sub menu. Special syntax may be required for some features, e.g. the Directory Services feature requires LDAP syntax. Feature-specific settings and syntax are explained in the respective AXS Guard How To guides, available through the permanently on-screen Documentation button.
Status This sub menu displays the feature-specific status information (see note below). This is useful if a problem occurs, for example a synchronization error with a Directory Server. The format of the status information is also feature-specific, and is explained in the respective AXS Guard How To guides, available through the permanently on-screen Documentation button.
Tools Tools may be feature-specific or system-specific. The Tools sub menu allows new setups to be tested, and the system to be shut down for maintenance, etc.
Logs Logs are records of system or feature-specific events, which help administrators to track and solve problems. Filters support searching for specific records within a given log file.

Tables and Configuration Screens

When clicking on a menu or submenu, the corresponding configuration screen is shown in the right pane. Information or settings are presented in one of two ways:

  • Table form: tables provide an overview of settings for a particular type of object, e.g. groups, users, or uploaded DIGIPASS tokens.

  • Configuration screens: configuration screens show the settings of a particular feature for viewing or modification.

Settings can only be added or modified if an administrator is logged in with the appropriate rights.

Table View

Clicking on Users & Groups > Users displays the corresponding table in the right pane.

image

Deleted objects (e.g. a user, a configuration setting, etc.) cannot be recovered. For example, deleting a user irrevocably deletes the user’s mailbox and settings!

Two groups of controls are displayed on screen above the table: the search filter (explained below) and buttons for various operations: Items per page, Template, Add New, Delete, Export and Refresh. Hovering over a button will show its corresponding function.

Tool Buttons

Button Functionality
Add New Adds a new (sub)menu-specific object, e.g. a user, a group, a client, a firewall rule, etc.
Delete Deletes a (sub)menu-specific object, e.g. a user, a group, a client, a firewall policy, etc. Deleting an object with references is not allowed and generates a warning message.
Export Exports the configuration data (e.g. User records) to a CSV file (Comma Separated Values).
Refresh Refreshes the screen with the most current information. This is useful for checking that recent modifications have been applied (e.g. when synchronizing users and groups with a Directory Server).
Column Toggle Inverts the selections in a column of records.
Row Toggle (top) Enables/disables the record in a selected row.
Items per Page This drop-down menu allows you to select the number of objects (e.g. users, groups, log files etc.) to be displayed on screen.

If you try to delete an object that is in use by another object, for example a group that still has members, an activation error will be shown (to preserve referential integrity).

image

Search Filters

Certain tables or files may contain a large numbers of records or entries, e.g. the full event logs. Search filters help administrators to restrict viewing specifically to relevant records and entries.

Table Search Filters

Search strings are case-sensitive by default. Press Aa to change the default behavior.

Configuration Screens

Click on an object in a table, e.g. a username, to show its corresponding configuration. Multiple settings may be grouped and accessible through separate tabs (as shown in the image below). Whether a tab is visible or not depends on the features that are activated on your appliance.

Selectable Tabs

Configuration Settings

Some settings can be selected from drop-down lists, while some need to be entered manually in data fields using dedicated syntax. Some simply require a checkbox to be selected (examples are shown in the image below).

Required fields have a description in bold.

Example Screen with Drop Down Menu, Checkbox and Entry Field Configuration Methods

Configuration Screen Buttons

The various buttons are explained in the table below .

Hovering over a button will show its corresponding function.

Buttons for Modifying or Creating a New Records.

Button Functionality
Add New Adds a new (sub)menu-specific object, e.g. a user, a group, a client, a firewall rule, etc.
Cancel Prevents new or modified settings from being stored and cancels the current operation, returning to the previous screen.
Delete Deletes a (sub)menu-specific object, e.g. a user, a group, a client, a firewall policy, etc. Deleting an object with references is not allowed and generates a warning message.
Edit as New Creates a copy of the selected record, keeping the same configuration options (for easy editing of a new record).
Save Stores any new objects, e.g. a new firewall rule. The save button is only available where saving is required, otherwise the update button is shown.
Update Submits any modifications to existing AXS Guard settings. Modifications are lost if not updated.
Print Prints the current screen. Useful for printing logs and statistics.
Help Displays help for the current screen.

Manual System Configuration

Overview

This section covers the AXS Guard’s System menu, explaining configuration in detail for the following sub menus:

  • General

  • Customer

  • Feature Activation

  • UPS

  • Administrator Tool

  • Tools

  • Returning to Factory Default settings

General Menu

The Domain Name set on the System > General screen is not necessarily the Windows Domain Name. Please see the table below for more information.

Navigate to System > General. A screen similar to the image below is displayed. Fields and their settings are explained in the table below .

System > General Screen

Field Description
Host name The hostname of the appliance. This name is used by the appliance’s own internal DNS server. axsguard is the system default. Do not change unless necessary. Changing the hostname requires advanced administrator access.
Domain Name The name of your primary domain, e.g. example.com. This domain is used by the appliance’s internal DNS server and is also used when it sends an e-mail notification to system administrators or the outside world.
Domain for outgoing emails Enter a domain with a valid MX record. This is only required if the domain name specified above is a local domain which is not resolvable on the Internet, e.g. example.local.
Time Zone Select the appropriate time zone from the drop-down list. A correct system time is critical for time-sensitive processes such as Kerberos and DIGIPASS authentication.
System Administrator Email address Enter the system administrator’s e-mail address. All reports generated by your appliance are sent to this e-mail address. Multiple e-mail addresses can be specified.
System Administrator Password The factory default sysadmin password. It is highly recommended to change this password as soon as you install your appliance.
Country Select the appropriate country from the drop-down list.
Send warning if load is consistently high The appliance will automatically send an e-mail to system administrators if it detects a high system load during 5 consecutive days. The e-mail is sent to the e-mail address(es) specified under System > General. A high load average may be an indication of a task monopolizing a lot of CPU time, in which case you may want to upgrade your hardware.

Customer Information and Product Notifications

This screen is used to enter customer information, which is uploaded to the Able customer database in order to keep system administrators informed about new system features, product updates and to facilitate customer support and remote assistance.

Keeping this information up-to-date optimizes and facilitates Able customer support.

Navigate to System > Customer. A screen similar to the image below is displayed.

System > Customer

You can subscribe to notifications covering important security topics and information about your appliance. The notifications are sent to the e-mail address you specify. Select the topics you want to be informed about.

Selecting mail types to receive from Able

Feature Activation Menu

Additional software options can be purchased and enabled as required. The procedure to activate new software options is explained below.

Disabling unused features and options improves system performance.

  1. Navigate to System > Feature Activation

  2. In the right pane, expand the sub menu for the feature you wish to enable

  3. Check or uncheck the boxes to activate or deactivate features respectively (see the image below)

  4. Click on Update

After activating a feature, the configuration menu becomes available in the left pane.

System > Customer

UPS Settings

UPS

A UPS (uninterruptible power supply) is a device which allows a server to operate when its primary power source is lost. It also provides protection against power surges. The AXS Guard supports the following UPS makes and models:

  • APC Smart-UPS

  • Back-UPS Pro.

The UPS unit is connected via a serial cable and uses a PSTN device (serial link) for communication with the AXS Guard. In case of a power failure, the UPS unit will signal the AXS Guard when its battery is about to be depleted. This ensures a proper shutdown and prevents data loss or corruption.

Check whether the UPS feature is activated (System > Feature Activation).

To configure the settings of the connected UPS:

  1. Navigate to System > UPS

  2. Enter the requested data

  3. Click on Update to finish

System > UPS

Field Description
UPS Type Select your UPS make and model.
UPS Cable Type Select the cable type from the drop-down menu.
PSTN Device The PSTN device as configured under Network > Devices > PSTN

Administrator Tool Configuration

General settings for the Administrator Tool are configured on the System > Administrator Tool screen.

  1. Go to System > Administrator Tool.

  2. Modify the settings as required. Fields are explained in the table below .

  3. Click on Update to finish.

System > Administrator Tool

Field Description
Administrator Tool Time-Out Enter the time in minutes for the period of inactivity after which the AXS Guard Administrator Tool is automatically disconnected. The system default is 15 minutes. This is an extra security precaution in case an administrator forgets to log off. Setting the value to 0 disables the time-out.
Name to go to the AXS Guard Administrator Tool The name specified in this field automatically resolves to the AXS Guard Administrator Tool if the AXS Guard is configured as your browser’s proxy server. The system default is tool. This name is added to the AXS Guard’s internal DNS repository.
Name to go to the AXS Guard DIGIPASS for e-ID registration page This is the name of the page users can go to in order to register their DIGIPASS for eID reader. For example, if you enter registration, users will be able to self-register on https://axsguard:82/registration. See the AXS Guard Authentication How To for more information.
Certificate The certificate that is used to identify your appliance. Go to PKI > Certificates to configure the AXS Guard CA and create certificates. See the PKI How To for more information.

Tools Menu

Overview

Four system tools are grouped under the Tools menu:

  • Actions

  • Backup

  • Restore

  • Automatic Reboot

Actions

Navigate to System > Tools > Actions. A screen similar to the image below appears. Actions are described in the table below.

Tool Actions

Button Description
Reboot Click to reboot the AXS Guard appliance.
Shut Down Click to shut down the AXS Guard appliance. Never disconnect the power supply (power cord) while the AXS Guard is booting up or active, as this may cause system or hardware damage. Always shut down the AXS Guard with this button.
Rebuild (Empty) Proxy Cache This option is only available if the Content Scanning Feature (proxy server) is enabled. The proxy cache must be rebuilt only if the cache size has been reduced or if the cache has been corrupted due to an incorrect shutdown, e.g. a power failure.

Automatic Reboot

Navigate to System > Tools > Automatic Reboot.

Tool Actions

The fields on the Modify Automatic Reboot screen are self-explanatory.

Automatic reboot can be enabled or disabled, the day, time and frequency for automatic reboot can be specified and the date and time of the next reboot is indicated.

Reboots are useful to check the AXS Guard hard drive(s) for integrity. Generally, this occurs automatically at boot time.

If the system detects that a file system is inconsistent, indicating failure to shut down properly, such as a crash or power failure. The system hard drives are additionally checked for consistency by default every 33 reboots or every 6 months.

Factory Default Settings

Important

  • Restoring an appliance to factory default removes the License and changes the Configuration Key.
  • Back up all your configuration and user data before restoring the AXS Guard to its factory default settings.
  • Manually restoring an AXS Guard to its factory default settings is not necessary before restoring a back-up; the appliance will be restored to factory default automatically before the back-up is restored.

You can reset AXS Guard to its factory default settings via the AXS Guard console tool. The console tool is a text-based command line interface (CLI) to edit and display critical AXS Guard settings and variables via menus. It also allows commands to be executed for advanced troubleshooting, such as network traffic analysis.

Details about using the console tool and resetting the AXS Guard to its factory default settings are available in the AXS Guard Conmmand Line Interface How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool.

Activating New Software Options

Additional software options can be purchased and enabled as required. The procedure to activate new software options is explained below.

System administrator(s) are automatically notified by e-mail when new software options are available. The software options need to be activated by a system administrator, which we explain in this section. Once activated, features can be enabled or disabled as required under System > Feature Activation.

  1. Log in to the AXS Guard as a full or advanced administrator. A message on the Dashboard will indicate that there are unactivated software options.

  2. Click on the here link to activate the software options and follow the on-screen instructions.

    Activating New Software Options

    Info

    Disabling unused features and options improves system performance.

Backup and Restore

Overview

Backup and Restore functionalities allow the AXS Guard’s configuration to be saved, and recovered later if necessary. It also allows you to restore a backup to a Spare Unit, in case of a hardware failure.

The Backup and Restore screens are accessible through the System > Tools sub menu. Available options on these screens are explained in the following sections .

Backing up your Configuration

Navigate to System > Tools > Backup to display the Modify Backup screen with tabs for:

  • Backup Download

  • Weekly Backup

  • Daily Backup on Network Share

These and a fourth backup option, backup on Able Servers, are describe in the following sections.

Backup Download

This type of backup does not back up e-mails, log files or any other user data. Use the Daily Backup on Network Share option to back up this data.

Backup Download allows you to save the current AXS Guard configuration settings. The backup file(s) created can later be restored to the AXS Guard if a configuration error occurs. Configuration settings are saved in a compressed .tgz file.

  1. Navigate to System > Tools > Backup & Restore > Backup.

  2. Click on Save as.

  3. Browse to select the location for storing the backup.

    Backup Download

Weekly Backup by Email

Weekly Backup by email cannot be used to back up e-mails, log files or any other user data. Only your AXS Guard configuration data is backed up. Use Daily Backup on Network Share to create full system backups.

Via Weekly Backup by email system administrators can specify one or more email addresses to send a backup to.

  1. Navigate to System > Tools > Backup & Restore > Backup.

  2. Click on the Weekly Backup by email tab.

  3. Configure the settings as required. Fields are explained in the table below .

  4. Click on Update.

    Weekly Backup by Mail

Field

Description

Send backup to

Specify one or multiple e-mail addresses.

Reporting Frequency

Two options are available:

  • Test e-mail: Allows you to test your backup settings on the fly.

  • Weekly: System default. Automatically sends a backup to the specified e-mail address(es).

Time of backup

The e-mail containing the backup file will be sent at the specified time.

Day of backup

The e-mail containing the backup file will be sent on the specified day.

Daily Backup on Network Share

Daily Backup on Network Share allows you to make a backup of the AXS Guard configuration and critical user data, such as e-mails and log files, to a network share. System administrators receive a report via e-mail when the backup has been completed.

The report is sent to the e-mail address(es) specified on the System > General screen. If an error occurs during the backup process, the type of error is also reported.

  1. Navigate to System > Tools > Backup & Restore > Backup.

  2. Click on on the Daily Backup on Network Share tab.

  3. Enter the Server settings and select the data to be backed up (fields are explained in the table below ).

  4. Click on Update. A Create Now button appears at the bottom of the screen, which can be used to create a backup immediately, to test the settings.

image

Server Setting Description
Enable automatic backup to server? Automatically sends a backup of your configuration and user data to the specified server every 24 hours (if enabled). In the unlikely event of a system crash, you will be able to swiftly recover your settings and user data as they were at the time of the last backup. Enabling this option is highly recommended.
Do automatic daily backup at (hh:mm) Performs a backup at the specified time. Use the hh:mm format.
Remote Server Name The hostname or IP of your backup server.
Share on Remote Server The name of the SMB share as broadcasted by the backup server.
Directory on Share (optional) Specify a directory within the share. Use this if you shared an entire drive, e.g. d:. This prevents backup data from being written to the root directory of the shared drive. Use \ for subfolders, e.g. backups\axsbackup is valid syntax.
User The username to log in to the backup server.
Password The password to log in to the backup server.
Backup Contents Select the data to be included in the backup.

Backup options:

  • Delete older backups: old backup files are overwritten if option is enabled (see note below)

  • AXS Guard configuration

  • logs

  • e-mails

  • faxes (only available in Belgium), and

  • SSL Web Portal settings

image

Backups on Able Servers

For customers who subscribe to a Managed Services contract, Able provides an AXS Guard configuration backup service for disaster recovery.

Backups to Able Servers occur every 3 hours for subscribing customers. Only the latest backup is stored on the Able servers; previous (older) backups are removed.

Restoring your Configuration

Restore from File

Important

  • Restoring a backup of a different AXS Guard license erases all e-mails, logs and other files stored on the AXS Guard.

  • Restoring to a Spare Unit is restricted to the same software version as the appliance being replaced (or a higher version to which data migration is supported; please contact Able support (support@axsguard.com) for guidance).

  • Restoring a back-up from another appliance means that the Host Key varies from the Host Key to which the License is bound. In this case the License has a grace period of 30 days. Restoring a back-up from the same appliance means that the Host Key remains the same and re-licensing is not necessary.

  • The Configuration Key from the back-up is always restored.

  1. Navigate to System > Tools > Backup & Restore > Restore from file.

  2. Click on the Browse button to locate the appropriate backup file. Backup files have the extension .tgz.

  3. Reboot the appliance.

    Restore from file

Restore from Server

Available backups will be shown if you configured your backup server settings under Backup > Daily Backup on Network Share.

Restoring a Backup on a Spare Unit

A Spare Unit is an unlicensed appliance, with limited configuration possibilities and allows you to swiftly replace a defective appliance.

It can also be licensed as a new appliance. In fact, all appliances can be considered spare units until they are fully licensed.

Restoring a backup on a Spare Unit is restricted to:

  • the same hardware version (e.g. AG-3XXX, AG-5XXX or AG7XXX) as the unit being replaced.

  • the same software version as the appliance being replaced (or a higher version on which data migration is supported; please contact Able support (support@axsguard.com) for guidance.

Once a backup is restored on a Spare Unit, full functionality is available. The configuration tool of the appliance can then be accessed by any user with administrative privileges.

The license from the backup is also restored on the Spare Unit. However, an appliance with a restored license only remains operational for a grace period of 30 days, during which the System Administrator needs to acquire a new license. If a new license has not been issued after this grace period, all services on the appliance will be stopped. Only the Administrator Tool will remain accessible.

Contact us (support@axsguard.com) to release the restored license of the original appliance. To relicense the appliance, follow the same procedure as used during first-time licensing.

The AXS Guard Software Update System

Overview

Version updates Revision updates Hotfixes

New attacks and methods to exploit software are discovered frequently. Keep your appliance’s software updated at all times by enabling automated updates.

There are 3 types of updates:

  • Version updates, which include major AXS Guard improvements and introduce new features.

  • Revision updates, which correct small, non-blocking software issues and contain minor improvements or features.

  • Hotfixes, which are pushed automatically to all affected appliances. Hotfixes are used when a customer has detected an issue within the current release of the product for which a fix is needed immediately.

The various update procedures are explained in the following sections.

Update Notifications

System administrators are automatically notified by e-mail when updates are available. A message will also appear on the appliance’s dashboard. In the e-mail, administrators will find detailed information about software improvements and changes (changelog). It is recommended to read the changelog thoroughly prior to installation.

The changelog information provided in the e-mail can also be viewed by navigating to System > Software Updates > Update Packages. Click on the package name to read the changelog.

logo

Manual and Automatic Update Configuration

Revision and version updates can be installed manually or automatically. A system reboot is required in both cases.

  1. Navigate to System > Software Updates > Preferences.

  2. To check for updates on the fly click on "check for updates".

Check for Updates Button

Parameter Description
Check for updates In "on" status, the appliance automatically checks if any new updates are available. To automatically activate these updates, you must enable the automatic updates option for revisions and / or versions. Available updates are listed under System > Software Updates > Update Packages. FYI only. The data in this field cannot be modified.
Update Server The names or IP address(es) of the update servers from which new software updates are downloaded by the appliance. FYI only. The data in this field cannot be changed.

Current and Restore Version Settings

logo

Parameter Description
Keep the current version permanently After installing or upgrading to a new version, you must check this option to install the new version permanently. The appliance will revert to the previous version in case of a power failure or a system reboot, unless you have checked this option.
Parameter Description
Available versions to restore Select the version to be restored from the drop-down list. Your selection will be activated after a reboot.

Automatic Revision Update Settings

To configure your appliance for manual updates:

  1. uncheck the "Automatic Updates" option.

  2. click the "Update" button.

To configure your appliance for automatic updates:

  1. check the "Automatic Updates" option

  2. specify a time for the installation of the new version or revision

  3. click on "Update"

The AXS Guard appliance will be rebooted at the specified time to automatically install new updates.

Automatic Revision Update Settings

Parameter Description
Automatic updates? Check this option to automatically activate new revision updates at regular intervals. The following two fields are only available if this option is checked. To manually activate a revision update, go to System > Software Updates > Update Packages.
Do automatic update at (hh:mm) This field is only available if automatic revision updates are enabled. Enter the time at which revision updates should be automatically activated, using the hh:mm format. For example, 02:30 would automatically activate new revision updates at 2:30AM each day.
Delay automatic update by number of days This field is only available if automatic revision updates are enabled. Enter the number of days by which automatic revision updates should be delayed. This option allows you to schedule updates when most convenient for your organization.

Automatic Version Update Settings

To configure your appliance for manual updates:

  1. uncheck the "Automatic Updates" option.

  2. click the "Update" button.

To configure your appliance for manual updates:

  1. check the "Automatic Updates" option

  2. specify a time for the installation of the new version or revision

  3. click on "Update"

The AXS Guard appliance will be rebooted at the specified time to automatically install new updates.

A system administrator must manually approve the test upgrade report and accept the new version before it can be permanently installed.

Automatic Version Update Settings

Parameter Description
Automatic updates? Check this option to automatically activate new revision updates at regular intervals. The following two fields are only available if this option is checked. To manually activate a version update, go to System > Software Updates > Update Packages.
Do automatic update at (hh:mm) This field is only available if automatic revision updates are enabled. Enter the time at which version updates should be automatically activated, using the hh:mm format. For example, 02:30 would automatically activate new version updates at 2:30AM each day.
Delay automatic update by number of days This field is only available if automatic version updates are enabled. Enter the number of days by which automatic version updates should be delayed. This option allows you to schedule updates when most convenient for your organization.

Version Updates

Overview

Version updates offer major improvements and new software features. Given the scale and impact of version updates, they are automatically tested prior to installation.

The tests simulate the update on your appliance without actually activating it. A system administrator must manually accept a version before it can be permanently installed.

There are three distinct phases when updating the appliance to a new version:

  1. Version testing and approval of the test report by a system administrator

  2. Manual or automatic installation of the new version

  3. Confirmation by a system administrator to permanently accept the new version

Version Testing and Approval

Version updates are tested automatically. The automatic testing functionality ensures that possible problems involving version updates in a production environment can be avoided. While a new version is being tested (simulated), the AXS Guard appliance continues running as normal, using its current version.

A test report is automatically generated and indicates which actions administrators should take prior to installing the new version.

  1. Navigate to System > Software Updates > Test Upgrade.

  2. To rerun a test, click on Start Test Upgrade.

The last 10 test reports remain available for viewing under System > Logs > Test Update History.

Update Test Report

Installing a New Version

A new version cannot be installed until it has been approved by a system administrator. After approval of the version update test:

  • With automatic version updates enabled under System > Software Updates > Preferences, the new version will be installed automatically at the specified time.
  • With automatic version updates disabled, the version can be manually installed by going to System > Software Updates > Update Packages and selecting the update package by clicking on its name.

System > Software Updates > Update Packages: Manual Installation

  1. Check the Activated? checkbox

  2. Click on Update to proceed with the installation.

  3. Go to System > Tools > Actions and reboot the AXS Guard appliance. The new version will be installed during the reboot process.

Accepting a New Version

Important

  • A new version should only be accepted if everything is fully functional. If not, reboot the AXS Guard appliance immediately to revert to the previous version.

  • If a new version is not accepted, the AXS Guard appliance will revert to the previous version after the next reboot.

  • When a software upgrade cannot be installed, the system administrators will be notified by email to take corrective measures. A message will also appear on the dashboard.

  1. Navigate to System > Status > Health.

  2. Check that all services are working as expected

  3. If all services are working correctly, go to System > Software Updates > Preferences.

  4. Check "Keep the current version permanently" and update.

image

Revision Updates

Revision updates correct small errors in the software and are downloaded automatically. Revision updates can either be installed manually or automatically.

  • With automatic revision updates enabled under System > Software Updates > Preferences, no action is required and the new revision will be installed automatically at the specified time.

  • With automatic revision updates disabled under System > Software Updates > Preferences, a revision can be manually installed as follows:

Installation procedure

  1. Go to System > Software Updates > Update Packages

  2. Click on the revision name in the list

  3. Check the Activated? field

  4. Click on Update to proceed with the installation.

  5. Go to System > Tools > Actions and reboot the AXS Guard appliance. The new revision will be installed during the reboot process.

Reverting to a Previous Version

Important

  • Do not to revert to a previous version if a new version has been installed for more than 2 weeks.
  • In the unlikely event of upgrade difficulties, administrators should immediately revert to the previous version.
  • Reverting to a previous version is only possible if it is still available on the system. Older versions are automatically removed after a certain period of time to preserve system disk space.

A complete downgrade without any loss of user and/or configuration data is possible when the upgrade to a newer version has been successfully completed and the administrator has accepted/acknowledged the newer version (or the version has been automatically accepted after 24 hours by the system).

If the administrator chooses to restore the appliance to a previous version, a complete version downgrade will be carried out and the system will be restored to the version which was installed prior to the upgrade.

  1. Navigate to System > Software Updates > Preferences.

  2. Select the version to be restored from the drop-down list and update.

  3. Reboot the AXS Guard appliance.

System > Software Updates > Preferences: Reverting to a previous Version

Hotfixes

Hotfixes occur automatically and transparently. They are used to ensure the optimal operation of appliances in the field and are pushed automatically by our update servers. Hotfix installations are beyond the control of resellers and system administrators. They are usually introduced when a customer has detected an issue within the current release which requires an immediate solution.

Hotfixes are installed in a particular order. The system update protocol automatically checks if all available hotfixes have been correctly installed before a new software revision or update can be installed by a system administrator.

Server-Side SSL and TLS Options

Introduction

TLS SSL Secure Sockets Layer Transport Layer Security HMAC GCM Record Protocol Handshake Protocol

The AXS Guard uses SSL and TLS to secure a variety of its services, for example webmail and the SSL web portal. SSL and TLS are widely used protocols that provide host authentication, data transmission confidentiality and integrity.

In turn, SSL and TLS consist of a variety of protocols, which have their own purpose. From a security perspective, the two most important of these protocols are:

  • The Handshake Protocol, which establishes a common secret between the client and the server.

  • The Record Protocol, which protects the data traveling between the client and the server.

The Record Protocol provides three ways to protect data:

  1. The HMAC followed by encryption with a block cipher in CBC-mode.

  2. The HMAC followed by encryption with RC4.

  3. GCM with a block cipher.

In the following section, you will find a non-exhaustive list of known SSL and TLS vulnerabilities.

Known Vulnerabilities

Target

Date

Type

Versions Affected

Solution

CBC-mode encryption with block cipher (e.g. 3DES, AES)

Sep 2011

SSL/TLS Browser Exploit (BEAST)

  • SSL 3.0

  • TLS 1.0

Use TLS 1.1 or later or use RC4.

Cookies containing secrets

Sep 2012

Compression Ratio Info-leak Made Easy (CRIME)

  • TLS 1.0

  • TLS 1.1

  • TLS 1.2

Disable TLS/SPDY compression

CBC-mode encryption with block cipher (e.g. 3DES, AES)

Feb 2013

Lucky 13

  • SSL 3.0

  • TLS 1.0

  • TLS 1.1

  • TLS 1.2

Use RC4

Encryption with RC4

Mar 2013

RC4 Attack

All versions using RC4

Use GCM-mode encryption

Secrets exposed by web applications in HTTP response bodies

Aug 2013

Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH)

All versions

Disable HTTP compression

Security Recommendations

SSL and TLS Cipher Suites

The following settings are recommended for any services using SSL/TLS:

  • Support for SSL 2.0 and SSL 3.0 must be disabled

  • Servers must support TLS v1.0, TLS v1.1 and TLS v1.2

  • Do not allow symmetric encryption algorithms in the SSL/TLS Record Protocol with key lengths smaller than 112 bits

  • Enforce RC4 as the preferred encryption algorithm combined with SHA-1 as the hashing algorithm

  • Only allow authenticated key exchange protocols in the SSL/TLS Handshake Protocol

  • Never allow cipher suites that do not provide encryption

Key Pairs and Certificates

Important

Protect and back up your private keys with a complex password at all times.

  • RSA key pairs should have a modulus length of at least 2048 bits.

  • RSA key pairs must not have a modulus length exceeding 3072 bits to ensure the efficiency of cryptographic operations.

  • Do not use the MD5 algorithm to sign certificates. Use SHA-1 instead.

  • The following algorithms are recommended for signing: SHA-256, SHA-384 or SHA-512

  • Use a modulus length of at least 2048 bits when signing certificates with RSA keys.

  • The lifetime of certificates should not exceed 5 years.

  • When renewing a certificate, its is recommended to renew the associated key pair as well.

Compression

Do not allow TLS-level or SPDY-level compression for any services that are using SSL and TLS.

Session Initiation and Renegotiation

Disable client-initiated renegotiation for any services using SSL/TLS to avoid denial-of-service attacks.

Services Offering TLS

System administrators can change the default TLS configuration of the following AXS Guard services:

  • The web-based configuration tool

  • The reverse proxy

  • The MTA (SMTP server with starttls enabled)

  • The SSL Web Portal (VPN)

Configuration

  1. Log in to the AXS Guard.

  2. Go to System > Security > TLS.

  3. Click on a service to configure the TLS options, which are explained in the tables below.

  4. Update your configuration when ready.

    TLS Security Settings

Info

Also see http://www.openssl.org/docs/apps/ciphers.html for detailed information about cipher groups mentioned in the following tables.

Parameter Description
Service The AXS Guard service to which the settings will be applied (System > Security > TLS).
Protocols The SSL or TLS version(s) to be supported by the service, i.e. SSLv2, SSLv3, TLSv1, TLSv1.1 or TLSv1.2. Select the ones that should be enforced.
Cipher Description
EXPORT All export ciphers, including 40 and 56-bit algorithms
LOW All low strength ciphers (currently those using 64 or 56-bit encryption algorithms but excluding export cipher suites, single DES)
MEDIUM Mostly all ciphers with 128-gbit encryption
HIGH All ciphers with key lengths larger than 128 bit (and some with 128 bits)
Prefer Our Cipher List Order During SSL negotiation, the client proposes a list of supported ciphers to the AXS Guard service in the order preferred by the client. The service then selects the first compatible one, which may or may not be the strongest cipher supported by both. By enabling this option, the order of the ciphers proposed by the client is overruled and the server offers the strongest cipher first. Note that this may affect older clients or software, which potentially propose a weaker cipher first due to a poor implementation or for reasons of performance.
Prefer Streaming Ciphers In order to mitigate the risk of a BEAST or Lucky13 attack, you can choose a streaming cipher over a block cipher. Such attacks exploit a flaw in the way old TLS versions initialize vectors for CBC block ciphers and allow the unencrypted plaintext to be extracted from an encrypted session. The AXS Guard appliance is protected by default against Lucky13 attacks. Note that TLS version 1 and prior versions (SSL versions 2 and 3) only support 1 widely-adopted streaming cipher, namely RC4, which is obsolete and is known to be vulnerable. This option is disabled by default.
Disable Broken/Flawed Ciphers Check to disable ciphers that are considered broken or flawed and that should not be used to secure connections. Leave this option unchecked if compatibility with older clients is an issue. This option is ignored if the SSLv2 protocol is enabled. Currently, only the MD5 hash function is considered to be flawed.
Option Description
Enable Compression Enables compression at the SSL level if checked. Note that this is enabled for all services by default. Be aware of the BREACH attack, which enables an attacker to read encrypted messages over the Internet by injecting plaintext into HTTPS requests and measuring compression changes.
Require Authentication Require cipher types that use authentication. Most notably it disables aNULL ciphers offering no authentication and ADH ciphers allowing anonymous Diffie-Hellman authentication. Authentication is required for all services by default.
Enable Opportunistic Encryption If the client attempts to encrypt the communications channel, TLS is used. If not, the appliance falls back to unencrypted communications. This method requires no pre-arrangement between clients and the appliance. Opportunistic encryption is defined in RFC 7435.

Basic openssl Testing

Syntax

To test a specific cipher:

openssl s_client -cipher [CIPHER] -[starttls|ssl3|ssl2|tls1] -host [HOST/IP] -port [PORT]

To test a group of ciphers:

openssl s_client -connect <HOSTNAME:PORT> -cipher [CIPHER]

To check available ciphers and the group they belong to:

# openssl ciphers -v LOW
EDH-RSA-DES-CBC-SHA     SSLv3 Kx=DH       Au=RSA  Enc=DES(56)   Mac=SHA1
EDH-DSS-DES-CBC-SHA     SSLv3 Kx=DH       Au=DSS  Enc=DES(56)   Mac=SHA1
ADH-DES-CBC-SHA         SSLv3 Kx=DH       Au=None Enc=DES(56)   Mac=SHA1
DES-CBC-SHA             SSLv3 Kx=RSA      Au=RSA  Enc=DES(56)   Mac=SHA1
DES-CBC-MD5             SSLv2 Kx=RSA      Au=RSA  Enc=DES(56)   Mac=MD5

Examples

In the following examples, we assume that 198.51.100.1 is your AXS Guard IP address. To test the AXS Guard administrator tool using SSLv3, SSLv2 and TLS respectively:

openssl s_client -cipher 'EXP-RC4-MD5' -ssl3 -host 198.51.100.1 -port 82

openssl s_client -cipher 'EXP-RC4-MD5' -ssl2 -host 198.51.100.1 -port 82

openssl s_client -cipher 'EXP-RC4-MD5' -tls1 -host 198.51.100.1 -port 82

To test the AXS Guard SMTP server (starttls must be enabled) using SSLv3, SSLv2 and TLS respectively:

openssl s_client -cipher 'DES-CBC3-SHA' -starttls smtp -host 198.51.100.1 -port 25

openssl s_client -cipher 'DES-CBC-MD5' -ssl2 -starttls smtp -host 198.51.100.1 -port 25

openssl s_client -cipher 'DES-CBC3-SHA' -tls1 -starttls smtp -host 198.51.100.1 -port 25

To test compression, run one of the above openssl s_client commands and look for compression (e.g. combine the openssl command with grep)

openssl s_client -cipher 'DES-CBC3-SHA' -tls1 -starttls smtp -host 198.51.100.1 -port 25 | grep -i compression

Security Levels and Policies

Security Policies

Security Policies define rights for authentication and for data transmission related to the various AXS Guard services, such as e-mail, web access and the firewall:

  • E-mail policies are based on the sender’s and the receiver’s e-mail addresses.

  • Web access and firewall policies can be assigned at the system level, the computer level (based on the computer’s IP address) or - after authentication - at the user level. Authentication allows the configured group or user-specific policies to be assigned. Without authentication, the AXS Guard cannot identify the user, and will assign either computer or system-based policies for Web and firewall access.

The image below explains the concept of security policies, the rules they contain and their relation to the AXS Guard security levels. In order to link individual rules, which are the smallest configuration element of an AXS Guard feature, to security levels, three simple steps are required:

  1. Start by creating the rule(s)

  2. Add the rule(s) to a policy

  3. Assign the resulting policy to a security level

    Security Policies in relation to Security Levels

Info

It is critical to enforce user authentication when possible. A Single Sign-On Tool is available for the AXS Guard to implement Firewall and Web access authentication. This tool allows users to automatically sign-on with the AXS Guard after logging on to their client PC. For more information, please refer to the documents AXS Guard Single Sign-On Utility (SSO) and AXS Guard Authentication How To, available through the permanently on-screen Documentation button.

Security Levels with Authentication

User Level

Settings defined at the user level are specific for a single user and determine special access rights or restrictions for a user on the network (i.e. exceptions). The AXS Guard applies the appropriate Security Policy, which defines a user’s rights, based on the user credentials.

  1. Navigate to Users & Groups > Users

  2. Select the appropriate user from the list

  3. Adjust the settings as appropriate (user and group management are explained in User and Group Management ).

    Changing user-specific Policies

Group Level

An AXS Guard group is a logical unit of users who need the same access rights or restrictions on the network. The purpose of using groups is to simplify access control configuration and management. The AXS Guard retrieves the Security Policy, which defines a group’s access rights based on the user credentials and the user’s group membership.

  1. Navigate to Users&Groups > Groups

  2. Select the appropriate group from the list.

  3. Adjust the settings as appropriate).

    Changing Group-specific Policies

Security Levels without Authentication

Computer Level

Important

We recommend enforcing user authentication when possible, as this is the most secure option.

Registering a computer on the AXS Guard allows a policy to be applied to the computer, e.g. firewall rights or the right to use the AXS Guard RADIUS authentication service (for more information about RADIUS authentication, please refer to the AXS Guard Authentication How To, available via the Documentation button).

An unauthenticated user on a registered computer is assigned computer-level Web access and firewall policies, based the computer’s IP address. Assigning rights at the computer level (based on the host’s IP address) is therefore less secure than assigning them at user level, because unauthorized users with physical access to the computer could access the network.

Computer registration and computer level assignment of security policies should only be used for servers which:

  • have a static IP address

  • need specific access to services on the Internet, e.g. to download critical system updates.

To change computer-specific policy settings:

  1. Navigate to Computers

  2. Select the appropriate computer from the list

  3. Adjust the settings as appropriate.

    Changing Computer-specific Policies

System Level

Important

We recommend enforcing user authentication when possible, as this is the most secure option.

A security policy is applied by default at the system level only if a policy has not been assigned at any other level. The system level must enforce the tightest security, as the defined policies at this level are valid for all computers which are physically connected to your network. A user who is physically connected to your network and who does not authenticate, is automatically assigned system-level access rights if his/her computer is not registered on the AXS Guard.

System-specific policy settings are configured separately for each feature, e.g. for the firewall, Web access etc. For further information, please refer to the relevant AXS Guard How To guide, available via the permanently on-screen Documentation button.

Changing System-wide Policies

Example Configurations

The following two examples demonstrate a user-specific configuration and the efficiency of using groups to assign Security Policies to multiple users.

Example 1

A company has a dedicated group for its Accounting department. The group consists of 5 users. All users of the group are subject to the same Firewall Policy. However, one user (Bob) needs special access to an Internet server which is forbidden by the Group Policy.

To allow access for user Bob:

  1. Create a new firewall rule(s) allowing access to the specific server

  2. Add the rule to a security policy.

  3. Select Add to Group Firewall Policies, in the user’s Firewall profile.

  4. Add the newly created security policy. This combines the group and the user-specific policies.

The result is that the user can access the specific server, while he/she is still subject to his Group’s Firewall Policy. For detailsabout firewall rules and policies, please refer to the AXS Guard Firewall How To, which is available via the Documentation button.

Example 2

An office of 500 users is divided into 6 groups. Every user needs access to the AXS Guard e-mail system. This means that you must create of 1 firewall rule per service, i.e. POP, IMAP, SMTP, LDAP (for the address book), which amounts to a total of 4 rules.

  • Without Firewall Policies: creating 4 rules, and adding them to 500 users would require 2004 configuration steps.

  • With Firewall Policies at the group level: creating 4 rules, adding them to 1 Firewall Policy and subsequently assigning the Policy to 6 groups requires only 11 configuration steps.

User and Group Management

Overview

In this section we:

  • define AXS Guard users and groups

  • list the advantages of assigning security policies at the user and group levels

  • explain the general settings for users

  • explain how to create and modify users and groups

  • explain how user and group templates can speed up configuration

For settings specifically related to AXS Guard features such as e-mail or Web access, please refer to the relevant AXS Guard How To guide available via the Documentation button.

Users

An AXS Guard user is a person who:

  • Is registered on the appliance, either manually via the administrator tool or automatically though synchronization with a directory server (LDAP). For information about user synchronization, see the AXS Guard Directory Services How To, which is available via the Documentation button in the administrator tool.

  • Has certain access privileges (firewall, web access, e-mail, etc.) based on his/her profile and group settings.

  • Has a mailbox (if the e-mail server feature is activated on your appliance).

User templates, in which common access rights and other user-specific settings are specified, allow administrators to configure the system more easily.

Groups

An AXS Guard group is:

  • A logical set of users, based on their location, department, access rights or position within an organization, e.g. accountants, the HR division, the legal department, management, etc.

  • Linked to a set of permissions or restrictions which apply to its members.

Groups can be created with the AXS Guard administrator tool or can be imported from a Directory Server. For more information on group synchronization, see the AXS Guard Directory Services How To, which available via the Documentation button.

Group templates, in which access rights and other group-specific settings are specified, can help administrators to easily configure common group settings.

The relationship between user and group level policies are feature-specific. For example, with firewall access, group level policies can be overruled, enforced, or fine-tuned. For web and e-mail access, group level policies can be enforced or overruled at the user level, but cannot be added. For more information, see the relevant AXS Guard How To guides, which are available via the Documentation button.

A group can also consist of a single user.

User and Group Level Security

Assigning security policies at the computer level is insecure. Therefore Able recommends assigning security policies at the user or group levels with authentication.

Advantages inherent to user and group level security are:

  • Authentication (identification of the user) is enforced, which is the most secure option. Strong user authentication, e.g. Able DIGIPASS can be easily implemented.

  • Physical access to a computer is insufficient to obtain network access, i.e. credentials always have to be provided before access is granted.

  • A list of users and/or groups is easier to maintain than a list of computers.

  • Users who share a computer, e.g. at a reception desk, can be assigned different user-specific rights. (Assigning a computer level security policy assigns the same rights to all (unauthenticated) users of the computer, which is insecure).

General User and Group Settings

Navigate to Users & Groups > Preferences. The options are explained in the table below.

User and Groups General Settings

Field Description
Secure Password Checker Enable this option to activate the secure static password checker for users. If enabled, the system rejects static passwords which can easily be guessed. The password criteria are listed below this table.
Users may change static passwords Enable this option to allow users to change their static password. Users are only able to change their passwords if their access rights to the AXS Guard Administrator Tool are set to User.
Users may change auto-response settings This option is only available if the AXS Guard e-mail feature is activated and allows users to change their auto-response settings. With auto-response, e-mail correspondents can be notified automatically if a recipient is unavailable. For more information, please refer to the AXS Guard E-mail How To, available via the Documentation button.
Users may change their e-mail forwarding This option is only available if the AXS Guard e-mail feature is activated and allows a user’s e-mails to be forwarded to one or more e-mail address(es). A copy of the forwarded message(s) can also be kept in the recipient’s mailbox. For more information, please refer to the AXS Guard E-mail How To, available via the Documentation button.

Password complexity criteria:

  • must be composed of at least 6 characters

  • must be different from the username

  • may not be a word in the dictionary (to prevent password dictionary attacks)

  • may not be too simple, e.g. 123456 or password

  • may not include a # symbol

Important

We strongly recommends the use of OATH or DIGIPASS authentication. 2FA is the most secure authentication method, because a one-time password is randomly generated by the DIGIPASS each time the user logs on. For additional information, see the AXS Guard Authentication How To, available via the Documentation button.

Creating and Editing Groups

  1. Navigate to Users & Groups > Groups

  2. Click on Add New.

  3. Enter the settings as explained below.

  4. Click on save when finished.

    Creating a Group

Important

See the relevant documentation for additional information about feature-specific options.

Parameters Description
Group Name A name for the new group. Invalid names will trigger a validation error.
Description Describe your group, e.g. Human Resources. This field is optional.
Enabled If unchecked, group members will be prevented from logging in.

Creating and Editing Users

  1. Navigate to Users & Groups > Users

  2. Click on Add New.

  3. After you have configured the settings as required, click on Save.

    Users and Groups > Users > Add User

Important

  • To speed up the creation of new users, administrators can define a user template. A user template is a collection of the settings which all users have in common.
  • See the relevant documentation for additional information about feature-specific options.

  • The UPN format cannot be used to authenticate for PPTP and AXS Guard services for which Kerberos authentication has been enforced.

Format Description and Examples When to use

User account name

Also known as the logon name, e.g. UserName, Bob, Alice, JonDoe.

This format must be used for authentication when the AXS Guard system domain matches the domain of the directory server of which the user is also a member or if the AXS Guard appliance is not synchronized with a directory server.

User Principal Name (UPN)

The UPN format is used to specify an Internet-style name, such as UserName@example.com.

This format must be used for authentication when the AXS Guard system domain does not match the domain of the directory server of which the user is a member. Note that this format can only be created through synchronization with a directory server; it cannot be entered manually.

Administrative Privileges

In the AXS Guard Administration tab on the lower part of the Add User screen you can configure:

  • Tool Access Type settings: These settings determine whether or not a user has access to the AXS Guard web-based administrator tool.

  • Console Tool Access: Only for basic administrators or above. If enabled, the user has access to the appliance’s console for advanced troubleshooting.

  • Technical Mailings: Select which messages to receive from Able, e.g. information about critical updates.

  • Access to FTP files: System legacy option.

Tool Access Type Description

None

The user has no access to the administrator tool.

User

The user can only modify his/her full name, auto-response settings, password and e-mail forwarding settings, if allowed by the system administrator.

Reporting User

A reporting user has the same access as a regular user, but also has access to web access, e-mail and the AXS Guard hardware performance statistics.

Distribution List Administration

This option is only available if the AXS Guard e-mail feature is enabled. This user type has the same access rights as a reporting user and can manage e-mail distribution lists.

Basic Administration

This user type only has restricted administrator access. At this level, only non-critical system settings may be modified, e.g. user and group settings.

Full Administrator

This is the default administrator type. All standard system settings can be modified or viewed.

Advanced Administrator

Caution: Only expert administrators should be assigned allowed this type of access. Advanced administrators can view and modify system-critical settings, which are typically never modified, e.g. DNS forwarding.

Access to FTP files

FTP access can be used to download AXS Guard log files, e.g. firewall logs. FTP access towards the AXS Guard is only possible if allowed by the firewall.

Options for FTP access are displayed under the AXS Guard Administration tab in the lower part of the Add User screen.

FTP Access Option Description

No FTP Access

Access to FTP is denied.

Unrestricted FTP Access

Provides access to the AXS Guard logs and the IMAP mail directories (only if the AXS Guard e-mail feature is enabled under System > Feature Activation).

Intranet-Extranet FTP access

Allows the user to upload and download files to and from the AXS Guard Intranet and Extranet areas (legacy option).

Console Tool Access

The console tool is a text-based command line interface (CLI) to edit and display critical AXS Guard configuration parameters via menus. It also allows you to execute commands for advanced troubleshooting, such as network traffic analysis.

Enabling Console Tool Access for a User

Parameter

Description

Console Tool Access

Check to enable access to the console tool.

Console Tool RSA/DSA Public Key

Copy and paste the user’s public key, generated with ssh-keygen or PuTTYgen.

User and Group Templates

AXS Guard user and group templates allow administrators to easily configure common user or group settings. Examples of common settings are firewall access rights, web access rights and e-mail policies. The template system prevents you from repeatedly having to define identical settings for different users and groups, thus simplifying configuration. The template settings are automatically applied each time a new group or user is manually created or synchronized with a directory server.

The template system is particularly useful for synchronizing a large number of users and groups with a Directory Server, such as Active Directory. For information about user and group synchronization, see the AXS Guard Directory Services How To, available via the Documentation button.

System administrators need to determine which AXS Guard privileges and services are shared by most AXS Guard groups and users. If a certain user or group needs special access (or must be denied access) to a specific resource, it is easier to define and assign the exception(s) afterwards. For information on how to configure user and group templates, see the following sections.

You can create one user template and one group template per LDAP profile. The AXS Guard provides default user and group templates which can be modified to accommodate your specific needs.

Example of a user template on the AXS Guard

Group Template Settings

Modification of the default group template does not affect existing AXS Guard groups. The group template is only applied when a new group is created.

  1. Navigate to Users and Groups > Groups.

  2. Click on the Template button as indicated below.

    Users and Groups > Groups > Template Button

  3. Configure the group settings as required.

  4. Click on Update to finish. (The system may display a validation warning to counter potentially dangerous configurations, which need to be modified before you can continue.)

    Users and Groups > Groups > Template

The number of tabs available on your system may vary depending on which features are activated on your AXS Guard appliance. Go to System > Feature activation for an overview of activated features on your system.

User Template Settings

Modification of the user template does not affect existing AXS Guard users. The user template is only applied to new users.

  1. Navigate to Users and Groups > Users

  2. Click on the Template button as indicated below.

    Users and Groups > User > Template Button

  3. Configure the user settings as required. Tabs on the Modify User Template screen may vary depending on the features which are activated on your AXS Guard. For more information about feature-specific settings, see the relevant AXS Guard How To guides available via the Documentation button.

  4. Click Update to finish. (The system may display validation warnings to counter potentially dangerous configurations, which need to be modified before you continue).

    Users and Groups > User > Template

The number of tabs available on your system may vary depending on which features are activated on your AXS Guard appliance. Go to System > Feature activation for an overview of activated features on your system.

Computer Management

Overview

In this section, we explain:

  • when computers need to be registered on the AXS Guard

  • the disadvantages of assigning security policies at the computer level, and

  • how to register a computer on the AXS Guard.

For settings specifically related to AXS Guard features such as e-mail or Web access, please refer to the relevant AXS Guard How To guide, available through the permanently on-screen Documentation button.

When to register a computer

Able strongly recommends enforcing user authentication whenever possible rather than assigning security policies at the computer level.

Registering computers on AXS Guar allows rights and restrictions to be assigned through security policies. Security policies control network access from the computers, such as the firewall rights or the right to use the AXS Guard RADIUS authentication service. (For more information on RADIUS authentication please refer to the document AXS Guard Authentication How To, available through the permanently on-screen Documentation button.)

Assigning security policies at the computer level is only appropriate for servers (with a static IP address) which need specific access, e.g. for the use of the RADIUS service on the AXS Guard. In all other instances, Able recommends assigning security policies at user and group levels and enforcing user authentication.

It is not necessary to register computers from which users authenticate, as access rights in this case are determined based on the user credentials provided.

Computer Level Security

Disadvantages inherent to computer level security are:

  • The authentication process (identification of the user) is bypassed, which is insecure.

  • Physical access to a computer is sufficient to acquire possibly more rights than normally permitted with user authentication and could lead to unauthorized access to network resources or to abuse of your network’s public IP address.

  • A computer list may lead to errors and is difficult to maintain (DHCP), while a user list is not (especially for large networks).

  • It is not possible to assign different rights to multiple users who use the same computer, e.g. a reception desk. This is only possible with user authentication.

  • Troubleshooting is more difficult and cumbersome, since access rights can be configured at the user, group and computer level.

It is imperative to enforce user authentication wherever possible. A Single Sign-On Tool is available for the AXS Guard to implement Firewall and Web access authentication. This tool allows users to automatically sign-on with the AXS Guard after logging on to their client PC. For more information, please refer to the documents AXS Guard Single Sign-On Utility (SSO) and AXS Guard Authentication How To, available through the permanently on-screen Documentation button.

Registering Computers

Important

  • Only servers (with a static IP address) should be registered on AXS Guard.
  • Enforce authentication for regular computers, such as workstations.

  1. Navigate to Computers.

  2. Click on Add new.

  3. Configure the settings as explained in the following tables.

  4. Click on Save.

    Computers > Add Computer

The number of tabs available under Computers are linked to the features that are activated and may vary on your AXS Guard appliance. Go to System > Feature Activation for an overview of enabled features on your system.

General Settings

Field Description

Computer Name

Enter a name for the computer, using lower cases without spaces, starting with an alphabetic character, followed by any number of alphanumeric characters and/or the special characters: hyphen (-) and full stop(.) If possible, use the name of your computer, as defined in your Network / Properties / Identification tab (where the computer name is listed) since this is usually unique. The entered computer names and aliases are added to the internal DNS system of the AXS Guard appliance.

Enable Computer

Check to enable (default setting). Uncheck to disable. If disabled, system-level or user-level policies will be applied for web access, authentication, the firewall and SRV records. When a computer is disabled, its SRV record is not added to the internal DNS repository of the AXS Guard appliance.

Alias Names

You can add several names for a computer, providing the names adhere to the same specifications as for the Computer Name (see field above). All aliases are added to the AXS Guard internal DNS server. Computer names, computer aliases, device names and device aliases need to be unique in the network.

IP address

Enter the IP address of the computer to be added. IP addresses of computers must be unique. If you want a certain IP address to be known under (a) different name(s), the name(s) can be added in Alias Names as described above.

This computer can receive SMTP mail

Enable this option if the computer is running an SMTP mail server. This may be the case, for example, if the mailboxes on the AXS Guard appliance aren’t used, but e-mail is forwarded from the AXS Guard appliance to an Exchange server instead. For more information, see the AXS Guard E-mail Relay How To, available via the permanently on-screen Documentation button.

Use system mail policy when no other policy can be found

This option is only visible if the option above is enabled. Enable the option if the computer is a mail server where each user can control his/her own e-mail forwarding. In this case, e-mails could be sent to the AXS Guard mail content filtering system where both the sender and recipient addresses don’t belong to local or forwarded domains. Without activating this option, these e-mails would be blocked, as no mail policy is assigned. Activating this option will enable the AXS Guard to handle the computer’s mail traffic using the system mail policy as defined under E-mail > General.

Authentication Linking

Authentication Linking

Field Description

Overrule system authentication setting

AXS Guard firewall and web access authentication can be combined (linked) or separate (unlinked). Check to link authentication for users of this computer. This configuration overrules the system-wide configuration under Web Access > General.

Allow authentication

Uncheck to block all authentication requests from this computer.

Link Web Access and Firewall authentication

Linked authentication is the default configuration and combines authentication for firewall and web access privileges. With linked authentication, users are mapped to the computer’s IP address from which they authenticate, making the user and IP address a unique pair. Based on this unique pair, the defined firewall and web access rights are assigned to the user after successful authentication.

Allow Basic Authentication for Web Access

This option is only available with unlinked authentication. Users will be invited to authenticate via a browser popup when they attempt to access the Internet via the AXS Guard proxy server. Configured computer ACLs don’t apply in this case. Web access is only authorized after authentication, including access to sites configured in system-wide ACLs (under System > Web Access > General). After authenticating, the user’s group and / or user level ACLs are applied. If no user or group ACLs exist, the system-wide ACLs are applied.

Allow Ident Authentication for Web Access

The Ident Protocol, defined per RFC 1413, is an Internet protocol that helps to identify the user of a particular TCP connection. This simplifies management in that you do not have to match IP addresses to computers to regulate web traffic. Using Ident has several benefits over the SSL (SSO) or proxy login methods, primarily that the user does not need to enter username and password credentials for Web Access. Instead, an Ident server running on the citrix client system will automatically relay the Windows username to the AXS Guard proxy.

Web Access Control

Web Access Control at the Computer Level

Field Description

Overrule system Web access filter

Check to overrule the system-wide web access filer defined under Web Access > General.

Web Access Filter

Select the desired web access filter from the drop-down list. Go to Web Access > Filters > ACL for an overview of configured web access filters.

Firewall Access Control

Firewall Access Control at the Computer Level

Button Description

Add Firewall Policy

Select the desired firewall policy from the drop-down list. Go to Firewall > Policies > Dynamic for an overview of assignable firewall policies.

Application Control

Computer-level Application Control Policy Configuration

Option Description

Use system application control policies

Use the system-wide policies, assigned under Application Control > General.

Add to system application control policies

Assign specific policies to this computer, in addition to the system-wide policies configured under Application Control > General.

Overrule system application control policies

Do not enforce the system-wide policies, but only the specified policies. Specific policies are enforced based on the computer’s IP address.

SRV Records

You can add SRV records to the Internal DNS server of your appliance. SRV Records extend DNS functionality to enable location of services outside of the standard record types supported in DNS. Various protocols such as SIP and XMPP use SRV records to allow discovery of the service endpoint for a particular domain. The SRV record is defined in RFC 2782.

SRV Records

Field Description

Service Name

The symbolic name of the desired service.

Protocol

Select the transport protocol of the desired service from the drop-down list; TCP or UDP.

Port

The TCP or UDP port on which the service is to be found.

Priority

The priority of the target host. A lower value means a higher priority.

Weight

A relative weight for SRV records with the same priority. A higher value means more weight.

TTL

Standard DNS time to live field.

Example of an SRV record

_sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.

Network Configuration

Introduction

In this chapter, we explain the various network settings. Topics covered in this section include:

  • Network devices that you may find on your appliance

  • How to configure Ethernet, Virtual Local Area Network (VLAN) and PSTN devices. (The number of available network devices varies per model. Each appliance has at least two Ethernet network devices and one or more PSTN devices).

  • How to configure the internal DNS repository (Domain Name System).

  • How to configure the DHCP server.

  • The basic principles of routing.

  • How to configure NAT (Network Address Translation).

Supported Network Devices

Physical Devices

  • PSTN devices

  • Ethernet devices

  • Bridges

  • Bond devices

Virtual Devices

  • VLAN devices.

  • TUN devices: A TUN device is a virtual point-to-point IP link used by the Personal aXsGUARD (PAX).

  • TAP devices: A TAP device is a virtual ethernet adapter used by the OpenVPN server.

  • PPTP devices: used by PPTP client and servers. For information about PPTP, click on Documentation to download the PPTP How To.

  • e-tunnel devices: Special devices used by IPsec e-tunnels. See the IPsec How To for more information.

  • IPsec devices: Devices used for IPsec tunnels and L2TP. See the respective manuals for more information.

  • PPPoE devices: The Point-to-Point Protocol over Ethernet (PPPoE) is a network protocol for encapsulating Point-to-Point Protocol (PPP) frames inside Ethernet frames. It is used mainly with DSL services.

Ethernet Devices

Configuration

  1. Navigate to Network > Devices > Eth.

  2. Click on a logical device in the list. A screen similar to the image below appears.

  3. Configure the settings as explained in the following sections on:

    • general settings

    • interface types

    • connection settings such as the speed, duplex mode and MTU

    • IP settings

    • account settings

    • connectivity checks

  4. Click on Update.

Network > Devices > Eth > Modify Ethernet Device

General Settings

Changing the configuration of network devices requires the system to be rebooted.

Field Description

Logical Device

The name of the physical device. FYI only. This name cannot be changed.

DNS Name

The name of the network device as known by the internal DNS repository of the AXS Guard appliane. FYI only. This name cannot be modified.

Description

A description for the device (optional).

Alias Names

Alias(es) for the DNS name. Use the Add button to specify multiple aliases.

Interface Types

  • Not in use: Select this option to disable the device.
  • Internet: Select this option if the device is connected to the Internet, for example your DSL modem. This device can either be assigned a public or a private IP address (e.g. in NAT environments). Multiple Internet devices can only be configured if the Internet Redundancy feature is enabled under System > Feature Activation.
  • Secure: The network device to which all your company workstations are connected, shielded from the Internet by the firewall of the appliance. This device has an IP address in the private range. 192.168.250.254/24 is the factory default IP address.
  • DMZ: This network device can either be assigned a public or private IP address. The DMZ is an insecure area where you would install a public server for which the AXS Guard Reverse Proxy cannot be used.

About Interface Types

If the AXS Guard appliance is used for authentication only, there is only one secure interface. Interface settings for the Internet and DMZ are not relevant in this case. For more information about AXS Guard authentication services, see the AXS Guard Authentication How To, which can be accessed via the on-screen Documentation button.

AXS Guard used as a Standalone Authentication Appliance

If the AXS Guard appliance sits at the gate of your network, as illustrated below, configure the interface type according to the network to which it is connected, i.e. the Internet, the Secure LAN or the DMZ.

Using the AXS Guard Appliance as a Corporate Gateway

Connection Settings

Connection Settings

Setting

Description

Upstream bandwidth

This parameter is only relevant if you are using bandwidth management, which must be enabled under System > Feature Activation. The upstream bandwidth is the maximum amount of data which can be sent through the device per second (expressed in Kilobits per second). A value of 0 (factory default value) means that bandwidth management is not used.

Downstream bandwidth

Only relevant for bandwidth management. The downstream bandwidth is the maximum amount of data which can be received by the device per second (expressed in Kilobits per second). A value of 0 (factory default value) means that bandwidth management is not used.

Connection Modes

Fixed IP Configuration: Select this option to assign a static IP address to the network device.

DHCP Client: DHCP is an Internet protocol that allows IP addresses to be assigned dynamically by a DHCP server (Defined per RFC 2131). Select this option to dynamically assign an IP address to the device.

PPTP Client (Internet Only): In some countries, Internet Service Providers use PPTP to connect their customers to the Internet. Enter the correct IP and account information. Contact your Internet Service Provider if you are unsure about the account information.

PPP over Ethernet (Internet Only): PPPoE is a network protocol for encapsulating Point-to-Point Protocol (PPP) frames inside Ethernet frames. It is used mainly with ADSL services where individual users connect to the ADSL transceiver (modem) over Ethernet (Defined per RFC 2516). Contact your ISP if you are unsure about the account information.

Speed / Duplex Mode

The factory default setting is auto-detect, which negotiates the speed and duplex settings for the highest possible data rates. For this mode to function properly, you must also configure the other endpoint (switch) so it uses automatic negotiation as well.

  • It is crucial to configure the network device and the other endpoint of the cable (normally an Ethernet switch or another adapter if running in a point-to-point configuration without an Ethernet switch) the same way. If one endpoint is manually set to a specific speed and duplex mode, the other endpoint should be set to the same speed and duplex mode. Discrepancies will more than likely have an adverse impact on network performance.

  • It is best practice to use auto-detect wherever possible, as it is the default configuration for most Ethernet switches. However, some 10/100 Ethernet switches do not support auto negotiation. These types of switches require that you manually set both endpoints to the desired speed and duplex mode.

MTU

Packet size, often referred to as MTU (Maximum Transmission Unit) is the greatest amount of data that can be transferred in one physical frame on the network. For Ethernet, the MTU is 1500 bytes, for PPPoE 1492, dial-up connections often use 576. 1500 is assumed when no value is specified.

IP Settings

IP Settings

Field

Functionality

IP Address/Netmask

The appliance’s IP address as seen from a network zone connected to the Ethernet device. Use the CIDR notation to specify the netmask. A netmask of /24 will be assumed if none is specified. 192.168.250.254/24 is the factory default IP and netmask.

IP Aliases

Use this field to assign additional IP addresses to the network device. Aliases are used to connect several subnets (network segments) to the same Ethernet device. Use the CIDR notation to specify the netmask. A netmask of /24 will be assumed if none is specified.

Gateway

If the Interface Type is set to Internet, enter the IP address of the gateway provided by your Internet Service Provider (ISP). Contact your ISP if you are unsure about the gateway IP.

If the Interface Type is not set to Internet:

  • where the appliance is used as a gateway, leave this field empty.

  • where the appliance is used for authentication only, (i.e. not as a gateway), enter the IP address of your network’s default gateway.

Account Settings

Account Settings can only be configured if one of the following connection modes has been selected:

  • PPTP Client

  • PPPoE

Account Settings

Field Description

ISP Account Name

Enter the account name (login) provided by your ISP.

Password

Enter the password provided by your ISP (twice for verification).

Connectivity Check

Connectivity Check

Field Description

Connectivity Check

Connectivity checking is a functionality which periodically tests whether the network interface still has connectivity or not. This option cannot be disabled for Internet devices. If enabled, the AXS Guard appliance will periodically send ICMP (ping) messages to the specified IP address(es). System administrator(s) will be notified by e-mail if connectivity is lost. Timeout values can be configured under Network > Monitoring. Do not use master or slave IP addresses for network connectivity checks (also see High Availability > General ).

Use DNS Root Servers

If enabled, DNS root servers will be used to periodically check the connectivity of the selected Internet interface.

Connectivity Check IPs

Enter the IP address(es) to be used for connectivity checks. Do not use master or slave IP addresses for network connectivity checks (also see High Availability ▸ General ).

Virtual Local Area Networks (VLANs)

Definition

A Virtual Local Area Network (VLAN) device is an independent network interface, with its own configuration parameters and is used to add one or more segments to your network without the need to add an additional physical network interface.

A Virtual LAN device is always added to a physical LAN device, for instance eth0. VLAN devices use their own identifiers for communication, e.g. eth0.10. Some identifiers are reserved and should not be used.

Check the documentation of your network switch to verify if it supports VLANs.

Adding VLAN Devices

  1. Navigate to Network > Devices > Eth

  2. Select the device in the list to which the VLAN should be added, e.g. eth0

  3. Click on the Add Virtual LAN button (shown below).

  4. A VLAN device requires the same configuration parameters as an Ethernet device. Only the Virtual LAN identifier is VLAN-specific. Some VLAN identifiers are reserved and should not be used, e.g. eth0.0.

  5. After configuring the relevant settings, click on Save.

    Adding a Virtual LAN to an EthernetInterface

Field Description

Logical Device

The name of the VLAN device as known by the appliance, e.g. eth0.11

VLAN on Physical Device

The physical network device to which a VLAN device is added, e.g. eth0

Virtual LAN Identifier

A VLAN identifier is a unique number to identify a VLAN device in a network. Use a VLAN identifier equal or greater than 10, e.g. eth0.11. VLAN identifiers ranging from 0 to 9 are reserved by some manufacturers and could cause the VLAN to malfunction.

About VLAN Identifiers

A VLAN identifier is a unique number to identify a VLAN device in a network.

  • Always use a VLAN identifier equal or greater than 10, e.g. eth0.11. VLAN identifiers ranging from 0 to 9 are reserved by some manufacturers and could cause the VLAN to malfunction if used.

  • The logical device, e.g. eth0.11, is the name of the device as recognized by the AXS Guard Operating System.

VLAN Identifiers

Channel Bonding

Concepts

Channel bonding or Ethernet bonding is a computer networking arrangement in which two or more network interfaces on a host are combined for redundancy or increased throughput. Bonding allows you to effectively combine the bandwidth into a single connection or to create multi-gigabit pipes to transport traffic through the highest traffic areas of your network.

You can aggregate three megabits ports (1 mb each) into a three-megabits trunk port. That is equivalent to a single three megabits interface.

  • Provides redundant links

  • Fault tolerance

  • Load balancing

It is the best way to have a high availability network segment. A very useful way to use bonding is to use it in connection with 802.1q VLAN support (your network equipment must support the 802.1q protocol).

  • A given network device can only be added to a single bond device.

  • Only free network devices can be added to a bond device (not in use).

  • A bonding device can only be connected to another bonding device, i.e. all participants must have a bonding device, as illustrated below.

Ethernet Bonding

Bonding types Round robin Active backup XOR Balancing 802.3ad Balance TLB Balance ALB Adaptive Transmit Load Balancing Adaptive Load Balancing

Ethernet Bonding Types

The AXS Guard supports the following bonding types:

  • Round Robin: Packets are transmitted in a round robin fashion over the available slave interfaces. This type provides both load balancing and fault tolerance.

  • Active Backup: One slave interface is active at any time. If one interface fails, another interface takes over the MAC address and becomes the active interface. Provides fault tolerance only. Doesn’t require special switch support.

  • XOR Balancing: Tranmissions are balanced across the slave interfaces based on source MAC) XOR (dest MACsource MAC) XOR (dest MAC modula slave count. The same slave is selected for each destination MAC. Provides load balancing and fault tolerance.

  • Broadcast: Transmits everything on all slave interfaces. Provides fault tolerance.

  • 802.3ad: This is classic IEEE 802.3ad Dynamic link aggregation. This requires 802.3ad support in the switch and driver support for retrieving the speed and duplex of each slave.

  • Balance TLB: Adaptive Transmit Load Balancing. Incoming traffic is received on the active slave only, outgoing traffic is distributed according to the current load on each slave. Doesn’t require special switch support

  • Balance ALB: Adaptive Load Balancing — provides both transmit load balancing (TLB) and receive load balancing for IPv4 via ARP negotiation. Doesn’t require special switch support, but does require the ability to change the MAC address of a device while it is open.

Configuration

  1. Go to Devices > Eth.

  2. Select the appropriate logical device, e.g. bond0.

  3. Select the interface type (zone).

  4. Configure the connection settings, IP address(es) and connectivity check.

  5. Select the Bonding Settings tab to configure your bonding device.

  6. Update your configuration.

    Ethernet Bonding Configuration

Option / Field

Description

Bonding Type

  • Round Robin: Packets are transmitted in a round robin fashion over the available slave interfaces. This type provides both load balancing and fault tolerance.

  • Active Backup: One slave interface is active at any time. If one interface fails, another interface takes over the MAC address and becomes the active interface. Provides fault tolerance only. Doesn’t require special switch support.

  • XOR Balancing: Tranmissions are balanced across the slave interfaces based on source MAC) XOR (dest MAC modula slave count. The same slave is selected for each destination MAC. Provides load balancing and fault tolerance.

  • Broadcast: Transmits everything on all slave interfaces. Provides fault tolerance.

  • 802.3ad: This is classic IEEE 802.3ad Dynamic link aggregation. This requires 802.3ad support in the switch and driver support for retrieving the speed and duplex of each slave.

  • Balance TLB: Adaptive Transmit Load Balancing. Incoming traffic is received on the active slave only, outgoing traffic is distributed according to the current load on each slave. Doesn’t require special switch support

  • Balance ALB: Adaptive Load Balancing — provides both transmit load balancing (TLB) and receive load balancing for IPv4 via ARP negotiation. Doesn’t require special switch support, but does require the ability to change the MAC address of a device while it is open.

Physical Ethernet Ports

The Ethernet devices to be aggregated into the bond group, e.g. eth1, eth2, etc.

Updelay (in ms)

If a link has been brought up, the bonding interface is disabled for the duration specified in the updelay time and after this time it is enabled. The value should be a multiple of the MII-interval.

Downdelay (in ms)

if a link failure has been detected, the bonding interface is disabled for the duration specified in the downdelay time. This value should be a multiple of the MII-interval

Monitoring Interval (in ms)

Specifies the MII link monitoring frequency in milliseconds. This determines how often the link state of each slave is inspected for link failures. A value of zero disables MII link monitoring. A value of 100 is a good starting point.

Bond policy for load balancing

Select the appropriate policy from the drop-down list (this option is only available if supported by the selected bonding type).

  • Based on MAC addresses

  • Based on IP addresses and ports

Bridging

Concepts

It is sometimes useful to divide one physical network (such as an Ethernet segment) into two separate network segments without having to create IP subnets and use a router to connect the segments together. A device that connects two networks together in this fashion is called a “bridge”. If your appliance has two or more network interfaces, they can be configured as a bridge.

The bridge works by learning the MAC layer addresses (Ethernet addresses) of the devices on each of its network interfaces. It forwards traffic between two networks only when its source and destination are on different networks.

In many respects, a bridge is like an Ethernet switch with very few ports.

Bridging Concept

  • Connecting Networks: Joining two or more network segments together. There are many reasons to use a host-based bridge over plain networking equipment such as cabling constraints, firewalling and routing. A bridge can also connect a wireless interface running in hostap mode to a wired network and act as an access point.

  • Filtering/Traffic Shaping Firewall: A common situation is where firewall functionality is needed without routing or network address translation (NAT).

  • Network Tap: A bridge can be used to inspect all Ethernet frames that pass between the connected network segments. This can be achieved with a traffic analyzer such as tcpdump(1) or by sending a copy of all frames to an additional interface (span port).

  • Layer 2 Redundancy: A network can be connected together with multiple links and use the Spanning Tree Protocol to block redundant paths. For an Ethernet network to function properly, only one active path can exist between two devices. Spanning Tree will detect loops and put the redundant links into a blocked state. Should one of the active links fail then the protocol will calculate a different tree and reenable one of the blocked paths to restore connectivity to all points in the network.

The Spanning Tree Protocol

To prevent broadcast storms and other unwanted side effects of looping, Digital Equipment Corporation created the spanning tree protocol (STP), which has been standardized as the 802.1d specification by the Institute of Electrical and Electronic Engineers (IEEE).

Essentially, a spanning tree uses the spanning tree algorithm (STA), which senses that the switch has more than one way to communicate with a node, determines which way is best and blocks out the other path(s). It also keeps track of the other path(s), just in case the primary path is unavailable.

An in-depth explanation of STP is outside the scope of this guide. See the appropriate online resources for additional information and details.

Configuration

  1. Go to Devices > Eth.

  2. Select the appropriate logical device, e.g. br0.

  3. Select the interface type (zone).

  4. Configure the connection settings, IP address(es) and connectivity check.

  5. Configure your Bridge Settings and update your configuration.

    Bridge Settings

Parameter Description

Physical Ethernet device

The name of the Ethernet port that you want to add to the bridge. This is the name of the device as listed under Network > Devices > Eth, for example eth1.

Path cost

A path cost value is given to each port. The cost is typically based on a guideline established as part of the 802.1d standard. According to the original specification, cost is 1,000 Mbps (1 gigabit per second) divided by the bandwidth of the segment connected to the port. Therefore, a 10 Mbps connection would have a cost of (1,000/10) 100.

Port priority

The priority value is an unsigned 8-bit quantity (a number between 0 and 255). This metric is used in the designated port and root port selection algorithms.

Time a MAC is remembered in the forward tables (seconds)

The factory default value is 300.

Delay at boot before the bridge starts forwarding (seconds)

The factory default value is 15.

To compensate for the speed of networks increasing beyond the gigabit range, the standard cost has been slightly modified. The new cost values are:

Bandwidth STP Path Cost Value

4 Mbps

250

10 Mbps

100

16 Mbps

62

45 Mbps

39

100 Mbps

19

155 Mbps

14

622 Mbps

6

1 Gbps

4

10 Gbps

2

Parameter Definition

Enabled

Check to enable STP.

Bridge priority

The root bridge of the spanning tree is the bridge with the smallest (lowest) bridge ID. Each bridge has a configurable priority number and a MAC Address; the bridge ID contains both numbers combined together - Bridge priority + MAC (32768.0200.0000.1111). The priority value is an unsigned 16-bit quantity (a number between 0 and 65535). Lower priority values are better. The bridge with the lowest priority will be elected root bridge. The bridge priority default is 100.

Brige Hello Time

The hello time is the time between each bridge protocol data unit (BPDU) that is sent on a port. This time is equal to 2 seconds (sec) by default, but you can tune the time to be between 1 and 10 sec.

Bridge Max Age

The max age timer controls the maximum length of time that passes before a bridge port saves its configuration BPDU information. This time is 20 sec by default, but you can tune the time to be between 6 and 40 sec.

Firewall Settings

For the bridge to work, you must configure the AXS Guard firewall to allow traffic between the bridged interfaces. This is done by creating a "through" rule and adding it to the stat-sec firewall policy. For details about firewall rules and policies, see the AXS Guard Firewall How To, which is accessible via the Documentation button in the administration tool.

In the following example, we assume that you want to allow all traffic and that the name of the bridge device is br0. The name may be different on your appliance.

  1. Go to Firewall > Rules > Through

  2. Click on "Add new"

  3. Enter a name for the new rule, e.g. bridge

  4. Select your bridge device, e.g. br0 as Device in and Device Out

  5. Set the protocol to any

  6. Save the rule

    Creating a Through Rule for your Network Bridge

  7. Go to Firewall > Policies > Static

  8. Select the stat-sec policy.

  9. Click on "Add Firewall Rule"

  10. Select the newly created rule

  11. Update your configuration

PSTN Devices

Why PSTN devices are used

PSTN devices are used for:

  • communication with an uninterruptible power supply (UPS)

  • the AXS Guard Fax module

PSTN Configuration

  1. Navigate to Network > Devices > PSTN

  2. Click on a logical device in the list. A screen similar to the image below appears.

  3. Configure the general and interface type settings as explained in the table below.

  4. Click on Update.

    Modify PSTN Device

Field

Description

Physical Device

The name of the serial device as seen by the appliance’s operating system, e.g. ttyS0.

Description

Enter a description for the device (optional).

Interface Type

  • Not in use: select this option to disable the device.

  • UPS: An APC Smart UPS can be connected to gracefully shut down the appliance if the battery of the UPS is nearly depleted. The PSTN interface is used for communication with the UPS and needs to be selected when you configure a UPS under System > UPS.

  • Fax: A modem can be connected to the appliance to handle outgoing and incoming faxes. The fax option can only be enabled by VASCO personnel.

  • Heartbeat: Select this option if your HA cluster uses heartbeat communications (recommended). See the High Availability manual for additional information.

Network Tools

Ping

Ping is a computer network administration software utility used to test the reachability of a host on an Internet Protocol (IP) network.

  1. Navigate to Network > Tools > Ping.

  2. Enter an IP address or hostname to ping.

  3. Enter the amount of pings to execute.

  4. Press the Ping button.

    Ping Tool

Traceroute

Traceroute is a computer network tool for measuring the route path and transit times of packets across an Internet Protocol (IP) network.

  1. Navigate to Network > Tools > Traceroute.

  2. Enter an IP address or hostname.

  3. Press the Traceroute button.

    Traceroute

Subnet Calculator

The subnet calculator takes an IP address and netmask (CIDR) and calculates the resulting broadcast, network and host range. It is also intended to be a teaching tool and presents the subnetting results.

  1. Navigate to Network > Tools

  2. Select the subnet calculator tool

  3. Enter the IP address and subnet using the CIDR notation, e.g. 10.20.30.40/24 or 10.20.30.40/255.255.255.0

  4. Click on calculate for the results.

    Subnet Calculator

Flow Viewer

The flow viewer allows you to view active connections and use filters to extract information based on the:

  • Protocol

  • Source IP and port

  • Destination IP and port

  • Network device

  • Connections that are monitored by the application control system

Flow Viewer

Internet Speed Test

The speed test measures your Internet connection speed in Megabits Per Second, which is the ISP industry standard. Run this test to verify the connection speeds advertised by your ISP.

  1. Navigate to Network > Tools > Internet speed test.

  2. Click on the Start Speed Test button.

  3. Select the desired mode.

  4. Press the Start Speed Test button again.

    Internet Speed Test

Domain Name Server (DNS)

What is DNS?

The Domain Name System (DNS) is a distributed, hierarchical naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participants. An often used analogy to explain the Domain Name System is that it serves as the "phone book" for the Internet by translating human-friendly computer host names into IP addresses and vice versa.

The protocol used by DNS is an application protocol of the TCP/IP protocol suite. Requests for translations to this system use the UDP and TCP protocols on port 53.

Domain Concept

Domains group networked (sub)structures and use intuitive identifiers (domain suffixes, such as vasco.com). The substructures can either be sub-domains, computers, other hosts, e.g. routers and printers or even services (as illustrated below).

The use of domains (domain names) offers the following advantages:

  • Name Grouping: Names of individual hosts and services used within an organization can be grouped into a single domain (using the same domain suffix) for name to IP address mapping purposes and vice versa. For example, all computers (hosts) within Able have names ending in vasco.com, e.g. www.vasco.com, mail.vasco.com, etc.

  • Intuitive names: An IP address by itself doesn’t represent any characteristics of the host or service. The intuitive naming of a domain and its hosts identifies the purpose and characteristics of a host, such as the country of origin, the name of the company, the service provided by the host, etc. The following information can be deducted from the name mail.vasco.com:

    • The com suffix indicates that the server belongs to a company

    • Able is the name of the company which owns the server

    • mail indicates that the host is a mail server

  • More efficient and reliable name resolution: Without the name grouping concept, no hierarchical resolution of addresses would be possible, meaning all requests for domain name resolution would be directed to one physical place (a single root server on the Internet). This would not only slow down the entire name resolution process, but would also make the Internet less reliable, since there would be no redundant servers to take over if the single root server crashed. The domain concept allows domain names to pin-point a particular address of a host and the resolution of each part of the domain name occurs at different levels and is handled by different DNS (and DNS backup) servers. This distributed system thus improves the speed, reliability and efficiency of the Internet.

Fully Qualified Domain Names (FQDN)

Each host in a network has a Fully Qualified Domain Name (FQDN), which points to information about that host. This information may include the IP address(es), information about mail routing, etc. A Fully Qualified Domain Name is the human-readable name which includes a hostname and its associated domain name. For example, if you combine the hostname www and the domain name vasco.com, they form the following FQDN: www.vasco.com.

Unqualified Domain Names (UQDN)

UQDN Unqualified Domain Name

The Unqualified Domain Name or UQDN is the name of the host without the domain suffix. For example, www and mail are a UQDNs, vasco.com is the domain. Joined together they form the following FQDNs:

  • www.vasco.com

  • mail.vasco.com

Internal DNS Concepts

The AXS Guard appliance has an internal DNS service and a public DNS service. The internal DNS service, explained in this section, specifically serves the local network, i.e. the secure LAN and the DMZ. It also caches and forwards DNS requests. The public DNS server provides domain name resolution for hosts on the Internet.

The AXS Guard’s internal DNS automatically collects DNS records. The following information is collected by the AXS Guard’s internal DNS:

  • Names given to network devices, e.g. axsguard.

  • Names given to computers in the LAN.

  • SRV records to enable location of services outside of the standard record types supported in DNS.

  • General names, such as tool, login, logout.

Internal DNS Flow

The AXS Guard’s internal DNS flow is illustrated below.

AXS Guard Internal DNS Flow

Stage 1: Interrogating the DNS Cache

The DNS cache on the AXS Guard is where previous DNS lookups are temporarily stored and is the first place where host names are resolved. If the host name can be resolved by the AXS Guard’s DNS cache, i.e. if a response is immediately available, the response is returned without proceeding to stage 2.

Assume the DNS entry www.google.com is not present in the DNS cache. User 1 requests www.google.com. The AXS Guard performs a DNS lookup for www.google.com on the Internet. The result is returned to the user and stored in the DNS cache. User 2 also requests www.google.com. Since the entry for www.google.com is already present in the DNS cache, this entry is returned rather than performing a new lookup on the Internet. This process accelerates DNS lookups and saves Internet bandwidth.

Stage 2: Interrogating a DNS Server

If no record is available in the DNS cache, depending entirely on the host name to be resolved, the DNS request is handled by one of the following:

  • a) AXS Guard 's internal DNS: if the DNS request (e.g. host.vasco.com) is related to a host in the system domain as entered under System > General screen, the request is handled by the AXS Guard’s internal DNS.

AXS Guard System Domain

  • b) Forwarded DNS Server: if the DNS request is related to a host within a specific forwarded domain (not the system domain), the DNS query is forwarded to the specified server. DNS Forwarding is configured under Network > DNS > Forwarding. In the following example, all queries related to hosts of somedomain.com are forwarded to the DNS server with IP address 192.168.5.100.

AXS Guard DNS Forwarding

Only Advanced Administrators can add/modify DNS Forwarding settings.

  • c) Other DNS Server: if the DNS query is related to a host which cannot be resolved by the AXS Guard system domain DNS (a) or by forwarding the query to a specific DNS server (b), the query is forwarded to another DNS server.

    • If the AXS Guard is used only as an authentication appliance, the network DNS server is used.

    • If the AXS Guard is used as a corporate gateway, the ISP’s DNS servers are used.

DNS servers can be configured under Network > General. The configured DNS server(s) contact(s) other DNS servers as necessary until a response is obtained.

  • If no DNS servers are specified under Network > General, the DNS Root servers are used. This adversely affects the DNS lookup performance. Able therefore recommends that administrators specify DNS servers.

  • When the ISP name servers are unreachable or not responding, an error message will appear in the status overview under System > Status.

ISP Domain Name Server Fields

Field

Description

ISP Domain Name Server

The IP address(es) of your ISP’s DNS servers.

Include default AXS Guard NTP Time Servers

Many AXS Guard appliance security features such as log generation, backup & restore, certificate validation and two-factor authentication rely on accurate time. With an imprecise time, your connected devices may run into different kinds of errors and you also may encounter various troubleshooting burdens. AXS Guard NTP servers provide redundancy, which means clients and other devices connected to your network will always be able to get the correct time.

ISP NTP Time Server

The IP address or FQDN of a time server. ntp.vasco.com is the factory default time server. A correct system time is critical for time-sensitive processes, such as DIGIPASS authentication.

Primary Secure Device

Do not change this parameter unless absolutely necessary. eth0 is the factory default setting which is used by the following services:

  • The AXS Guard configuration tool (TCP port 82)

  • The AXS Guard proxy server (TCP port 3128)

  • DNS zone transfers (TCP port 53)

  • The synchronization of appliances in a High Availability configuration

Allow DNS zone transfers on secure LAN?

Check this option to allow DNS zone transfers from the appliance to a secondary DNS server in your LAN. Zone transfers allow DNS servers to synchronize their repositories.

  • Alias IP Address for Zone Transfers: Zone transfers on a secure LAN device require an alias IP address for that device. Go to Network > Eth and select the IP Settings tab to configure an alias for the primary secure LAN device. The secondary DNS server requests zone transfers from the alias IP address, rather than from the primary secure LAN IP address.

  • Secondary Name Servers: Enter the IP address(es) of the backup (secondary) DNS server(s) in your network. The IP address of the secondary DNS server must be registered under Computers for DNS Zone transfers to be successful.

Disable path-MTU discovery?

Check to disable path-MTU discovery for all connections on the appliance, which implicitly enables IP fragmentation for all of them.

Internal DNS Zone Transfers a.k.a. Secondary DNS

A backup DNS server, also known as a Secondary DNS server, handles DNS queries if the Primary DNS server is being rebooted or fails. Zone transfers enable the synchronization of data between the AXS Guard DNS server and secondary DNS servers in your LAN. When the DNS repository of the AXS Guard is updated, the repository of the secondary DNS server (and any additional configured DNS servers) is updated as well.

Examples of Internal DNS Setups

With Microsoft Active Directory Domain

DNS queries for the domain specified on the Active Directory (AD) Server are handled by the AD server, while queries for other domains are handled by the AXS Guard. The DNS queries for other domains are forwarded to the AXS Guard appliance by the AD server, hereby shielding the secure LAN. The setup is illustrated below.

Enter the IP addresses of your ISP’s DNS servers. This optimizes DNS queries on the Internet. If you don’t specify an IP address, the Internet Root Servers are used instead.

DNS Queries are Forwarded from Microsoft AD to AXS Guard

Without Microsoft Active Directory Domain

DNS queries for the domain specified on the AXS Guard appliance are handled by the AXS Guard, while requests for other domains are handled by the ISP’s DNS servers. The setup is illustrated below.

Enter the IP addresses of your ISP’s DNS servers. This optimizes DNS queries on the Internet. If you don’t specify an IP address, the Internet Root Servers are used instead.

DNS Requests Forwarded from AXS Guard to ISP

With a Secondary DNS Server (DNS Zone Transfers)

All DNS requests are forwarded to the AXS Guard appliance, which is the Primary DNS server. The DNS zones are transferred to a secondary (backup) DNS server. The backup DNS server temporarily handles all DNS queries if the AXS Guard appliance is rebooted for maintenance. This setup is illustrated below.

Enter the IP addresses of your ISP’s DNS servers. This optimizes DNS queries on the Internet. If you don’t specify an IP address, the Internet Root Servers are used instead.

AXS Guard with Secondary DNS Server (DNS Zone Transfers)

Without a Secondary DNS in your network, internal DNS services are temporarily unavailable, i.e. during the maintenance of your AXS Guard appliance, while the system is down or being rebooted.

AXS Guard as an Authentication Server with Active Directory DNS

DNS queries for the corporate domain are handled by the Active Directory (AD) Server. The DNS queries for other domains are forwarded to the ISP’s DNS server by the Active Directory server. In the example below, the AXS Guard appliance is set up as a standalone authentication appliance.

Enter the IP addresses of your ISP’s DNS servers. This optimizes DNS queries on the Internet. If you don’t specify an IP address, the Internet Root Servers are used instead.

AXS Guard as a Standalone Authentication Appliance

Forwarding DNS Queries

  1. Go to Network > DNS > Forwarding.

  2. Configure the settings as explained in the table below).

  3. Click on Save to finish.

    Network > DNS > Forwarding > Add Forwarding DNS Service

Field Description

Forward Requests for Domain

The domain for which DNS queries should be forwarded.

Description

A description (optional field).

Enabled

Check to enable forwarding for the specified domain.

Forward to DNS server(s)

The IP address(es) of the DNS server(s) to which queries for the specified domain must be forwarded.

Public DNS

The public DNS server provides domain name resolution for hosts on the Internet. For more information on the use and configuration of the AXS Guard’s public DNS server, see the AXS Guard Public DNS How To, which can be downloaded via the Documentation button in the configuration tool.

Dynamic DNS

With Dynamic DNS, you can assign a static hostname to an appliance with a dynamic IP address. This facilitates remote access, e.g. VPN users just have to remember a user-friendly name, rather than a dynamic IP or a variable hostname to connect.

To use this feature, you must register with a supported Dynamic DNS provider and activate the feature.

  1. Log on to the Administrator Tool.

  2. Navigate to System > Feature Activation.

  3. Expand Network and check the Dynamic DNS option as shown in the image below.

  4. Click on Update.

    DynDNS Feature Activation

  5. Navigate to Network > DNS > Dynamic DNS

  6. Enter the account settings received from your Dynamic DNS provider.

  7. Select the appropriate Internet device (in case your appliance has 2 or more Internet devices).

  8. Select your DNS provider from the list.

  9. Click on Update to finish.

Dynamic DNS Configuration

Parameter Description

Name registered with DNS Provider

The full name, including the domain, as registered with your Dynamic DNS Provider, e.g. nameofmyhost.dyndns.org.

Username

The username of your Dynamic DNS account.

Password

The password of your Dynamic DNS account.

Internet device

The Internet device that will be handling traffic for the domain, e.g. eth1. Go to Network > Devices > Eth for an overview of Internet devices configured on your system.

Provider

Select the appropriate Dynamic DNS provider from the drop-down list.

DHCP

What is DHCP?

The Dynamic Host Configuration Protocol (DHCP) is an application protocol that enables your appliance to dynamically assign IP addresses to computers and other devices in its network.

DHCP simplifies network administration because software automatically keeps track of IP addresses so that administrators don’t have to. Many Internet Service Providers (ISPs) use DHCP to assign IP addresses to their clients.

A DHCP lease is the amount of time during which the DHCP client may use an assigned IP address. The AXS Guard DHCP server allows you to configure the lease time.

Data received from the DHCP Server

A computer connecting to the network receives the following parameters from the AXS Guard DHCP server:

  • an Internet Protocol (IP) address

  • a default gateway address

  • one or more Domain Name Server (DNS) address(es)

  • a Windows Internet Name Server (WINS) address, if present in your network

  • a Network Time Protocol (NTP) server address

Address Pools

An address pool or DHCP range is a range of valid IP addresses made available for assignment to clients in a particular subnet. Address pools are configured on the AXS Guard DHCP server. IP addresses from this pool are then offered by the AXS Guard to DHCP clients.

Addresses are offered by an AXS Guard network interface. This can be a DMZ or a secure LAN interface.

The AXS Guard also allows you to reserve IP addresses for dedicated hosts, e.g. dedicated servers and printers. Such leases are referred to as static leases.

Attempts to create invalid pools will generate a validation message.

Static Leases

Use static IP addresses rather than static DHCP leases for the Windows Servers in your network. Windows Servers may malfunction if the AXS Guard’s DHCP lease settings are changed.

With a static DHCP lease, the AXS Guard’s DHCP server always assigns the same IP address to a specific host in the LAN. Static DHCP leases allow:

  • Automatic assignment of static IP addresses to servers and central management of the IP addresses.

  • Settings which are defined in the configured DHCP range (e.g. DNS servers) can be overruled. This is required for certain programs to function properly.

Authoritative vs. Not Authoritative

The DHCP server will normally assume that the configuration information about a given network segment is not known to be correct and is not authoritative. This is so that if a naive user installs a DHCP server not fully understanding how to configure it, it does not send spurious DHCPNAK messages to clients that have obtained addresses from a legitimate DHCP server on the network.

Network administrators setting up authoritative DHCP servers for their networks should always enable the authoritative option to indicate that the DHCP server should send DHCPNAK messages to misconfigured clients. If this is not done, clients will be unable to get a correct IP address after changing subnets until their old lease has expired, which could take quite a long time.

PXE Options

If you’re looking to perform a lot of system recovery or network system installations, then network booting with PXE is ideal. PXE allows you to boot up a system and have it automatically get an IP address via DHCP and start booting a kernel over the network.

PXE itself stands for "Pre-boot eXecution Environment", which describes how it works in the sense that the clients using it do not boot in a traditional manner.

In order to use PXE, you need to setup a boot server which will allow client systems to:

  • Request an IP address (via DHCP)

  • Download a kernel (via TFTP or next-server)

With both of these services in place, any system which supports PXE/network-booting (you might need to enable it in the BIOS) should be able to get an IP address, fetch a kernel, and boot without an installed operating system. This is ideal for systems which can’t be booted using a traditional approach, e.g. VoIP phones.

DHCP Relay Agents

A relay agent is a small program that relays DHCP/BOOTP messages between clients and servers on different subnets. DHCP/BOOTP relay agents are part of the DHCP and BOOTP standards and function according to the Request for Comments (RFCs), standard documents that describe protocol design and related behavior.

The AXS Guard appliance can be configured to allow incoming DHCP requests from a DHCP relay agent.

DHCP Relay Agent Flow

  1. The DHCP client broadcasts a DHCP/BOOTP discover message (DHCPDISCOVER).

  2. The DHCP relay agent, in this case a DHCP/BOOTP relay-enabled router, examines the gateway IP address field in the DHCP/BOOTP message header. If the field has an IP address of 0.0.0.0, the agent fills it with the relay agent or router’s IP address and forwards the message to the AXS Guard DHCP server.

  3. When the AXS Guard DHCP server receives the DHCPDISCOVER message, it processes and sends an IP address lease offer (DHCPOFFER) directly to the relay agent.

  4. The router with the DHCP relay agent then relays the address lease offer (DHCPOFFER) to the DHCP client.

DHCP Server Configuration

Enabling DHCP

Important

Using multiple DHCP servers in a subnet causes conflicts.

  1. Navigate to System > Feature Activation > Network

  2. Check the option to use the DHCP Server (see the image below)

  3. Click on Update to finish

    image

Adding an Address Pool
  1. Navigate to Network > DHCP > Address Pools

  2. Click on the Add New button to add a DHCP pool to a network device (Secure LAN or DMZ).

  3. Configure the options as explained in the tables below .

  4. Click on Save to finish.

    Adding an Address Pool

Address Pool Settings
Field Description

Name

Enter a name for the IP range, e.g. LAN.

First IP in range

The first IP address to be issued in the DHCP range, e.g. 192.168.1.50. The AXS Guard DHCP server stores the MAC addresses of each DHCP lease and attempts to preserve IP / MAC address combinations. This means that clients usually obtain the same IP address (DHCP lease), for instance after a reboot. Only use IP addresses in the same ranges as your DMZ or LAN devices.

Last IP in range

The last IP address to be issued in the DHCP range, e.g. 192.168.1.150.

Subnet device

The network device that issues IP addresses to clients. Go to Network > Devices > Eth for an overview of network devices on your system.

Netmask

The subnet mask to be assigned to clients, e.g. 255.255.255.0

Info

Static leases are excluded from configured DHCP ranges.

DHCP Settings

DHCP Settings Tab

Field Description

Authoritative

If disabled, misconfigured clients which connect to another AXS Guard subnet will be unable to get a new IP address until their old DHCP lease has expired, which may be quite a long time. If enabled, the DHCP server should send DHCPNAK messages to misconfigured clients, which will receive a new IP address without delays. See http://linux.die.net/man/5/dhcpd.conf for additional information.

Gateways

The FQDN or the IP address of the default gateway in your network, e.g.192.168.1.254.

Domain Name Servers

The primary DNS server to be used by your clients. Multiple DNS servers can be added.

Time Servers

The FQDN or the IP address of a Time Server, e.g. ntp.vasco.com. Multiple Time Servers can be added. This parameter is critical for time-sensitive processes, such as DIGIPASS authentication.

WINS

The IP address(es) of (a) WINS server(s) in your network. WINS (Windows Internet Name Server) is Microsoft’s implementation of the NetBIOS Name Service (NBNS), a name server and service for NetBIOS computer names. WINS is to NetBIOS names what DNS is to domain names, a central mapping of host names to network addresses.

High Threshold

Determines the percentage of available leases to be used prior to sending a system notification. When the threshold is reached, a system warning will be shown on the dashboard and the administrator will be notified by email. Setting the percentage to 0 disables notifications.

Low Threshold

If the amount of used leases drops below this threshold, the dashboard system warning message will disappear.

Lease time

The maximum duration of DHCP leases. When expired, clients must renew their lease.

DHCP Settings Tab

Network Boot Settings

Network Boot Settings

Field Description

TFTP Server

IP address of a TFTP server to support network booting (PXE), e.g. for VoIP phones or OS installations.

Next Server

IP address of a Next server to support network booting (PXE), e.g. for VoIP phones or OS installations.

Boot file

Name of the file to be loaded by clients when booting from the network.

Non-Standard and Vendor-specific DHCP Options

These options are to be used if certain DHCP hardware or software clients in your network expect DHCP options that are not available otherwise. Consult the documentation of your hardware or software clients to know the values that are expected for each option.

The following values are accepted:

  • an IP address

  • text (string)

  • a hexadecimal value

  • a domain name

A list of standard DHCP options can be found here.

RFC2132 provides a list of the most frequently used DHCP options.

DHCP Options Tab

Example: Vendor-specific options to create a PXE boot menu

Vendor-specific numbered option:

  • Number = 6

  • Description = multicast

  • Value type = text

  • Value = 7

Value 7 means: use PXE_BOOT_SERVERS list + disable multicast and broadcast discovery.

  • Number = 8

  • Description = Boot servers

  • Value type = hex

  • Value = 80:F0:01:C0:A8:01:04:80:F1:01:C0:A8:01:05

Option 8 defines the two PXE servers. The first server is defined by the first 7 bytes, starting with the OS deployment server type (80:F0,33008), followed by one IP address: C0:A8:01:04 (192.168.1.4). The second server is defined in the following manner, using OS deployment server type 80:F1 (33009).

  • Number = 9

  • Description = boot menu

  • Value type = hex

  • Value = 80:F0:08:53:65:72:76:65:82:20:41:80:F1:08:53:65:72:76:65:82:20:42

Option 9 defines the boot menu that is displayed at boot time. The first 11 bytes correspond to the first line, for the first server. It shows the string Server A, associated with type 80:F0 (first server). The second line shows the string Server B, associated with type 80:F1 (second server).

  • Number = 10

  • Description = timeout+prompt

  • Value type = hex

  • Value = 0F:53:65:6C:65:63:74

Option 10 specifies a 15 second timeout and shows the string "Select" as the boot menu prompt.

Additional IP Ranges

Additional IP Ranges

Field Description

First IP address in range

Enter the first IP address of the additional range, e.g. 192.168.1.160. Use an IP address in the same subnet as specified in the general DHCP configuration.

Last IP address in range

Enter the last IP address of the additional range, e.g. 192.168.1.170. Use an IP address in the same subnet as specified in the general DHCP configuration.

Field Description

Authoritative

If disabled, misconfigured clients which connect to another AXS Guard subnet will be unable to get a new IP address until their old DHCP lease has expired, which may be quite a long time. If enabled, the DHCP server should send DHCPNAK messages to misconfigured clients, which will receive a new IP address without delays. See http://linux.die.net/man/5/dhcpd.conf for additional information.

Gateways

The FQDN or the IP address of the default gateway in your network, e.g.192.168.1.254.

Domain Name Servers

The primary DNS server to be used by your clients. Multiple DNS servers can be added.

Time Servers

The FQDN or the IP address of a Time Server, e.g. ntp.vasco.com. Multiple Time Servers can be added. This parameter is critical for time-sensitive processes, such as DIGIPASS authentication.

WINS

The IP address(es) of (a) WINS server(s) in your network. WINS (Windows Internet Name Server) is Microsoft’s implementation of the NetBIOS Name Service (NBNS), a name server and service for NetBIOS computer names. WINS is to NetBIOS names what DNS is to domain names, a central mapping of host names to network addresses.

High Threshold

Determines the percentage of available leases to be used prior to sending a system notification. When the threshold is reached, a system warning will be shown on the dashboard and the administrator will be notified by email. Setting the percentage to 0 disables notifications.

Low Threshold

If the amount of used leases drops below this threshold, the dashboard system warning message will disappear.

Lease time

The maximum duration of DHCP leases. When expired, clients must renew their lease.

DHCP Relay Settings

Relay Settings

Field Description

Allow relayed requests

Check to allow relayed requests from a DHCP agent.

Accept requests on interface

Accept relayed DHCP requests on the specified interface.

Static Leases

  1. Navigate to Network > DHCP > Static Leases. A list of the hosts with static leases is shown.

  2. Click on the Add New button to add a new lease or click on a name to modify an existing static lease.

  3. Configure the settings as explained in the table below.

  4. Click on Save to finish.

    Adding a Static DHCP Lease

Field Description

Name

Enter the name of the host to be assigned a static lease.

Description

Description of the host (optional), e.g. file server 1.

Hardware Address

The host’s MAC address, for instance 00:12:d8:60:90:48.

IP Address

The IP address to be assigned to the host, e.g. 192.168.1.225.

Field Description

TFTP Server

IP address of a TFTP server to support network booting (PXE), e.g. for VoIP phones or OS installations.

Next Server

IP address of a Next server to support network booting (PXE), e.g. for VoIP phones or OS installations.

Boot file

Name of the file to be loaded by clients when booting from the network.

Non-Standard and Vendor-specific DHCP Options

These options are to be used if certain DHCP hardware or software clients in your network expect DHCP options that are not available otherwise. Consult the documentation of your hardware or software clients to know the values that are expected for each option.

The following values are accepted:

  • an IP address

  • text (string)

  • a hexadecimal value

  • a domain name

A list of standard DHCP options can be found here.

RFC2132 provides a list of the most frequently used DHCP options.

Used Leases

Navigate to Network > DHCP Server > Used Leases. The fields are explained in the table below.

Field Description

IP

The IP address which has been assigned within a specified IP range.

MAC

The MAC address of the client that received (or currently has) a dynamically assigned IP address.

Hostname

The hostname of the DHCP client.

Expires

Indicates when the DHCP lease expires.

Actions

Clicking on the Make Static link converts the current lease to a static lease. Clicking on Edit Static allows you to modify the configuration of the new static lease.

Info

Clients with a static DHCP lease are not listed.

DHCP Logs

  1. Go to Network > DHCP > Logs.

  2. Click on the appropriate log file to view the DHCP logs.

Routing

What is Routing?

Routing is the decision process by which packets are moved from one network to another. Entries in routing tables specify the interface or gateway through which a packet must leave a network to reach another.

Routing tables are processed from the top entry down to the final entry. Whether an IP packet can be sent directly to its destination (communicating with a computer in the same LAN or subnet) or needs to be sent to the computer’s default gateway (attempting to communicate with a computer in another network segment or subnet) is first checked by the sending host. The AXS Guard uses the same principle to send and receive network packets.

Routing Table Entries

The main information recorded in a routing table is explained below.

  • Destination: This is the destination network of a packet. The destination is required to match the packet with an entry in the routing table, for instance 192.168.3.0.

  • Netmask: This entry, for instance 255.255.255.0, is checked against the destination entries in the routing table. Netmasking is defined per RFC 950.

  • Gateway: This entry designates a specific host (by its IP address) to which packets should be forwarded if the destination address cannot be reached directly by the AXS Guard.

  • Interface / Device: This field specifies the network interface through which a packet destined for a specific network - which can be reached directly by the AXS Guard - must be sent, e.g. eth0.

Default Gateway

Arriving network packets always traverse the routing table. If the destination network is within reach of one of the AXS Guard network interfaces (i.e. it is a subnet of the AXS Guard), routing entries are automatically added by the AXS Guard and the packets are delivered.

If the destination network cannot be reached directly by the AXS Guard (i.e. it is not a subnet of the AXS Guard), the routing system looks for a matching entry in the routing table. If a matching entry is found in the routing table, the network packets are delivered to the specified gateway for the destination network. If no matching entry is found for the destination network, the network packets are delivered to the default gateway. The routing system discards packets if no gateway or default gateway is specified in the routing table. In this case, a message is generated notifying the sending application that the destination network is unreachable, e.g. if pinging a host which is unreachable.

Most systems using TCP/IP have a routing table entry in which the default gateway is specified.

How Routing Works

What follows is a simple, yet straightforward example of how routing works.

Case Destination Netmask Gateway Network Interface

1

192.168.1.1

255.255.255.0

*

eth0

1

192.168.2.50

255.255.255.0

*

eth1

2

192.168.3.50

255.255.255.0

192.168.2.2

eth1

3

Default GW

0.0.0.0

213.49.50.75

eth2

Example of basic Routing Table Entries

Case 1

If the network packet is destined for a network which can be reached directly by the AXS Guard (i.e. for a subnet of the AXS Guard), the packet is immediately delivered to this network, e.g. a packet traveling from 192.168.1.50 towards 192.168.2.50 (see the image below).

Case 2

If the network packet is destined for a network which cannot be reached directly by the AXS Guard, the packet is sent to the gateway of this network, if specified in the routing table, e.g. a packet traveling from 192.168.1.50 towards 192.168.3.50 (see the image below).

Case 3

If there is no specific gateway routing entry in the routing table for the destination network, the packet is sent to the default gateway, for instance a packet traveling from 192.168.1.50 towards www.vasco.com (see the image below).

Routing Concepts

Adding Routes

  1. Navigate to Network > Routing.

  2. Click on the Add New button. A screen similar to the image below is displayed.

  3. Configure the settings as explained in the table below.

  4. Click on Save to finish.

    Adding a Route on the AXS Guard Appliance

Field

Description

Name

Enter an identifier for the route, using only lower cases without spaces, starting with an alphabetic character followed by any number of alphanumeric characters and/or the special characters: back slash \, hyphen -, underscore _, full stop ., and the @ symbol, e.g. some_network.

Description

A description for the route (optional), e.g. Route To Some_Network.

Enabled

Check to enable the defined route.

Network

Enter the destination network, using the CIDR notation, e.g. 192.168.3.0/24. The following notation is also accepted: 192.168.3.0/255.255.255.0.

Destination

  • Gateway IP: Enter the IP address of the nearest router or gateway on the local network segment.

  • Device: Select the network device from the drop-down list through which traffic must be routed , e.g. eth1. The appliance will automatically assign a device if none is selected. Go to Network > Devices > Eth for an overview of network devices on your system.

  • eTunnel: Routes traffic over the selected eTunnel (IPsec VPN) device. See the IPsec How To for additional information. The order determines the routing priority. 0 is the highest priority and the factory default value.

Consulting the Route Table

When a route has been added to the AXS Guard’s route table and enabled, it can be viewed. To view the main routing table:

Navigate to Network > Status > Route Table.

Main Routing Table

In this section we have described the main routing table. Other routing tables exist, but are outside the scope of this guide.

Network Address Translation

NAT only needs to be configured if the AXS Guard is used as a router or a gateway. If you are using the AXS Guard solely as an authentication appliance, configuring NAT is not necessary and this section may be skipped.

What is NAT?

While network packets travel from a source to a destination, routers which use NAT (Network Address Translation) alter the source or destination headers of the IP packets. If the UDP or TCP protocol is used, the source or destination port can also be altered.

Five NAT types can be configured on the AXS Guard. The types are defined based on the altered header information:

  • Masquerading

  • SNAT (Source Network Address Translation)

  • Port Forwarding

  • DNAT (Destination Network Address Translation)

  • Port Redirection

Masquerading

How Masquerading Works

IP Masquerading, also called IPMASQ or MASQ, allows computers in your network to communicate with the Internet using the IP address of your appliance (the IPMASQ server). The IPMASQ server acts as a gateway and the other devices are invisible behind it. So to other machines on the Internet, the outgoing traffic appears to be coming from the IPMASQ server and not the internal PCs.

In addition to masquerading a packet’s source IP address, the AXS Guard also automatically masquerades source ports, if a port is already in use. The automatic mapping mechanism on the AXS Guard stores the data accordingly so that reply packets are correctly handled (demasqueraded).

Info

Port numbers are assigned based on those which are already in use. The range of available port numbers is pre-configured on the AXS Guard and cannot be changed.

Masquerading Concept

The illustration above shows that all computers in the LAN connect to the Internet via the same AXS Guard Internet connection. The computers in the LAN have a private IP address in the 192.168.1.0/24 segment.

PC1 sends a packet to the outside world (the Internet). The source IP address of this packet is 192.168.1.10, which is an IP address in the private range. Since IP addresses in the private range cannot be routed on the Internet, the Private IP address is masqueraded to the public IP address of the AXS Guard, 62.58.227.146, so that a response can be given by the receiving computer.

Receiving computers reply to 62.58.227.146, which is the AXS Guard. Once the answer is received by the AXS Guard ,the address is rewritten (demasquerading) to 192.168.1.10, which is the address of the sending host.

In the illustration above, we assume that the PC with IP 192.168.1.10/24 makes a connection with an external Web server using source port 2000, which is chosen randomly. The source IP address is 192.168.1.10 and the destination is port 80 (i.e. a connection to a Web server). The AXS Guard masquerades the private source IP address with its Internet interface IP address, which is 62.58.227.146. The source port remains unchanged. The Web server identifies an incoming connection from source IP address 62.58.227.146, with source port 2000 and responds accordingly. When the response is received, the AXS Guard automatically rewrites (demasquerades) the reply packet so that it contains the private source IP address of PC1, i.e. 192.168.1.10, leaving the port (2000) unchanged.

Assume that another PC in the same network simultaneously connects to the same Web server and also uses source port 2000. The AXS Guard identifies an incoming packet with source IP address 192.168.1.20, using port 2000. Since port 2000 is already in use for PC1, both the source IP address and port number need to be automatically masqueraded to allow demasquerading.

Packets sent by the other PC are therefore masqueraded by the AXS Guard to source IP address 62.58.227.146, using a different source port, e.g. source port 2500. The automatic mapping mechanism on the AXS Guard stores the data accordingly so that reply packets are correctly handled (demasqueraded).

Pre-defined Masquerading

Important

When using IP addresses in the private range for hosts in the DMZ, Masquerading rules must be configured on the AXS Guard to enable traffic from the DMZ towards the Internet.

The AXS Guard applies pre-defined masquerading in the following order by default:

In Interface Out Interface Masquerading applied?

DMZ

Internet

No

Secure LAN

DMZ

Yes

Secure LAN

Internet

Yes

Predefined Masquerading Rules

If none of the above combinations match, the packet is either:

  • not masqueraded

  • blocked by the firewall

From To Action

LAN

LAN

ACCEPT

LAN

DMZ

MASQ

LAN

Internet

MASQ

DMZ

LAN

DROP

DMZ

DMZ

ACCEPT

DMZ

Internet

ACCEPT only if DMZ has public IP

Internet

LAN

DROP

Internet

DMZ

ACCEPT

Internet

Internet

DROP

In some situations, the predefined masquerading rules do not suffice. If IP addresses in the private range are used for hosts in the DMZ. packets sent from the DMZ to the Internet are discarded if no masquerading is applied. IP addresses in the private range cannot be routed on the Internet. The problem can be solved by adding an explicit masquerade rule for subnets in the DMZ.

Exception to Predefined Masquerading Rules

Assume that your DMZ falls in the following private range: 10.0.0.0/24.

Packets sent to the Internet from the DMZ are not masqueraded by default, e.g. packets originating from the server with IP 10.0.0.4/24. If masquerading is not applied to the 10.0.0.0/24 network, all packets sent to the Internet will be discarded.

Creating Masquerading Rules
  1. Navigate to Network > NAT > Masquerading

  2. Click on the Add New button.

  3. Configure the settings as explained in the table below.

  4. Click on Save to finish.

    Creating Rules for Masquerading

Field Description

Name

Enter an identifier for the rule, using only lower cases without spaces, starting with an alphabetic character, followed by any number of alphanumeric characters and/or the special characters: back slash \, hyphen -, underscore _, full stop . and the @ symbol, e.g. internet_access_for_dmz.

Description

Enter a description for the rule, e.g. Access to the Internet from DMZ 10.0.0.0/24. This field is optional.

Enabled

Check to enable the rule.

Source IP

The IP range to be masqueraded. Use the CIDR notation, e.g. 10.0.0.0/24. If left blank, the rule is applied to all source IP addresses.

Destination IP

Enter an IP or subnet to restrict matching to specific destination(s). Use the CIDR notation to specify a subnet. If left blank, the rule applies to any destination IP.

Device In

The device that receives traffic to be masqueraded.

Device Out

The device that forwards the NATed traffic to other networks.

Target

Select the action for matching traffic. "Accept" means that matching traffic should not be MASQed. Select "MASQ" to apply masquerading.

Source Network Address Translation

How SNAT Works

Source Network Address Translation (SNAT) is a type of NAT that changes the source IP address of packets. Unlike masquerading, the public IP address is not looked up for new connections.

The public source IP must be static for all future connections; SNAT cannot be used with dynamically assigned public IP addresses. Similar to masquerading, the reverse “de-SNAT” process is automatic.

Creating SNAT Rules
  1. Navigate to Network > NAT > SNAT/DNAT.

  2. Click on the Add New button.

  3. Configure the settings as explained in the table below.

  4. Click on Save to finish.

    Adding SNAT Rules

Field

Description

Name

Enter an identifier for the rule, using only lower case without spaces, starting with an alphabetic character, followed by any number of alphanumeric characters and/or the special characters: back slash \, hyphen -, underscore _, full stop . and the @ symbol, e.g. internet_access_for_dmz.

Description

Enter a description for the rule, e.g. Access to the Internet from DMZ 10.0.0.0/24. This field is optional.

Enabled

Check to enable the rule.

Action

  • Source address translation: Select this option for SNAT.

  • Destination address translation: Select this option for DNAT.

  • Don’t translate: Does not perform NAT on matching traffic.

Source address translation-specific settings

  • Coming from IP or network: Enter the Source IP or network range to be translated. Use the CIDR notation to specify a range, e.g. 10.0.0.0/24.

  • Translate to IP: Enter the IP address to which the specified source IP or range must be translated, e.g. 200.210.0.1.

  • Going to IP or network: If an IP or IP range is specified, SNAT is only applied when packets are being sent to the specified IP or network. Use the CIDR notation to specify a network. If this field is left empty, the SNAT rule is always applied.

  • Going through device: The device via which the packets to be translated are leaving the appliance, e.g. eth1 – Internet.

Destination address translation-specific settings

  • Arriving at IP or network: The IP address or IP range which receives the traffic to be forwarded, e.g. 200.210.0.1. Use the CIDR notation to specify a range.

  • Translate to IP: The IP address or IP range to which traffic must be forwarded. Use the CIDR notation to specify a range.

  • coming from IP or network: Only traffic coming from the specified source is translated. If no source is specified, any source is assumed.

  • coming through device: The device by which traffic to be forwarded is received, e.g. eth1 - Internet.

Don’t translate options

See the options explained above.

Important

  • Sometimes you may need a one-to-one NAT of a network range. For example, you have the 192.168.1.0/24 network and you would like to NAT each IP to its equivalent in 192.168.2.0/24 (SNAT) or vice versa (DNAT) when the packet travels through the NAT device. Make sure the subnets do not overlap each other.
  • Select Don't Translate in the Action field if you wish to define exceptions.

Port Forwarding

Port Forwarding Principle

Port forwarding is a type of NAT that is used to change the destination IP address and/or the destination port of network traffic.

image

Port forwarding can be used to forward incoming traffic on the AXS Guard to a server in the DMZ (configured with a private IP address). Whenever a connection is made from the Internet to the Internet IP address of the AXS Guard, the connection can be forwarded to a server in the DMZ listening on a different port.

Based on the image above, a connection to 200.210.0.1 on port 800, is forwarded to 10.0.0.2 on port 806. The server receives the packet and sends a reply packet with its private IP address. To avoid this packet being dropped immediately on the Internet as it leaves the LAN, the private IP address is automatically translated to the public IP address of the AXS Guard i.e. 200.210.0.1; thus De-NAT is automatic with port forwarding.

In this example, private IP addresses are used in the DMZ. It is also possible to use public IP addresses for servers in the DMZ. In that case no Port Forwarding is required.

For web servers, it is recommended to use the AXS Guard Reverse Proxy feature. This is an application firewall which services the requests of Internet clients by forwarding them to the appropriate servers in the LAN, while providing access control, auditing and content monitoring, which cannot be accomplished with a DMZ setup. For more information, please refer to the AXS Guard Reverse Proxy How To, available via the Documentation button.

Port forwarding can be used to forward incoming traffic on the AXS Guard to a PPTP or IPsec VPN server in your DMZ or secure LAN. PPTP uses a control channel over TCP and a GRE tunnel to encapsulate PPP packets. You can forward this PPTP traffic by selecting GRE as the protocol type in the port forwarding rule. To forward traffic to an IPsec VPN appliance in your LAN or DMZ, select ESP as the protocol type. For details about IPsec and the ESP protocol, see the AXS Guard IPsec How To, which can be accessed via the Documentation button in the Administrator tool.

  1. Navigate to Network > NAT > Port Forwarding.

  2. Click the Add New button.

  3. Configure the settings as described in the table below.

  4. Click on Save to finish.

    Adding Port Forwarding Rules

Field Description

Name

Enter an identifier for the rule, using only lower cases without spaces, starting with an alphabetic character, followed by any number of alphanumeric characters and/or the special characters: back slash \, hyphen -, underscore _, full stop . and the @ symbol, e.g. fwd_to_dmz_webserver.

Description

Describe the purpose of the port forwarding rule (optional field).

Enabled

Check to enable this rule.

Source IP/Net

Restricts forwarding from the specified source IP address or subnet. Use the CIDR notation to specify a subnet. If left empty, traffic coming from any source IP will be forwarded.

Protocol

Select the appropriate protocol from the drop-down list. The following protocols are supported: TCP, UDP, GRE and ESP.

Entering via Device

The network device or network zone that receives the traffic to be forwarded, i.e. the receiving end of the connection.

Coming to IP address

The IP address that receives the traffic to be forwarded.

Port

The port number or range on the receiving end. Use the x:x format to specify a port range, e.g. 1000:1024.

Destination IP

The IP address of the host to which traffic must be forwarded. Only one IP may be specified.

Destination Port

Forwards traffic to the specified port. This is optional and only relevant for UDP or TCP traffic.

Destination Network Address Translation

Able recommends the use of Port Forwarding rather than DNAT, as it provides control over the specific ports to be forwarded. Forwarding all ports constitutes a serious security risk.

How DNAT Works

Destination Network Address Translation (DNAT) is a special case of port forwarding. With DNAT all connections to a specific IP address are forwarded to another IP address. As with SNAT and masquerading, reverse NAT mapping occurs automatically. This NAT type is almost never used, as port forwarding accommodates most possible requirements.

image

Based on the image above, a connection to 200.210.0.1 on any port, is mapped to 10.0.0.2 on any port (the same port initially used in the connection to 200.210.0.1). The server receives the packet and sends a reply packet with its private IP address, 10.0.0.2. To avoid this packet from being dropped immediately on the Internet as it leaves the LAN, this private IP address is automatically translated to the correct public IP address of the AXS Guard i.e. 200.210.0.1; thus De-NAT is automatic with DNAT. The server in the DMZ cannot be contacted when making a connection to the AXS Guard on IP 200.210.0.2.

Creating DNAT Rules
  1. Navigate to Network > NAT > SNAT/DNAT.

  2. Click on the Add New button.

  3. Configure the settings (see SNAT)

  4. Click on Save to finish.

    Adding Network Address Translation (DNAT) Rules

important

  • Sometimes you may need a one-to-one NAT of a network range. For example, you have the 192.168.1.0/24 network and you would like to NAT each IP to its equivalent in 192.168.2.0/24 (SNAT) or vice versa (DNAT) when the packet travels through the NAT device. Make sure the subnets do not overlap each other.
  • Select Don't Translate in the Action field if you wish to define exceptions.

Port Redirection

How Port Redirection Works

Port redirection is a NAT type that is used to intercept traffic bound for a certain port and redirects that traffic to another port on the AXS Guard appliance.

image

A good example of port redirection is the redirection of http traffic to the proxy (illustrated above). If the browser proxy settings of hosts in the LAN are set to port 80, it is possible to configure a single port redirection rule on the AXS Guard so that all traffic going to port 80 is redirected to port 3128. Port 3128 is the default port number of the AXS Guard Proxy Server. This method is more efficient than modifying the proxy settings on each client.

For information about the use of the AXS Guard proxy server, see the AXS Guard Web Access How To, which is available via the Documentation button.

Pre-defined Port Redirection

important

  • Disabling certain predefined port redirection rules may prevent Able from providing remote support.
  • Predefined port redirection rules can be disabled, but cannot be removed or altered.

  1. Navigate to Network > NAT > Port Redirection.

  2. Click on the rule name to view details.

    Overview of Predefined Port Redirection Rules

Creating Port Redirection Rules
  1. Navigate to Network > NAT > Port Redirection.

  2. Click on the Add New button.

  3. Configure the settings as explained in the table below.

  4. Click on Save to finish.

    Adding Port Redirection Rules

Field Description

Name

Enter an identifier for the rule, using only lower cases without spaces, starting with an alphabetic character, followed by any number of alphanumeric characters and/or the special characters: back slash \, hyphen -, underscore _, full stop . and the @ symbol, e.g. http_proxy.

Description

Describe the purpose of the rule (optional field).

Enabled

Check to enable the rule.

Source IP/Net

Restrict redirection to the specified source IP address or subnet. Use the CIDR notation to specify a subnet. If none is specified, traffic coming from any source IP will be redirected.

Protocol

The protocol to be matched.

Entering via Device

The network device or zone on the receiving end of the connection.

Coming to IP or Network

If an IP address is specified, traffic will only be redirected if the destination IP matches the IP in the headers of the outgoing packets. If left blank, the rule applies to any destination IP.

Port

Traffic coming to this port will be redirected to the specified destination port.

Destination Port

The port to which traffic must be redirected.

NAT Helpers

What are NAT Helpers?

An important property of the AXS Guard firewall is the use of connection tracking. Connection tracking is the ability to keep records of connection information in tables.

This connection information consists of source and destination IP addresses, port number pairs (also known as socket pairs), protocol types, connection states, timeouts, etc. NAT helpers automatically add the necessary connection information to the connection tables for protocols that require it and ensure that associated connections are properly NATed.

The protocols listed below all use associated connections (control channels) for which NAT helpers can be enabled.

Enabling NAT Helpers
  1. Navigate to Network > NAT > NAT Helpers.

  2. Enable the NAT helpers that are required in your network (see the table below).

  3. Click on Update to finish.

    Enabling NAT Helpers

NAT Helper Description

FTP conntrack Helper Ports

Tracks so-called active FTP connections (ports 21 and 20).

VPN PPTP Helper

Tracks TCP port 1723 and the associated GRE tunnel.

IRC Helper

Tracks IRC connections on TCP port 6667.

H.323 Helper

NAT helper for the H.323 protocol (VoIP). It supports RAS, Fast Start, H.245 Tunnelling, Call Forwarding, RTP/RTCP and T.120 based data and applications including audio, video, fax, chat, whiteboard, file transfer, etc.

SIP Helper

NAT helper for the SIP protocol (VoIP).

SNMP Helper

NAT helper for the SNMP protocol. This is the ‘basic’ form of SNMP-ALG, as defined per RFC 2962. It modifies IP addresses inside SNMP payloads to match IP-layer NAT mapping.

TFTP Helper

NAT helper for the TFTP protocol, which tracks TFTP connections on UDP port 69.

Amanda Helper

NAT helper for the Amanda backup tool protocol.

Network Status Information

Netstat

netstat is used to display network status information.

Traditionally, it is used more for problem determination than for performance measurement. However, netstat can be used to determine the amount of traffic on the network to see what is causing performance problems, e.g. in case of network congestion.

netstat provides information about traffic on your appliance’s network interfaces, such as the following:

  • The address of any protocol control blocks associated with the sockets and the state of all sockets

  • The number of received, transmitted and droppped packets

  • Cumulative statistics per interface

  • Routes and their status

Netstat Output

Navigate to System > Status > Netstat.

Netstat Information

Used Ports

Navigate to Network > Status > Ports for an overview of used ports per service. Ports used in port redirection rules are also listed.

Overview of Used Ports

System Time and NTP

What is NTP?

NTP (Network Time Protocol) is a protocol designed to synchronize the clocks of hosts over a network. The AXS Guard appliance can be used as a time server in your LAN. The AXS Guard’s internal time server is enabled by default and cannot be disabled. Clients in your network need to be configured accordingly to make use of this service. See the documentation of your Operating System for instructions.

A correct system time is critical for time-sensitive processes, such as 2FA and Kerberos authentication.

NTP Concept

Synchronizing with a Time Server

  1. Navigate to Network > General.

  2. Enter the FQDN or IP address of an NTP server. ntp.axsguard.com is the factory default server and is also recommended for security reasons.

  3. Click on Update.

Important

Using unknown NTP sources on the Internet is dangerous, as they can deliver invalid timestamps or their UDP packets could be spoofed on their way to your clients and devices.

Syncing the AXS Guard Appliance with a Time Server

Field

Description

ISP Domain Name Server

The IP address(es) of your ISP’s DNS servers.

Include default AXS Guard NTP Time Servers

Many AXS Guard appliance security features such as log generation, backup & restore, certificate validation and two-factor authentication rely on accurate time. With an imprecise time, your connected devices may run into different kinds of errors and you also may encounter various troubleshooting burdens. AXS Guard NTP servers provide redundancy, which means clients and other devices connected to your network will always be able to get the correct time.

ISP NTP Time Server

The IP address or FQDN of a time server. ntp.vasco.com is the factory default time server. A correct system time is critical for time-sensitive processes, such as DIGIPASS authentication.

Primary Secure Device

Do not change this parameter unless absolutely necessary. eth0 is the factory default setting which is used by the following services:

  • The AXS Guard configuration tool (TCP port 82)

  • The AXS Guard proxy server (TCP port 3128)

  • DNS zone transfers (TCP port 53)

  • The synchronization of appliances in a High Availability configuration

Allow DNS zone transfers on secure LAN?

Check this option to allow DNS zone transfers from the appliance to a secondary DNS server in your LAN. Zone transfers allow DNS servers to synchronize their repositories.

  • Alias IP Address for Zone Transfers: Zone transfers on a secure LAN device require an alias IP address for that device. Go to Network > Eth and select the IP Settings tab to configure an alias for the primary secure LAN device. The secondary DNS server requests zone transfers from the alias IP address, rather than from the primary secure LAN IP address.

  • Secondary Name Servers: Enter the IP address(es) of the backup (secondary) DNS server(s) in your network. The IP address of the secondary DNS server must be registered under Computers for DNS Zone transfers to be successful.

Disable path-MTU discovery?

Check to disable path-MTU discovery for all connections on the appliance, which implicitly enables IP fragmentation for all of them.

Checking the System Time

The system time of the AXS Guard appliance is permanently displayed in the top pane of the administrator tool.

AXS Guard ApplianceSystem Time

System Status

Overview

The System Status menu provides general information about the AXS Guard system and specific information about the system’s health, services, hardware and the system kernel. In this section we explain how to access and use the system status information.

System Info

Navigate to System > Status > System Info to view:

  • the license information

  • the Able contract type

  • Version and Revision numbers

  • Host and Configuration Keys

  • information about the model (Type), Able DIGIPASS and AXS Guard hardware

  • available software features.

Accessing the System Information

Process Info

Navigate to System > Status > Processes to view detailed process information, i.e. UNIX-style information about the active processes on your appliance. You can also request process information using the ps and top commands via the AXS Guard console. See the CLI How To for more information.

Process Information

Netstat

See the section about network status information.

Health Status

The system health screen provides information about:

  • the system’s up time

  • the general health status (OK or Not OK)

  • health status messages.

Accessing the System Health Status

  1. Click on the Dashboard button or

  2. Navigate to System > Status > Health

System Health Information

Health Status Message Classification

Health status messages are either run time messages or messages generated after routine self-checks. Health messages are classified according to their severity.

Type Description

Fatal Error

Critical errors that prevents the correct operation of the appliance or one of its services, e.g. the failure of a network device.

Error

Errors do not necessarily prevent the correct operation of the appliance, but need immediate attention as they could affect future operations if left unattended, e.g. a failure of antivirus updates.

Warning

Warnings notify system administrators of configuration errors, e.g. when the default sysadmin password has not been changed, which is insecure.

Notices

Information about running processes, e.g. when the antivirus engine is being updated.

Runtime Messages

Run time health messages either offer a link to the configuration page where action needs to be taken or offer information about a configuration problem and/or the action which is required to resolve it.

Example of a Run Time Health Message

Configuration Warnings

AXS Guard self-checks occur automatically every night and take a couple of minutes to complete. Configuration warnings are generated after the self-checks and are refreshed every 24 hours after every self-check. This means that a configuration warning remains visible until the next self-check. The messages either offer links to interactively resolve problems or explain configuration problems and/or actions needed to resolve them.

  1. Navigate to System > Status > Health

  2. Click on the Start Configuration Check button (shown below). Note that the configuration check takes a few minutes to complete.

    image

For information on feature-specific health messages and problems, refer to the relevant AXS Guard How To guides, available via the Documentation button.

Services Status

The Services screen displays the status of the AXS Guard services. A stopped service can be (re)started via this screen.

Navigate to System > Status > Services. The fields are explained in the table below.

Service Status Screen

Field

Description

Service

The name of the service.

S

  • Green: the service is running normally.

  • Red: the service is no longer running or there is a problem with the service and it needs to be restarted.

  • Grey: the service is available, but not enabled under System > Feature Activation.

Status

Indicates whether the service is stopped, enabled or disabled.

Action

Click to restart the service.

Extra Information

Provides extra information about the service, i.e. the process ID (PID).

Hard Drive, UPS and Kernel Status

Other status screens provide information about the AXS Guard’s

  • hard drive(s), e.g. partition information, remaining disk space, etc.

  • connected UPS (if any). Only APC UPS appliances are supported.

  • running Kernel modules and the amount of system memory used by each module.

Go to:

  • System > Status > Hard-Disk for information about the AXS Guard Hard Drive(s).

  • System > Status > UPS for information about connected UPS, if any.

  • System > Status > Kernel Modules for information about loaded Kernel Modules.

High System Load Warning Messages

The AXS Guard will automatically send an e-mail to the system administrator, if it detects a high system load during 5 consecutive days. The e-mail is sent to the e-mail address(es) entered under System > General. A high load average can be due to a task monopolizing a lot of CPU time. A hardware update may be required. Contact the Able Sales Department for additional information.

System Reports

Threat Reports

The reporting feature allows system administrators to better monitor various types of network and system activity. The aim is threat detection and protection in the context of the General Data Protection Regulation (GDPR). Administrators will be able to generate various types of reports covering a given period, for example:

Authentication and Authorization Report

The authentication and authorization report is an easy way to detect suspicious login activity. If such activity is detected, administrators can intervene immediately by blocking the IP address associated with this activity.

Malware Detection

Malicious software in its various forms remains one of the key threat vectors for today’s organizations. The malware report provides a quick overview of viruses that have been blocked by the proxy and mail server.

Resource Access Report

These reports identify various system and application resource access patterns and can be used for both activity audit, trending and incident detection.

Tracking resource access can be used to reveal insider abuse and even fraud. They are valuable during incident response for determining which resources the attacker has accessed and possibly corrupted or modified. In addition, resource access can be used for purposes outside of security, such as capacity planning and other purposes.

Change Reports

These reports highlight changes made to the system configuration and can be used to audit administrator activity. For example, updating user accounts, changes to the firewall, etc.

Unauthorized changes to information systems can lead to costly crashes and the loss of data and may indicate security incidents. On top of this, attackers will often modify your systems in order to enable their access in the future. Being diligent with tracking changes will also improve your overall IT operation.

Viewing Threat Reports

  1. Go to Reports > Threats.

  2. Select the desired report type, e.g. authentication and authorization.

  3. Select the desire subtype, e.g. Login Activity.

  4. Select the desired period.

AXS Guard Reports

Info

Reports may also contain usernames linked to internal system processes, e.g. cyrus. This is expected behavior. System processes should never indicate a login failure. If a login failure is, however, detected, administrators should check the full event logs.

Mail Usage Reports

  1. Navigate to Reports > Mail Usage.

  2. Select the desired period.

  3. Click on the appropriate more link.

    MTA Reports

Info

Click on an area in the pie chart for additional details.

Web Access Usage Reports

  1. Go to Reports > Web Access Usage.

  2. Select the period for which a report must be generated.

  3. Click on the appropriate more link.

    Web Access Report

Configuring your own Reports

Automated security audit reports bring relevant and useful system information to administrators via e-mail, so they don’t have to seek out the information for themselves. This allows them to better monitor various types of network activity and identify potential threats in a GDPR context.

A default export configuration is available for convenience. This configuration cannot be modified, only enabled. If you wish to base your own export configuration(s) on the system default configuration, simply click on its name in the overview and use the edit as new button.

Reports are mailed to the specified recipient, based on the selected frequency. Note that access to the reporting feature is restricted to reporting users or users with higher access privileges. You can test report configurations by clicking on the Send Test E-mail button.

  1. Go to Reports > Configuration.

  2. Click on "add new".

  3. Configure your system report settings as explained in the table below, then save your configuration.

    Automated Security Audit Report Export Options

    Info

    The report configuration page is also accessible via the AXS Guard dashboard.

    Automated Security Audit Report Dashboard

Options Description

Name

Enter a name for your export profile, using lower cases without spaces, starting with an alphabetic character, followed by any number of alphanumeric characters and/or the special characters: back slash (\), hyphen (-), underscore (_), full stop(.) or the "at" sign (@).

Description

Use a sensible description to facilitate the configuration and management of your export profiles. The description will also appear in the export profile overview.

Enabled

Check to enable the export profile. If enabled, selected reports will be mailed to the specified e-mail addresses.

Obfuscate sensitive information

If checked, sensitive data in reports will be masked. The aim is to secure confidential information that may directly or indirectly reveal an individual’s identity.

Mail Reports to Administrator

If checked, the appliance will send the selected reports to the e-mail addresses specified under System ▸ General.

Specify other e-mail address to send reports

Select to specify additional e-mail addresses, e.g. an external e-mail address.

E-mail Addresses to send reports to

This field only appears if you selected the previous option. Enter the desired e-mail address and press the add button. Repeat the steps to add other addresses.

Selected Reports

Select the reports to be included in the e-mail. Reports will appear in the specified order. The order can be changed by clicking on the arrows in the order column. Press the preview button to view your current configuration and adjust the order if necessary.

Skip empty reports

Select to exclude reports which don’t contain any data. An e-mail will not be sent if no data is present in any of the selected reports.

Frequency

Automated e-mails will be sent as scheduled. Monthly is the factory default configuration, which means selected reports will be sent on the 1st of each month.

System Logs

Overview

In this section we explain how to access and use the system logs of the AXS Guard. Logs are ordered chronologically by default and labeled using the YYYY-MM-DD format. The log size is expressed in Kilobytes (KB).

Accessing Log Files

  1. Go to System > Logs.

  2. Select the desired type, for example Admin Tool.

  3. Click on the date to view the log entries.

    Example of a Log File

Info

Use search filters to look for a particular log entry.

Example of a Search Filter in the Full Event Log

Log Types

Type Description

Update History Log

Logs of all software update events.

Test Update History Log

Logs of all version tests.

Administrator Tool Log

All actions performed by system administrators.

Boot Log

Indicate when the system was booted up and shut down.

Network Security Logs

A compilation of logs related to traffic dropped by the firewall, the IPS and the application control system.

Full Event Log

A compilation of all the logs which are available on the appliance.

Other Log

A smaller version of the full event Log, with feature-related entries filtered out.

Remote Syslog

Logs sent to the appliance by another log server in its network, configured under System > Syslog.

Remote Syslog Management

Overview

Managing log files is a vital part of network administration. The syslog management utility offers you the ability to log system activities locally and remotely. This capability can be essential if you need to archive log files for a long period of time or simply want log files to be available on other systems in your network.

The syslog management utility allows you to centralize AXS Guard log files on a single server or to distribute them over several servers per facility or service, e.g. to store all e-mail log files on server A and firewall logs on server B.

Supported Delivery Types

Sumo Logic

  • Local delivery: refers to logs that are generated by and stored on the AXS Guard appliance.

  • Network delivery: refers to logs that are forwarded by a dedicated log server to and stored on the AXS Guard appliance.

  • Relay delivery: refers to logs that have been delivered to the AXS Guard appliance (see network delivery). Once the logs are received, the AXS Guard appliance relays them to another log server as specified in the configuration.

  • Mail delivery: the AXS Guard appliance sends logs by e-mail to the specified addresses.

  • The Sumo Logic log collector: a cloud-based log management and analytics service.

Local Delivery

By local delivery, we mean the local logging system of the AXS Guard. This option is enabled by default. We strongly recommend not to disable this option, unless there is insufficient disk space on your appliance or if you are using it as a log relay server.

Network Delivery

The AXS Guard’s log service enabled by default. This allows services in your secure network to forward log messages to the appliance. To use this functionality, you must configure the service(s) in your secure network to forward their logs to the AXS Guard, which listens on UDP Port 514.

For information about the appliance’s firewall configuration, see the AXS Guard Firewall How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool.

Personal AXS Guard clients forward their log messages to the AXS Guard VPN server as soon as the VPN Tunnel is up.

Important

Never expose UDP port 514 on the Internet side of your appliance. Only allow access from trusted networks, i.e. hosts in your LAN or connected via a VPN.

Relay Delivery

The AXS Guard’s log service has the ability to relay its local logs and logs received via the network to another log server in your network. Relay delivery is disabled by default and must be enabled before you can configure log relaying for any facility or service.

A default log relay is available for ease of configuration and allows you to relay all logs to (a) specific server(s). Enter the IP(s) or the hostname(s) of the target log servers and create the necessary relaying entries for each service or facility.

E-mail Delivery

If enabled, the appliance will forward log files the specified e-mail address(es) at the specified intervals.

The Sumo Logic Collector

The AXS Guard appliance offers a cloud-based solution to collect its log files, which we explain in the Sumo Logic Collector section.

Facilities and Services

A Facility is the proprietary log of a service running on the AXS Guard, e.g. OpenVPN produces its own log files, IPsec produces its own log files, etc.

A Service may contain one or more Facilities, e.g. the VPN Service contains the following Facilities: IPsec, PPP, OpenVPN, SSL VPN and the Personal AXS Guard. The Monitoring Service only contains one Facility, namely IPS.

Relaying can be configured per Facility or per Service. Local logging can only be configured per Facility.

Supported Log Formats

RFC 3164 RFC 3339

The log type mainly influences the formatting of relayed log messages, i.e. logs that are relayed by the AXS Guard to a log server. Details about the various formats are outside the scope of this manual. For detailed information about the supported formats, see the corresponding RFC of the list below via http://www.ietf.org/rfc.html.

The following log types are supported:

  • RFC 3164: This is the system default type and is the most human-readable format.

  • RFC 3339: This format contains the most details (e.g. timestaps)

  • Unix: Used by older servers and less detailed than RFC 3164 and 3339.

If you are using your appliance as a log server and relay simultaneously, and the source server generates Unix type logs, the AXS Guard will insert extra log headers before forwarding the logs to the target log server.

Remote Syslog Configuration

General Settings

In this section we explain how to enable the delivery type.

  1. Log on to the AXS Guard.

  2. Navigate to System > SysLog > Delivery Options.

  3. Check to enable / Uncheck to disable the desired delivery.

  4. Click on Update

    Remote Syslog General Options

Important

Relay Delivery has to be enabled if you wish to relay logs for any service or facility.

Option Description

Enable Local Delivery

The logs that are generated locally on the appliance. This option is enabled by default. Do not to disable, unless there is insufficient disk space on your appliance or if you are using the appliance as a log relay.

Enable Network Delivery

Allows log servers in your secure network to forward log messages to the syslog server of the appliance, which listens on UDP Port 514.

Enable Relay Delivery

The appliance can relay logs to another log server in your network. Relay delivery is disabled by default and must be enabled before you can configure log relaying for any facility or service.

Enable Mail Delivery

If enabled, the appliance will be able to send log files by e-mail to the specified address(es) at the specified intervals.

Local Delivery

In this section we explain how to configure Local Logging. Only three parameters need to be configured at the Facility level. The parameters are explained in the table below.

  1. Enable Local Logging.

  2. Navigate to System > SysLog > Facilities.

  3. Select the desired Facility, e.g. OpenVPN.

  4. Modify the settings as explained in the table below.

  5. Click on Update.

    Local Logging Configuration

Option Description

Rotate Log Size

Log rotation occurs when a log file reaches the specified size, i.e. a new log file is created.

Keep Minimum

The minimum number of days that the log files are to be kept on the system. Enough disk space must be available on the appliance for the specified minimum to be allowed (Disk usage must remain under 90% of the total available capacity).

Keep Maximum

The maximum number of days that the log files are to be kept on the system. Disk space restrictions also apply.

Network Delivery

  1. Enable the Network Logging option.

  2. Click on Update.

The configuration for local storage is done via the Remote Syslog Facility. To change the default settings of the Remote Syslog Facility:

  1. Navigate to System > Syslog > Facilities.

  2. Select Remote Syslog.

  3. Change the appropriate settings.

  4. Click on Update.

    Remote Syslog Settings

Info

  • The log files which are sent to the AXS Guard can be viewed by navigating to VPN&RAS > Logs > Personal AXS Guard > Clients.
  • Network Logs can be relayed too.

Relay Delivery

Overview

In this section we explain how to configure Relay Logging. This consists of the following steps:

  • Enable Relay logging as explained in section.

  • Configure the Log Relay Resources: a server or group of servers to which logs are relayed in the supported formats.

  • Enable the Relay Resource(s) at the Service or Facility level.

Log Resource Configuration
  1. Enable the Log Relaying option.

  2. Navigate to System > Syslog > Relays .

  3. Click on Add New.

  4. Enter the settings as explained in the table below.

    Configuring Log Resources

Option

Description

Name

A label for the network resource.

Description

An optional description for the resource.

Type

  • RFC 3164: This is the system default type and the most human-readable format.

  • RFC 3339: This format is the most detailed (e.g. timestaps).

  • Unix: Used by older servers and less detailed than the RFC 3164 and 3339 formats.

For detailed information, see the corresponding RFC on http://www.ietf.org/rfc.html.

Host Names / IPv4 Addresses

The FQDN, e.g. server.somedomain.com or the IP address of the network resource. Only IPv4 addresses are accepted. When hostnames are used, a DNS query is executed each time a log message is sent to the specified host(s). This may slow down the logging process (even locally) when the DNS service of the appliance is down or temporarily not available (e.g. while booting).

Port

The port on which the network resource listens. The system default is UDP port 514.

Info

Use the existing Default Relay definition when all logging needs to be forwarded to a specific relay server. This is much easier, since you only need to add the host name or IP address to this Definition. This Relay is assigned and enabled by default for all the Facilities (i.e. there is no need to follow the steps explained in the next subsections).

Using a Relay Resource

You can use Relay Resources at the Facility level or at the Service Level.

  1. Navigate to System > Syslog > Facilities.

  2. Select the appropriate Facility from the list.

  3. Enable Relaying.

  4. Add the appropriate log resource by clicking on the Add Relay Resources button.

    Using a Relay Resource at the Facility Level

Field

Description

Enable Relaying

Check to enable log relaying.

Relay Resources

Select the desired relay resource(s) as configured under System > Syslog > Relays.

Using a Relay Resource at the Service Level:

  1. Navigate to System > SysLog > Services.

  2. Select the desired Service.

  3. Enable Relaying (select Yes).

  4. Add the appropriate log resource by clicking on the Add Relay Resources button.

  5. Configure the appropriate Relay Resource(s) by clicking on the Change Relays Button.

  6. Click on Update.

    Service Configuration Settings

Option

Description

Enable Relaying

  • Yes: Check to enable relaying for all listed facilities in this group (service).

  • No: Check to disable relaying for this service.

Change Relays

Click on this button to change or select the relay. The relay must exist under System > Syslog > Relays.

Mail Delivery

Overview

Configuring a mail resource consists of the following steps:

  • Enable mail delivery under System > Syslog > General.

  • Configure the mail resource by adding the desired recipients.

  • Assign the mail resource to the appropriate service or facility.

Log Resource Configuration
  1. Go to System > Syslog > Mail

  2. Click on add new.

  3. Configure the settings as explained in the table below.

  4. Save your configuration.

  5. Assign the policy to a facility or a service.

    Mail Relay Configuration

Field

Description

Reference Name

A name for the mail resource.

Description

A description for the mail resource (optional field).

Enabled

Check to enable the mail resource.

Reporting Frequency

Select the desired frequency from the drop-down list.

Recipients

Logs will be sent to the specified e-mail address(es).

Using a Mail Resource

You can use Mail Resources at the Facility level or at the Service Level.

  1. Navigate to System > Syslog > Facilities.

  2. Select the appropriate Facility from the list.

  3. Enable Mailing under Mail log settings.

  4. Select the mail resource and save your settings.

    Mail Resource at the Facility Level

Field

Description

Enable Mailing

Check to enable mail delivery.

Mail Resources

Select the desired mail resource as configured under System > Syslog > Mail.

Using a Mail Resource at the Service level:

  1. Navigate to System > Syslog > Services.

  2. Select the appropriate Service from the list.

  3. Enable Mailing under Mail log settings.

  4. Select the mail resource and save your settings.

    Mail Resource at the Service Level

Field

Description

Enable Mailing

  • Yes: Check to enable mail delivery for all listed facilities in this group (service).

  • No: Check to disable mail delivery for this service.

Mail Resources

Select the desired mail resource as configured under System > Syslog > Mail.

The Sumo Logic Collector

About

Sumo Logic is a cloud-based log management and analytics service that leverages machine-generated data, such as log files. Centralized logging eliminates the need for additional archiving, backups and restores. Data can be pre-parsed and partitioned on ingest. A wide range of collector and search API’s also helps administrators easily develop and integrate data sources with the Sumo Logic service.

Info

The Sumo Logic Collector is a third-party software package integrated with the AXS Guard appliance. For support issues related to the Sumo Logic cloud platform, please contact the Sumo Logic help desk or go to https://service.eu.sumologic.com/help/.

Feature Activation

Sumo Logic

  1. Go to System > Feature Activation > Monitoring.

  2. Enable the following options:

    • Do you use the Security Information and Event Management?

    • Do you use the Sumo Logic Collector?

  3. Save your configuration.

    Sumo Logic Feature Activation

General Settings

  1. Go to Monitoring > Log Analysis > Sumo Logic Collector > General.

  2. Enter the settings as explained in the tables below.

  3. Save your configuration.

    Sumo Logic General Settings

Field

Description

Name

A unique name which represents the collector that will be registered with the Sumo Logic cloud service. As long as a collector is not successfully registered, the hostname of the AXS GUARD system is suggested as the default value.

Use Access ID / Key

There are 2 methods to authenticate the collector with Sumo Logic. Choose the preferred method:

  • Enabled: Use the Access ID and Access Key. This is the preferred method (more secure and system default).

  • Disabled: Use your e-mail address and password to authenticate the collector with Sumo Logic.

Field

Description

Bootstrap URL

URL used to register the collector for the Data Collection API. The default value is https://collectors.sumologic.com and should not be altered.

URL

The URL used by the Sumo Collector software during operation. It is automatically updated after successful registration and should never be altered. Registration is region-specific and may not be available among other collector URLs or sites.

Minimum amount of memory to use

The Sumo Logic Collector is a Java-based application. Specify the minimum amount of system memory to be allocated for the Java Virtual Machine. The default value is 64 megabytes.

Maximum amount of memory to use

The maximum amount of memory of system memory to be allocated for the Java Virtual Machine. The default value is 128 megabytes.

Scheduling priority

Specify the scheduling priority for the Sumo Logic Collector, where a value of -20 is the most favorable and 19 is the least favorable. The default value is 0 (normal priority).

CPU

You can assign the Sumo Logic Collector process to a specific CPU or core. By default no value is specified, which means the process is scheduled to run on the most favorable CPU or core available at runtime.

Adding Sources

  1. Go to Monitoring > Log Analysis > Sumo Logic Collector > Sources.

  2. Enable the sources to be collected by the Sumo Logic Collector, as explained in the table below.

    Sumo Logic Collector Sources

Field Description

Name

The unique name that will be used to create the source under the system’s collector on https://service.eu.sumologic.com/ui/.

Enabled

Check to enable. Once a source is enabled, it will be created automatically on the Sumo Logic cloud platform. The collector will pick up configuration changes from the platform and start to collect log entries for it. Disabling a source automatically removes it from the Sumo Logic cloud platform and stops any further collection of data for that source.

Description

A description which provides general information about the source.

Log Facility

Select the name of an AXS Guard log facility. An overview of all log facilities is available under System > Syslog > Facilities.

Status and Logging

Go to Monitoring > Log Analysis > Sumo Logic Collector > Status.

Sumo Logic Collector Status Screen

Field Description

Enabled

Green means that the collector has been successfully registered and is up and running.

Name

The name of the collector as registered on https://service.eu.sumologic.com/ui/.

ID

ID of the collector, assigned by Sumo Logic.

Version

The software version of the AXS Guard Sumo Logic collector.

Status

Indicates whether the collector is up and running.

PID(s)

The process IDs associated with the Sumo Logic collector process also listed under System > Status > Services and Processes.

Sources

The number of configured sources (selected under Monitoring > Log Analysis > Sumo Logic Collector > Sources).

Connected

Green means that the AXS Guard appliance is successfully connected to the Sumo Logic cloud service.

Viewing the Sumo Logic application logs:

  1. Go to Monitoring > Logs > Sumo Logic.

  2. Select the appropriate log date.

    Sumo Logic Logging

Authentication Settings

Overview

AXS Guard can be used as a standalone authentication appliance or as a UTM appliance providing strong authentication and Internet security. It supports the following authentication features:

  • One-factor authentication and two-factor authentication, e.g. DIGIPASS Authentication.

  • Local and back-end authentication: credentials can be checked locally on the AXS Guard or via a back-end server in its network.

  • The AXS Guard can be installed as a RADIUS server, a RADIUS client or a combination of both.

  • The AXS Guard can be synchronized with an LDAP back-end, such as a Microsoft Directory Server.

Important

If you are using the DIGIPASS authentication and management functionalities of the AXS Guard appliance, you must set a Derivation Key before any DIGIPASS tokens can be imported and deployed. For detailed information about authentication, see the AXS Guard Authentication and Directory Services manuals.

Setting the Derivation Key

The derivation key is a string which consists of 16 ASCII characters used to encrypt or decrypt the AXS Guard DIGIPASS database. It provides physical security, in that access to the AXS Guard hard drive(s) alone is not sufficient to read DIGIPASS data. The derivation key must be entered by an AXS Guard user with full administrative privileges or above before any DIGIPASS blob data can be imported. A derivation key can only be changed by a full system administrator or above.

  1. Log in to the AXS Guard appliance.

  2. Go to Authentication > Able DIGIPASS > General.

  3. Enter the Derivation Key in the Derivation Key used for data crypto field.

  4. Save your settings.

    image

Troubleshooting

I cannot access the AXS Guard administrator tool.

  1. Ping the LAN IP address of the AXS Guard. The factory default LAN IP address is 192.168.250.254. If the network is unreachable, check the IP address and subnet of your client.

  2. If you can ping the LAN IP address of the AXS Guard, check the proxy settings of your Internet browser and adjust them if necessary. Consult the documentation of your Internet browser if necessary.

I cannot log in to the administrator tool with IE or Chrome.

If you log in to the Administrator Tool using Internet Explorer or Chrome on Windows XP SP2, the connection will fail as of AXS Guard version 7.7.0.

As of version 7.7.0, Windows XP SP3 or later versions of the OS are required to log in to the administrator tool, because the appliance will be using the SHA-256 algorithm to sign its certificates. This algorithm is only supported by Windows XP SP3 and later versions of the Windows OS.

Firefox can be used to log in to the administrator tool on Windows XP SP2.

A purchased software option is missing from the AXS Guard menu.

A newly purchased AXS Guard software option must be activated under Feature Activation before it can be accessed for configuration.

I cannot log in to the administrator tool.

Check that the user account is permitted to access the Administrator Tool:

  1. Navigate to Users and Groups > Users.

  2. Click on the Mailbox / User name.

  3. Make sure the user account is enabled.

  4. Click on the AXS Guard Administration tab.

  5. Check that the correct Tool Access Type has been configured for the user.

Users cannot change their AXS Guard password.

  1. Check that the correct Tool Access Type has been configured for the user.

  2. Check that the user is allowed to change his/her password, by navigating to Users and Groups > General. The May users change their passwords? option must be checked.

I corrected the configuration, but still get an error message

Some system health messages are only refreshed after the self-checks which are completed every 24 hours. To test your configuration settings and force the health messages to be refreshed immediately:

  1. Navigate to System > Status > Health.

  2. Click on the Start Configuration Check button. Please note that the configuration check takes a few minutes to complete. If the configuration has been corrected, the message will no longer be displayed.

tool does not seem to resolve.

  1. Check your browser’s proxy settings.

  2. Navigate to System > Administrator Tool and check whether the name to go to the Administrator Tool has been changed.

The Sumo Logic Collector fails to register (Temporary failure in name resolution).

The Sumo Collector will fail to register if it cannot connect to https://api.sumologic.com. If you see entries similar to the ones below in the system’s full event log, reboot the appliance and restart the Sumo Logic registration procedure.

    15:58:51 AXSDBG debug tsrv-cmdqx(SumoLogic::Service>restart)[23473] SumoLogic::API::process(190) Error in HTTP GET https://api.sumologic.com/api/v1/collectors : 500 Can't connect to api.sumologic.com:443
    15:58:51 AXSDBG debug tsrv-cmdqx(SumoLogic::Service>restart)[23473] SumoLogic::API::process(196) Can't connect to api.sumologic.com:443; LWP::Protocol::https::Socket: getaddrinfo: Temporary failure in name resolution at /ub/lib/perl5/site_perl/LWP/Protocol/http.pm line 51.;
    15:59:34 AXSDBG debug tsrv-request(idle)[22706] SumoLogic::API::process(190) Error in HTTP GET https://api.sumologic.com/api/v1/collectors : 500 Can't connect to api.sumologic.com:443
    15:59:34 AXSDBG debug tsrv-request(idle)[22706] SumoLogic::API::process(196) Can't connect to api.sumologic.com:443; LWP::Protocol::https::Socket: getaddrinfo: Temporary failure in name resolution at /ub/lib/perl5/site_perl/LWP/Protocol/http.pm line 51.;
    16:00:09 AXSDBG debug tsrv-cmdqx(SumoLogic::Service>restart)[23655] SumoLogic::API::process(190) Error in HTTP GET https://api.sumologic.com/api/v1/collectors : 500 Can't connect to api.sumologic.com:443
    16:00:09 AXSDBG debug tsrv-cmdqx(SumoLogic::Service>restart)[23655] SumoLogic::API::process(196) Can't connect to api.sumologic.com:443; LWP::Protocol::https::Socket: getaddrinfo: Temporary failure in name resolution at /ub/lib/perl5/site_perl/LWP/Protocol/http.pm line 51.;
    16:00:09 AXSDBG error tsrv-cmdqx(SumoLogic::Service>restart)[23655] Result::_add(516) Failed to register Sumo Logic Collector: Can't connect to api.sumologic.com:443
    16:03:18 AXSDBG debug tsrv-request(idle)[17152] SumoLogic::API::process(190) Error in HTTP GET https://api.sumologic.com/api/v1/collectors : 500 Can't connect to api.sumologic.com:443

Support

If you encounter a problem

If you encounter a problem with AXS Guard, follow the steps below:

  1. Check the troubleshooting section of the feature-specific manual.

  2. Check the knowledge base on this site for information about special configurations.

  3. If no solution is available in any of the above sources, contact your AXS Guard vendor.

Contact Information

(+32) 15-504-400
support@axsguard.com