Firewall Guide

Introduction

About this Document

This document is an introductory guide to the AXS Guard firewall. It is intended for system administrators or technical personnel with a good understanding of network security and TCP/IP.

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.

Essential Terminology

Overview

In this section, we provide some essential definitions which occur frequently throughout this guide. Knowledge of these definitions is required to successfully configure your AXS Guard Firewall. We also explain the different Firewall components are and how they relate to each other.

Topics covered in this section include:

• A general definition of Firewalls and their purpose.

• Terminology which is needed to better understand the AXS Guard firewall concepts.

• Advantages of the AXS Guard Firewall.

What are Firewalls?

A Firewall protects your network from unlawful access (i.e. hackers) by blocking incoming connections which are not desired or unauthorized. It does so by inspecting incoming network packets. Besides blocking undesired external traffic, Firewalls also prevent malicious network traffic from leaving your secure network, i.e. by blocking outgoing network traffic generated by possibly malicious software, such as certain types of viruses or Trojans.

In the following section, we briefly explain some key terminology to better understand the operation and configuration of the AXS Guard Firewall.

Rules, Policies and Security Levels

In this section we explain some vital terminology used throughout this guide. It will help you to understand the different Firewall components and how they are related.

Rules: A Firewall Rule is the smallest configurable component of the AXS Guard Firewall. A Rule determines how a certain network packet is handled, i.e. whether is it is accepted, dropped or logged. Rules are the cornerstone of the AXS Guard Firewall.

Policies: A Firewall Policy is a logical set of Firewall Rules organized in a certain order, which is critical. A Firewall Policy can be assigned to AXS Guard security levels, i.e. a user, a group, computers or the system level.

Security Level: The level at which a Firewall Policy is assigned, i.e. an AXS Guard user, group, computer or system. System-level settings must be the strictest, since they are valid for all connected devices and computers.

Firewall Rights: General term used to describe Firewall permissions and restrictions at a given security level, i.e. the services a given user, group or computer can or cannot access.

Firewall GUI: The graphical user interface used to:

• Create, edit and configure Firewall rules and Policies

• Assign Firewall Policies to users, groups, computers and the system (system-wide)

• Consult Firewall logs and the Firewall status

The Relation between Firewall Rights and Security Levels

System-level Firewall rights are valid for all users. So you must always use the strictest security settings at this level. Failure to do so may cause inunauthenticated users to have more access than authenticated users.

Firewall rules are added to a firewall policy, which then must be assigned to a user, a group, a computer or implemented at the system level (system-wide policies). System-wide policies, referred to as static policies in the administrator tool, apply to all hosts who are physically connected to the AXS Guard network, while computer, group and user-level firewall policies, which are referred to as dynamic policies in the administrator tool, only apply to the computer, group or user they are assigned to. The illustration below explains the relation between rules, policies and the 4 AXS Guard levels at which policies can be assigned.

Easy Firewall Administration

For your convenience, the AXS Guard Firewall comes with a set of (factory) predefined Firewall Rules, which can be used right out of the box. You can easily create custom Rules with the AXS Guard Firewall GUI or use existing Rules as a template to add your modifications. This is done with the Edit as New function.

Firewall Rules and Policies can be recycled. Rules and / or Policies are not necessarily active when they are created. The AXS Guard offers the possibility to create Rules and Policies for future use and to assign a single Policy to different groups, users or computers. You do not have to remove Rules and Policies which no longer seem relevant. They can be disabled and saved for future use.

• A vast number of Rules can be easily and centrally managed through Policies.

• A Firewall Policy can easily be linked to a large number of users (by using a Firewall Group Policy).

• A Firewall Policy can be recycled (can be saved and enabled or disabled when you need it).

The advantage of Firewall Policies can be demonstrated via the following scenario: An office of 500 users is divided into 6 groups. They all need access to the AXS Guard e-mail system. This means that you have to create 1 firewall rule per e-mail service, i.e. POP, IMAP, SMTP and LDAP (for the address book), which is a total of 4 rules.

• Without Firewall Policies: adding 4 rules to 500 users means 2000 configuration actions.

• With Firewall Policies at the user level: adding 4 rules to 1 policy and subsequently assigning the policy to 500 users means 505 configuration actions.

• With Firewall Policies at the group level: adding 4 rules to 1 policy and subsequently assigning the policy to 6 groups means 11 configuration actions.

Concepts and Principles

Overview

In this chapter, we cover the main principles and concepts of the AXS Guard Firewall system in detail. Topics covered in this chapter include:

• An explanation of Stateful Packet Inspection with Connection Tracking or SPICT.

• The AXS Guard network zones: the Secure LAN, the DMZ and the Internet.

• The AXS Guard data paths: the direction in which data packets travel in relation to the AXS Guard.

• The 4 security levels and the resulting AXS Guard Firewall flow.

• The predefined Firewall Rules and naming conventions, Advanced Firewall Rules and Rule Matching.

• AXS Guard Firewall Policies: The distinction between Static and Dynamic Firewall Policies.

Stateful Packet Inspection & Connection Tracking

About

Connection tracking, also known as stateful packet inspection, is a technique used in network security to monitor and keep track of the state of network connections. It involves examining the packets of a connection and maintaining a record of the connection's current state and status, such as its source and destination addresses, ports, and sequence numbers.

The benefits of connection tracking include:

• Improved security: Connection tracking enables network administrators to monitor network connections and detect potential security threats, such as suspicious network activity, attacks, or unauthorized access attempts. By maintaining a record of the state of network connections, connection tracking can help prevent malicious traffic from entering or leaving a network.

• Enhanced network performance: Connection tracking can help optimize network performance by improving the efficiency of network traffic routing. By keeping track of the state of network connections, connection tracking can quickly identify established connections and allow packets to be forwarded directly to the appropriate destination without additional processing.

• Simplified network management: Connection tracking can help simplify network management by providing a centralized view of network connections and traffic. This can help administrators quickly identify and troubleshoot network issues, and make informed decisions about network policy and configuration.

Overall, connection tracking is an important technique for network security and management. It provides network administrators with greater visibility and control over network traffic, enabling them to improve security, performance, and reliability of their network infrastructure.

Connection States

There are five different connection states: New, Established, Related, Invalid and Assured.

State	Description
New	The first packet of a connection is given this state.
Established	After receiving the first reply on a new packet, the connection state changes to established.
Related	A connection is related when it is associated with an already established connection.
Invalid	This state is assigned to a packet which cannot be identified or which doesn’t have a state.
Assured	A connection becomes assured after it has been established for a certain time.

Example of a Related State connection: FTP

Certain protocols, such as IRC (chat), FTP (File Transfer Protocol), ICQ (instant messaging), etc., require special handling due to their unique connection requirements.

For instance, FTP connections use two different channels to exchange information: one to control the connection and another to send data. The control channel is established first, and then the second channel for data is negotiated within the payload section of the first connection. However, this negotiation is not visible to the firewall, and as a result, the firewall may deny the second connection for security reasons.

To address this problem, connection tracking is used to examine the payload of the first connection. When the negotiation for the data channel is detected, a second connection is initiated based on the first one and assigned a related state. This second connection is then used for data transfer, ensuring that the firewall allows the traffic.

With connection tracking, it becomes possible to establish secure connections for special protocols that require multiple channels. This helps to prevent security issues and ensures that the network operates effectively.

NAT Helpers

In the context of connection tracking, NAT (Network Address Translation) helpers are modules that are used to assist with the tracking of certain types of network protocols that use dynamic port assignments or other non-standard network communication patterns. For information about NAT, see the System Administration guide in the Product Manuals section of this site.

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.

Firewall Zones

About

A firewall zone is a logical grouping of network interfaces or subnets that share a common security policy. Firewalls are often used to control the flow of network traffic between different zones, based on the security policies and rules defined for each zone. There are 3 firewall zones, as explained below.

Zone Types

Network Zone	Description
Secure Zone (SEC)	The combination of all LAN devices and Virtual Private Network devices, e.g. IPsec devices.
Internet Zone (INT)	All network devices that are connected to the Internet.
Demilitarized Zone (DMZ)	Network segment which is accessible from the Internet, but strictly separated from the Secure Zone (secure LAN), e.g. a server hosting a corporate website.

Firewall Data Paths

What is a Data Path?

Firewall data paths are the direction in which data packets travel in relation to the AXS Guard appliance. There are 3 paths: towards, through and output.

Path Types

Field	Description
Towards	Traffic destined for a process running on the AXS Guard appliance, e.g. PPTP and SSTP client traffic.
Through	Traffic traveling through the AXS Guard appliance from one firewall zone to another, e.g. from a client in the Secure LAN to a server in the DMZ or on the Internet.
Output	Network traffic generated by and sent from a process running on the AXS Guard appliance.

Security Levels

The AXS Guard enforces network security on 4 levels:

• The system level: AXS Guard system-wide security, which applies to all users and devices physically connected to the network. Always apply the strictest settings at this level.

• The computer level: AXS Guard security rights associated to a workstation, a server, a printer or any other type of network device.

• The group level: security rights associated to a group of AXS Guard users.

• The user level: security rights associated to a specific AXS Guard user.

Firewall Flow

Overview

Important

System-level Firewall rights apply to all users and computers. Enforce the strictest security at this level.

The various Firewall security levels and Firewall Policies which apply to users who are connected to the network, whether authenticated or not, are referred to as the AXS Guard Firewall flow. Firewall Policies can be implemented at different AXS Guard security levels. A firewall flow exists for every scenario as explained in the following section.

Firewall Flow Scenarios

In this section, we explain the possible AXS Guard Firewall flows for hosts (users) which are physically connected to the network. A diagram of the flows is provided below.

Firewall Flow for authenticated users

The following Firewall flow applies to users with an AXS Guard account who are authenticated. Depending on the user settings, either A, B or C applies, followed by the computer and AXS Guard system policies:

• (A) Use group firewall policies: The firewall rights are based on the user’s AXS Guard group membership OR

• (B) Add to group firewall policies: The user’s Firewall rights are applied first, if any. Then the firewall rights based on the user’s AXS Guard group membership (see A). Additionally, specific firewall rights can be assigned to the user. These specific rights can either be more restrictive or more permissive than the user’s group firewall policies OR

• (C) Overrule group firewall policies: The user’s AXS Guard group firewall policies are overruled and do not apply. Only the user’s specific Firewall rights apply AND

• Computer policies: The user’s AXS Guard computer firewall policies applies (if available). The computer firewall policies are based on the computer’s IP address AND

• System policies: The AXS Guard system-wide policy applies. Traffic which is not allowed at the system level is blocked.

Firewall Flow for non-authenticated users

The following Firewall flow applies to users with an AXS Guard account who are not authenticated.

• Computer policies: If available, the AXS Guard computer Firewall policies apply. The computer Firewall policies are based on a computer’s IP address. No information about the connected user is available, since he/she is not authenticated!

• System policies: The AXS Guard system-wide policy applies. Network traffic which is not allowed at the system level is blocked.

Important

Able highly recommends 2FA, which is the most secure option. Computer policies should only be used for servers accessed by system administrators, e.g. for updates.

Firewall Flow for Computers, Servers, Printers and other Network Devices

The following Firewall flow applies to computers, servers, printers and other network devices in the network. Authentication does not apply.

• Computer policies: If available, the user’s AXS Guard computer Firewall Policies apply. The computer Firewall Policies are linked to a computer’s IP address.

• System policies: The AXS Guard system-wide policy applies. Network traffic which is not allowed at the system level is blocked.

System Level Firewall Flow

This Firewall flow is applies to:

• Non-authenticated users.

• Computer which don’t exist in the AXS Guard Computer list

Only system-wide firewall policies apply. Non-specified traffic is blocked. Maximum security and restrictions must be enforced at this level! Permissions must only be granted at the group / user level.

Example: Secure LANs are shielded from each other

When 2 secure LANs exist in the network, they are shielded from each other by default. This means that network traffic between these networks is not allowed. To allow traffic between these networks, the necessary Rules and Policies must be configured.

Characteristics of Computer-Level Firewall Rights

Computer Firewall rights should only be assigned to servers (ideally with a static IP address) needing specific access to the Internet, e.g. access to Microsoft update servers. In all other cases, the use of user and group Firewall rights are highly recommended.

Following is a list of drawbacks which are inherent to computer-level Firewall rights:

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

• If authentication is bypassed and rights are assigned at the computer level rather than the group or user level, you may be exposed to possible risks, such as misuse of your network’s public IP address or access to resources that would be unauthorized with user authentication.

• A computer list is difficult to maintain, while a user list is easy to maintain (especially in large organizations).

• You cannot assign user level Firewall rights at the computer level, i.e. when different users share a single computer. You need user authentication for this.

• Computer level firewall rights make it harder to troubleshoot problems, since a computer list has to be manually maintained. With authentication, each user name is automatically linked to an IP address and is therefore easier to track and troubleshoot.

Important

Implement user authentication whenever possible. A Single Sign-On Tool is available for the AXS Guard. This tool allows users to seemlessly sign-on with the AXS Guard after logging on to their client PC. See the Single Sign-On Utility (SSO) How To for information. This document is accessible via the Documentation button in the Administrator Tool.

Firewall Rules

What are Firewall Rules?

Important

A Firewall rule is only active when it is enabled, added to a Firewall Policy and assigned to an AXS Guard user, group, computer or system.

A network packet which travels from, towards or through the AXS Guard is first examined by the Firewall. The Firewall contains a set of rules which “decide” what happens to the network packet. The AXS Guard Firewall classifies network packets based on the properties found in the (IP) packet header fields (illustrated below).

If a packet matches the specifications in a Rule, it may be dropped, rejected or accepted. If it doesn’t match any specifications in the Rule, it is checked by a subsequent rule, if present. A packet for which no rule exists is dropped by default at the system level.

Actions such as drop, accept and reject are target actions. Actions are triggered whenever a packet matches certain properties specified in a Firewall Rule. There are several classes of matches: generic matches which apply to all protocols, protocol-specific matches (i.e. for TCP, UDP and ICMP) and special matches.

Certain Firewall configuration items are path-specific. Firewall rules can be recycled, which means they can be saved and assigned to several Policies at your convenience. An existing Firewall Rule is only active when enabled, included in a Policy and assigned to either a user, a group, a computer or the system.

Rule Types and Naming Conventions

There are different types of Firewall Rules, based on the network zones:

• Rules for traffic towards the AXS Guard

• Rules for traffic going through the AXS Guard

• DMZ filter rules

The DMZ filter rules can only be used in the FORWARD path. They specifically regulate traffic from the Internet to the DMZ. For convenience, a set of predefined Firewall rules is readily available on the AXS Guard.

To view the list of all available rules per path:

1. Log on to the AXS Guard

2. Navigate to Firewall > Rules

3. Select the desired set of Rules (Towards / Through / DMZ Filter / Advanced)

4. Select all in the items per page list.

The rule naming convention is based on the different classes of rules.

Prefix	Description
sec-	Traffic destined for a secure network interface.
int-	Traffic destined for an Internet interface.
dmz-	Traffic sent to a DMZ interface.
all-assistance	Rules used for remote assistance (technical support).
fwd-	Traffic traveling through the AXS Guard appliance (forwarded traffic).
dmzf-	DMZ filtering rules.
pr- & pf-	Automatically generated port redirection and port forwarding rules in the filter table.
cm-	Rules pushed on the AXS Guard appliance via the central management system.
predef-	Blocklists, which are updated automatically via the AXS Guard cloud, e.g. Tor exit nodes.
predef-geo-	GeoIP filters, which are updated automatically via the AXS Guard cloud.

Important

The Firewall Rules in the static Policy stat-forwarding are not portv forwarding rules. They are Rules that are automatically added to allow incoming connections on ports you may wish to forward.

Predefined and Custom Firewall Rules

The AXS Guard comes with a set of predefined Rules which can be used out of the box. When installing the AXS Guard for the first time, some of these Rules are already activated at the system level for convenience and optimal security, i.e. Rules allowing ICMP traffic and Able remote support.

Most services can be configured using the supplied predefined Firewall Rules. In some cases, administrators may prefer to create and implement their own Rules.

When creating custom Rules, it is recommended to use the existing naming conventions. This facilitates troubleshooting and Able customer support.

Advanced Firewall Rules

The Firewall system of the AXS Guard is based on iptables. Using advanced Firewall Rules may lead to insecure configurations if you are not familiar with the correct syntax. Be aware that no consequential damages can be sought against Able for network intrusions incurred by the improper use of advanced firewall rules.

Advanced Firewall Rules always have priority over any other Firewall Rules. Misconfiguration may lead to the accidental deactivation of rules required for remote support and automatic upgrades of your appliance.

To create advanced Firewall Rules, refer to the adequate man pages or online documentation, e.g. http://ipset.netfilter.org/iptables.man.html. The following is an example of an advanced rule. Note that the iptables command itself is left out. Only the options and parameters are required.

-A FORWARD -s 192.168.1.100 -d 212.1.250.0/24 -j ACCEPT

Recommendations

Use predefined, basic firewall rules whenever possible. Predefined and custom (basic) firewall rules are easy to configure:

• They can be created with a few simple clicks.

• They don’t require iptables knowledge.

• They are easier to locate in the web-based administration tool.

• They can be quite easily added to or removed from firewall policies.

When to use advanced Rules

Advanced firewall rules should only be used in rare cases, i.e. when predefined or custom rules cannot fulfill the requirements. When in doubt, please contact us for advice or assistance.

Rule Matching

Each Rule contains specifications of the packets to be matched (examined). It also contains a target. As a packet traverses a Firewall Policy, each rule - in its turn - examines it. If a packet does not match a Rule, the packet is checked against the next rule in the Policy, etc. If a packet matches a Rule in the Policy, the defined action (target) is taken. In a Rule, a packet can either be accepted, dropped or rejected.

Match Types

There are 4 types of matching:

• Generic matches

• Protocol matches, e.g. UDP and TCP matches

• Matches based on the firewall data path

• Special matches

Match	Description
Protocol	Only matches when the packet contains the specified protocol.
Source	Only matches when the packet contains the specified source IP. You can add multiple source IP addresses to a rule or define entire subnets to be matched, e.g. 1.2.3.100/24 or 1.2.3.0/255.255.255.0.
Destination	Only matches when the packet contains the specified destination IP or FQDN. You can add multiple destination IP addresses or FQDNs to a rule or define entire subnets to be matched, e.g. 1.2.3.100/24 or 1.2.3.0/255.255.255.0.

Important

Destination FQDNs can only be added to towards and through rules.

Match	Description
Source Port	Only matches when the packet contains the specified source port. A range of ports can be specified using the x:x format, e.g. 1000:1024.
Destination Port	Only matches when the contains the specified destination port. A range of ports can be specified using the x:x format, e.g. 1000:1024.

Match / Path	Description
Towards	Matches the specified interface type, i.e. Secure, DMZ or Internet.
Through	In-interface: the interface where the traffic to be matched arrives. Out-interface: the interface where the traffic to be matched exits.
DMZ	Matches traffic from the Internet to the DMZ; the in- and out-interfaces are already defined and there are no other special matching criteria.

The limit match

There are many different types of special matches. An important special match is the limit match.

The limit match restricts the number of matches to reduce risks associated with Denial Of Service (DoS) attacks. The purpose of DoS attacks is to cripple network services by flooding them with irrelevant traffic.

The limit match has two rules, limit and limit burst. limit determines the number of allowed matches per second, and limit burst determines the data packets which may be accepted above the set limit. Packets that are accepted after the limit has been exceeded are counted cumulatively and not per second. An allowed packet which causes the limit burst threshold to be exceeded, is dropped.

The AXS Guard automatically applies an unmodifiable burst value of twice the limit value. For example, if the limit is set to 1 packet per second, the limit burst value is automatically set to 2 packets.

Rule Target Actions: Accept, Drop, Reject and Log Only

A target action specifies the action to perform on a matched packet. Possible target actions are listed and explained in the table below. Actions are color-coded, allowing system administrators to quickly identify whether an action was blocked or accepted.

Target	Description
Accept	The packet is accepted and may continue its route. Accepted network traffic is not logged by default.
Drop	Prohibits a packet from passing. Sends no response to the sending host. The packet is discarded. Logging is enabled by default.
Reject	Prohibits a packet from passing, but also notifies the sending host. Logging is enabled by default. By rejecting rather than dropping unwanted packets, TCP aborts the connection and the sending application immediately gets a notification that the connection has failed, which is a security risk. The less connection information is provided to potential attackers, the more secure. Use security through obscurity. Use the reject option for troubleshooting and testing only.
Log Only	This target allows administrators to configure firewall rules that log matching packets without taking any action, such as ACCEPT, DROP or REJECT. It is designed to enhance network monitoring and troubleshooting capabilities. Administrators can gain insights into packet flows by observing logged data without directly impacting the network traffic. This feature facilitates effective rule set development, security auditing, and streamlined troubleshooting processes.

Important

Accepted traffic is not logged by default; the log rule target option must be checked for troubleshooting.

Interface Combinations in Firewall Rules

Important

• INT to LAN, INT to INT and DMZ to LAN rules compromize the safety of your network and are not allowed by the AXS Guard.
• For traffic from the Internet to the DMZ, use DMZ filter Rules.

Some restrictions apply when you create Firewall Rules. The AXS Guard Firewall prohibits the combination of certain network interface in its Rules, because they are inherently dangerous and could seriously compromise your network security and integrity.

• If you attempt is made to configure a dangerous / prohibited interface combination in a Firewall Rule, the AXS Guard generates an error message. The rule is not created.

• When the interface combination cannot be validated during the configuration, e.g. when no incoming device is selected, packets are dropped at runtime for invalid combinations.

The illustration below shows the possible interface combinations which are allowed in Firewall Rules. The next image shows the special actions which are triggered depending on the interface combination.

Firewall Policies

What are Firewall Policies?

A Firewall Policy is a set of Firewall Rules, which can be assigned at the different AXS Guard security levels.

Firewall Policies can be static or dynamic. A special type of firewall policy, the DMZ filter policy, is explained in DMZ Filter Policies. Like Rules, Policies can be recycled. This means they can be saved and activated or deactivated when needed.

Important

A Rule always needs to be added to a Policy before it can be used. A Firewall Policy can be composed of only a single Rule.

The Importance of Ordering Rules in a Policy

Important

• The first Rule which matches a packet is always applied, regardless of any following rules.
• Advanced firewall rules always have priority over any other rules and can lead to an insecure network environment if used incorrectly.
• The order of rules in factory default firewall policies cannot be changed.

Rules are added in a list to each policy. A packet is checked against each rule in turn, starting at the top, and if it matches that rule, then an action is taken such as accepting (ACCEPT) or dropping (DROP) the packet. Once a rule has been matched and an action taken, then the packet is processed according to the outcome of that rule and isn’t processed by further rules in the policy. If a packet passes down through all the rules in the policy and reaches the bottom without being matched against any rule, then the default action for that policy is taken. This is referred to as the system policy and may be set to either ACCEPT or DROP the packet.

Based on the illustration below: if the intention is to drop traffic B, Rule 5 must be placed before Rule 2. Another option is to remove Rule 2 from the Policy.

Static Policies

Static firewall policies are active as soon as the AXS Guard firewall starts up. Factory default static policies exist to support certain functionalities, such as remote support and ICMP traffic. We recommend not to disable these policies.

• Static policies are authentication-independent.

• They apply to all users, computers, servers, printers and other network devices physically connected to the AXS Guard network.

• Rules added to a static policy are activated immediately, i.e. they require no authentication.

Dynamic Policies

Dynamic Firewall Policies operate at the user, group or computer level. Two types of Dynamic Firewall Policies exist and are explained below.

Dynamic User and Group Policies

• Dynamic Policies are only activated after a user is successfully authenticated.

• Dynamic Policies only apply to the authenticated user.

When a rule is added to a dynamic user policy while a user is authenticated, the rule is immediately activated. The user is not required to log off to activate the new rule.

Dynamic Computer and Server Policies

Important

Computer policies should only be used for servers with restricted administrator access. For regular computers, enforce user authentication.

• Computer Policies are permanently active, user authentication does not apply in this case.

• The Policy only applies to the listed computer, based on its IP address.

DMZ Filter Policies

The default DMZ filter Policy intercepts and drops all packets coming from an Internet interface and travelling to the DMZ interface. By default, it consists of a single through rule (DMZ filter) to drop all packets. It can be customized by adding links to other DMZ filter rules, which must precede the drop rule in the Policy.

This allows complete control over packets destined to the DMZ. DMZ filter Rules are managed separately.

Policy Naming Conventions

Name	Description
stat-	Static policy name prefix.
stat-XXX	XXX provides an indication about the service or network device, e.g. stat-int pertains to services that are always accessible via Internet Interfaces.

Predefined System Policies in the Input and Towards Path

Important

The predefined Dynamic policies no-restrictions, int-no-restrictions and dmz-no-restrictions should be used for troubleshooting only, never in a live / production environment. These policies eliminate Firewall Security.

The policies below (and the Rules they contain) are active by default. Predefined (factory) policies cannot be modified.

• stat-portredirect: This Policy cannot be modified and contains automatically added port redirection NAT rules.

• stat-z-fix: This Policy cannot be modified.

Rule	Description
all-assistance1 to 5	These Rules enable remote assistance from the supplier, accepting packets received on an AXS Guard Internet interface via ports 22 (SSH), 3128 (AXS Guard proxy) and 82 (AXS Guard administrator tool).
sec-tool 1 and 2	These Rules allow the use of the AXS Guard administrator Tool from the secure LAN and only accepts packets destined to ports 82 and 83 on a secure AXS Guard interface.
sec-ssh	This Rule allows the use of the Secure Shell (SSH) from the secure LAN and only accepts packets for port 22 (SSH) on a secure AXS Guard interface.

• stat-int: This Policy enables services which are permanently available on an AXS Guard Internet interface and adds the following Rules by default:

Rule	Description
int-smtp	This Rule allows the AXS Guard mail system to function on the Internet, only accepting TCP packets which use port 25 (SMTP) and are received by an AXS Guard Internet interface.
int-ident	This Rule enables the Identification Protocol on an AXS Guard Internet interface. The Identification Protocol provides the possibility to determine the identity of a user of a particular TCP connection. Provided with a TCP port number pair, it returns a character string identifying the owner of that connection on the server’s system. The Rule only accepts packets for TCP port 113 on an AXS Guard Internet interface.
int-icmp	This Rule allows ICMP packets to enter the AXS Guard system on an Internet interface, making it possible to use the ping or traceroute command from the Internet towards the AXS Guard. This can be useful for troubleshooting purposes. This Rule only accepts packets which use the ICMP protocol and are received by an AXS Guard Internet interface.

• stat-sec: This Policy enables services which are permanently available on a secure AXS Guard interface and adds the following rules by default:

Rule	Description
sec-ntp	Enables automatic updating of the AXS Guard clock from the secure LAN. Only accepts packets which use TCP and UDP port 123 (NTP) and are received by a secure interface on the AXS Guard.
sec-dns	Allows the AXS Guard DNS system to work on the secure LAN. Only accepts packets which use UDP port 53 (DNS) and are received by an AXS Guard secure interface.
sec-proxy	Allows the AXS Guard proxy system and intranet to work on the secure LAN side. Only accepts packets which use TCP port 3128 (proxy server) and are received by a secure interface on the AXS Guard. This rule also allows ICMP packets coming from a secure LAN interface to enter the AXS Guard. (i.e. ping or traceroute)
sec-icmp	Allows ICMP packets from secure interfaces to be received by the AXS Guard (i.e. ping, traceroute).
sec-dhcp	Allows the AXS Guard to distribute IP addresses to hosts in the secure LAN. Only accepts packets which use TCP port 67 (DHCP) and are received by a secure interface on the AXS Guard.
sec-auth	Allows authentication with the AXS Guard from hosts in the secure LAN.

• stat-dmz: This Policy enables services which are permanently available on an AXS Guard DMZ interface and includes the following rules by default:

Rule	Description
dmz-ident	Allows the Identification Protocol to work on an AXS Guard DMZ interface. Only accepts packets which use TCP port 113 (ident).
dmz-icmp	Allows ICMP packets to enter the AXS Guard from the DMZ. (i.e. ping or traceroute) Only accepts packets which use the ICMP protocol and are received on an AXS Guard DMZ interface.
dmz-smtp	Allows the transmission of e-mail coming from the DMZ zone. Only accepts packets which use TCP port 25 (SMTP) and are received by an AXS Guard DMZ interface.

Predefined System Policies in the Forward and Through Path

• stat-portforward: This policy cannot be modified and contains automatically added NAT rules.

• stat-dmzfilter: This policy contains all DMZ filtering rules. It only has one rule by default, dmzf_drop_all, which drops all data packets. Rules to allow specific network traffic from the Internet to the DMZ should be added to the policy and placed before the default dmzf_drop_all rule.

• The Firewall Rules in the static Policy stat-forward are not port forwarding rules. They are Rules which are automatically added so that the Firewall will allow incoming connections on the ports you wish to forward.

• You can disable port forward Rules by navigating to Network > NAT > Port forwarding.

Rules cannot be added to predefined system Policies, although there are some exceptions.

• Rules can be added to the stat-int, stat-sec, stat-dmz and stat-dmz-filter Policies.

• New Rules for these Policies should have the same input interface.

• For Rules through the AXS Guard, a new static policy has to be created, using the applicable fwd rules.

Info

Adding rules to the predefined system policies facilitates customer support and troubleshooting.

GeoIP Filtering

About

GeoIP filtering or geo-blocking is a technology which blocks Internet traffic based on geographic location. This feature allows you to determine whether users can access your network or applications based on their location.

It also allows you to easily block malicious traffic to and from specific locations as well as manual and automated cyberattacks, which typically flood your system logs.

Filtering is done through the use of dedicated IP address lists, which are updated automatically via the AXS Guard cloud. Note that these lists cannot be modified, only enabled or disabled. GeoIP filters can be recognized by their predef-geo prefix in the firewall and network security logs.

With GeoIP filtering, you can drastically reduce the amount of cyberattacks, spam, ransomware and other cyber threats targeting your organization, simply by blocking specific regions in the world. For best results, it is recommended to only allow traffic to and from countries where you actually conduct business.

Important

This feature must be activated before use and requires a comfort or premium threat protection license. See the section about licensing for additional information.

Level of Operation

Enabling a GeoIP filter means it will affect all AXS Guard users, groups and computers that are connected to the appliance (system-wide configuration).

Whitelists allow you to overrule IP addresses included in GeoIP filters. User, group and computer-level GeoIP filters are currently not supported; you cannot overrule GeoIP filters with user authentication.

Traffic Matching

GeoIP filters are preconfigured to block incoming, outgoing and forwarded traffic.

Firewall Block Lists

About

Block lists are lists of IP addresses or IP ranges that can be blocked or allowed by the AXS Guard firewall. There are predefined and custom lists. Predefined lists contain malicious IP addresses and are automatically updated. They can be recognized by their predef- prefix. Custom lists must be configured from the ground up.

There are two types of block lists: whitelists and blacklists. Blacklists block specific network traffic and can be overruled by whitelists. Whitelists allow network traffic that may otherwise be blocked by a blacklist or a GeoIP filter.

Example:

Assume that a list with a predef- prefix blocks IP address 8.8.8.8. You can overrule this by creating a whitelist with the same IP address.

Level of Operation

Block lists apply to all AXS Guard users, groups and computers and are part of a system-wide configuration. User, group and computer-level block lists are not supported.

Whitelists cannot be used to overrule dynamic firewall policies assigned at the user, group or computer level. They only allow you to overrule IP address entries in blacklists and GeoIP filters.

Traffic Matching

Block lists can be configured to match on incoming, outgoing and forwarded connections.

System-Wide Firewall Checks

Denial Of Service Checks

A Denial-of-service attack (DoS attack) or a distributed denial-of-service attack (DDoS attack) is an attempt to make a computer resource unavailable to its intended users.

Although the means to, motives for, and targets of a DoS attack may vary, they generally consist of the concerted, malevolent efforts of individuals. Their goal is to prevent an Internet service from functioning, temporarily or indefinitely.

When the DoS check is enabled, the AXS Guard firewall defends your network against this type of attack. Enabling this option is highly recommended when running web servers or any other kind of service which is publicly available.

Unclean Packet Checks

A network packet containing a bad checksum or other invalid values in one of its fields is unclean. Hackers sometimes transform packets to gain unauthorized access or to trigger certain unwanted network communication behavior. Packets can also sustain damage when a hardware failure occurs along its route. The AXS Guard Firewall automatically prevents such packets from entering your network.

Global Bad Packet Management

The AXS Guard firewall includes special checks, which detect and manage bad packets at a global level, for instance packets of a TCP connection that was not opened using the 3-way handshake or packets that seem malformed or unusual, i.e. containing bad headers or checksums.

The AXS Guard prevents asymmetric routing. If asymmetric routing occurs, the comment Bad 1 new not syn appears in the Firewall logs.

Firewall Configuration

Accessing the Firewall GUI

In this chapter, we explain how to create firewall rules, add them to policies and assign the policies to users, groups, computers or the system (system-wide policies).

1. Log on to the AXS Guard as explained in the System Administration guide.

2. Navigate to Firewall.

3. Configure your rules, policies and general settings as explained in the following sections.

Denial of Service Checks

1. Go to Firewall > DoS Protection.

2. Configure the options as explained in the table below.

3. Update your configuration.

   

Options	Description
Enable Firewall Denial Of Service checks	Enable to protect your network against Denial of Service (DoS) attacks. When the DoS threshold is exceeded, excess packets will be dropped. AXS Guard monitors and blocks the following packets: ICMP Echo Requests and TCP packets with the RST flag set.
DoS threshold	The threshold at which the DoS protection activates is 25 packets per second, which is the system's default configuration. Activation of the DoS protection will appear in the firewall logs as BAD3: DOS.

Viewing Predefined Firewall Rules and Policies

Important

Predefined Rules and Policies cannot be edited.

Rules:

1. Navigate to Firewall > Rules

2. Click on Towards / Through / DMZ Filter.

3. Click on a Rule to view its configuration details.

Policies:

1. Navigate to Firewall > Policies

2. Click on Static to view all the Static Policies or on Dynamic to view all the Dynamic Policies.

3. Click on a Policy to view the Rule(s) it contains.

Adding a Predefined Firewall Policy to a Group

In this example we explain how to implement the AXS Guard mail policies at the group level.

1. Navigate to Firewall > Policies > Dynamic.

2. Enter mail as a search string and press enter.

3. Verify if the sys-email policy is enabled.

   

4. Navigate to Users & Groups > Groups.

5. Select the desired group from the list.

6. Select the Firewall tab.

7. Click on the Add Firewall Policy button.

8. Use mail as the search string and press enter. A new window will open.

9. Click on sys-email and exit the window.

10. Save your configuration.

    

The sys-email policy is now assigned to users who are members of the selected group.

Creating Custom Firewall Policies

Overview

In this section, we explain how to create and add a custom firewall policy for a Citrix back-end server and how to assign the new policy to a group. This process involves three steps: creating the rule, assigning the rule to a policy, and then assigning the policy to a user, group, computer, or the system.

Creating Rules

1. Go to Firewall > Rules > Through.

2. Click on Add New.

3. Enter the firewall rule parameters as explained in the table below.

4. Save the rule

   

Option	Description
Name	The name of the new firewall rule, e.g. fwd-citrix.
Description	An optional description for the rule.
Enabled	Check to enable the rule. Uncheck to disable the rule.
Device In	The network device receiving traffic.
Device Out	The network device that is forwarding traffic. This option is only available for traffic going through the AXS Guard, i.e. from one network zone to another.
Protocol	Select the protocol to be matched. With TCP and UDP, you can specify source and destination ports.
Source IP	The IP address(es) or range from which traffic originates. Use the CIDR notation to specify a range, e.g. 1.1.1.1/24 You can specify multiple IP addresses or ranges at once by using the Edit as List button. Please ensure each entry is placed on a separate line, or separate each entry with a space.
Destination	Enter a destination FQDN, e.g. example.com, the IP address(es) or range on the receiving end of the connection. Use the CIDR notation to specify a range, e.g. 1.1.1.1/24. You can enter multiple domains, IP addresses or IP address ranges at once by using the Edit as List button. Please ensure each entry is placed on a separate line, or separate each entry with a space. FQDN rules are applicable to both the main domain and its subdomains. This means that you can create a single rule to encompass traffic related to a domain and all of its subdomains. For example, a rule for example.com will also encompass www.example.com, ftp.example.com and so on.
Target	Select the appropriate target for matching traffic. When selecting accept, you have the option to enable Limit this Rule Target, as explained below. If enabled, allowed traffic causing the limit burst threshold to be exceeded will be dropped to prevent attempted DoS attacks.
Log this Rule Target	If enabled, matching traffic is logged.
Limit this Rule Target	The limit match restricts the number of matches to reduce risks associated with Denial Of Service (DoS) attacks. The purpose of DoS attacks is to cripple network services by flooding them with irrelevant traffic. The limit match has two rules, limit and limit burst. limit determines the number of allowed matches per second, and limit burst determines the data packets which may be accepted above the set limit. Packets that are accepted after the limit has been exceeded are counted cumulatively and not per second. An allowed packet which causes the limit burst threshold to be exceeded, is dropped. Administrators can configure the limit rate per second, which is set to 5 target actions by default.
Limit rate per second	This field only appears if you selected to limit the number of target actions (limit this rule target). Enter the number of target actions allowed per second. 5 is the system default configuration.

The rule is now created, but isn’t active yet. To activate the rule, you must add it to a policy. In turn, the policy must be added to the desired AXS Guard security level, e.g. a group or a user.

Important

When creating a firewall rule, you can select different values for the fields Device In and Device Out.

• LAN designates any Ethernet interface that is set to the type secure.
• SEC designates all secure interfaces, e.g. LAN, IPsec and PAX.

Creating Policies

1. Navigate to Firewall > Policies > Dynamic.

2. Click on Add new.

3. Enter the options as explained in the table below.

4. Click on Add Firewall Rule to search and select the created Citrix Rule.

5. Save your configuration.

   

Options	Description
Name	A label for the firewall policy
Description	A description for the firewall policy (optional field).
Enable	Check to enable the policy. Uncheck to disable the policy.
Add Firewall Rule	Click to select the firewall rule(s) to be added to the policy.

The Policy is now created, but needs to be added to the adequate AXS Guard security level to be activated.

Adding a Policy to a Group

1. Navigate to Users & Groups > Groups.

2. Click on the group name to which the Policy should be assigned.

3. Select the Firewall Tab.

4. Click on Add Firewall Policy. A pop-up window appears.

5. Search and select the newly created Firewall Policy (e.g. citrix)

6. Click on Update.

The Policy has now been assigned to the selected group and applies to all users who are members of this group.

Recycling an existing Firewall Policy

In this section we explain how to recycle an existing Firewall Policy with the Edit as New function.

1. Log on to the AXS Guard.

2. Navigate to Firewall > Policies and select the desired category (Static or Dynamic).

3. Enter a search string, e.g. citrix and press enter.

4. Click on the Policy.

5. Click on the Edit as New button and modify the Policy accordingly.

6. Click on Save when finished.

7. Add the Policy to the desired AXS Guard security level.

Important

Similarly, you can also use Edit as New for Firewall Rules.

Changing the Rule Order in a Policy

We now explain how to change the order of Firewall Rules in a Policy.

1. Go to Firewall > Policies and select the desired category, i.e. Static or Dynamic.

2. Select the appropriate firewall policy.

3. Drag and drop the rules until you reach the desired order.

4. Save your configuration.

   

Important

You cannot change the rule order in predefined firewall policies.

Firewall Rule Logging Options

1. Go to Firewall > Rules and select the appropriate category (Towards / Through / DMZ Filter).

2. Click on the specific rule for which logging must be enabled or disabled.

3. Check Log this rule target to enable logging. Uncheck to disable logging.

4. Click on Save when finished.

Important

Allowed traffic is not logged by default. Enable the log rule target option to investigate accepted traffic.

Adding Rules at the System Level

Services on the AXS Guard

Important

System-level Firewall Rights apply to all users and computers. Use the strictest security.

In this example, we explain the procedure to add a Rule to a predefined static Policy, i.e. the system level. The goal is to allow access from the secure LAN to a service running on the AXS Guard.

1. Log on to the AXS Guard.

2. Navigate to Firewall > Policies > Static.

3. Enter stat-sec as a search string and press enter.

4. Click on stat-sec.

5. Click on the Add Firewall Rule button.

6. Click on the Rule which must be added (e.g.sec-smtp) and close the window.

7. Click on Update to add the Rule to the Policy.

SMTP is now available for all users in the secure LAN.

Services in the DMZ

Important

• System-level Firewall Rights apply to all users and computers. Use the strictest security.
• Only use DMZ filter rules to allow traffic from the Internet to the DMZ.

In this example, we explain the procedure to add a Rule to a predefined static Policy, i.e. the system level. The goal is to enable access from the Internet to a service running in the DMZ.

1. Log on to the AXS Guard.

2. Navigate to Firewall > Policies > Static.

3. Enter dmz as a search string and press enter.

4. Click on stat-dmzf.

5. Click on the Add Firewall Rule button.

6. Click on the Rule which should be added (e.g. dmzf-sweb) and close the window.

7. Click on Update to add the rules to the policy.

HTTPS services in the DMZ are now available from the Internet.

Enabling NAT Helpers

1. Navigate to Network > NAT > NAT Helpers.

2. Enable the NAT helpers that are required in your network.

3. Click on Update to finish.

   

Configuring GeoIP Filtering

Feature Activation

Important

The GeoIP feature must be activated before use and requires a comfort or premium threat protection license.

1. Go to System => Feature Activation.
2. Enable GeoIP Filtering.
3. Update your configuration.

Blocking Countries and Regions

1. Go to GeoIP > Filters.

2. Select the countries to be blocked.

Important

• Whitelists allow you to overrule IP entries in GeoIP filters.
• You can sort enabled GeoIP filters by clicking on the Enabled header.

Configuring Block Lists (Blacklists & Whitelists)

1. Go to Firewall > Block lists.

2. Click on the + button to create a new block list (or click on a custom block list name in the table and then on edit as new).

3. Configure the block list options and parameters as explained in the table below.

4. Update your configuration.

   

Parameter	Description
Name	Enter a name for the block list. Predefined block lists have a predef- prefix. It is recommended to use another prefix for custom block lists, e.g. custom-
Description	Enter a description explaining the purpose of the block list (optional).
Enabled	Check to enable the block list. Uncheck to disable it.
Type	Select the appropriate type from the drop-down list: Blacklists block specific network traffic and can be overruled by whitelists. Whitelists allow network traffic that may otherwise be blocked by IP entries in a blacklist or GeoIP filters. Note that whitelists cannot be used to overrule dynamic firewall policies assigned at the user, group or computer level.
Apply to incoming connections	Applies to traffic originating from the specified IP address(es) towards the appliance.
Apply to outgoing connections	Applies to traffic leaving the appliance and destined for the specified IP address(es).
Apply to forwarded connections	Applies to traffic going through the appliance, i.e. from one network zone to another.
Log traffic.	Enable this option to log matching traffic under Firewall > Logs. When this option is enabled for a whitelist, matching traffic will be logged as BLOCKLIST BYPASS.
IP/Domain List	Add IP addresses, networks or domains that should be blocked (blacklist) or allowed (whitelist). Valid values are: IP addresses IP ranges (CIDR notation), e.g. 192.0.2.0/24 Domains & FQDNs AXS Guard will resolve FQDNs and add the resulting IP addresses to the rule. If a subdomain is resolved by the AXS Guard appliance, the resulting IP address is also added to the rule. For example, axsguard.com will match: axsguard.com cloud.axsguard.com The IP address resolution status is indicated by a color: Black Resolving succeeded Orange Resolving queued Red Resolving failed

Firewall Tools

Overview

The number of firewall rules can become quite large, especially in large networks. Use the firewall search tool to easily locate configured firewall rules.

Looking up Rules with Search Filters

1. Go to Firewall > Tools > Search.

2. Specify the filter properties as explained in the table below.

3. Click on Search.

   

Filter	Description
Protocol	The protocol to be matched by the query.
Source IP	The source IP to be matched by the query. Use the CIDR notation to specify an IP range.
Source Port	The source port to be matched by the query.
Destination IP	The destination IP to be matched by the query. Use the CIDR notation to specify an IP range.
Destination Port	The destination port to be matched by the query.
Target	Select the desired target from the drop-down list.
Device IN	The receiving device to be matched by the query. Select the appropriate device from the drop-down list.
Device OUT	The forwarding device to be matched by the query. Select the appropriate device from the drop-down list.

Firewall Logging and Status

Example of a Firewall Log

The firewall logs show packets which are dropped or rejected. To protect AXS Guard from Denial Of Service attacks, a limit for the number of logs to be recorded is set, meaning not every single dropped or rejected packet is logged. Typical firewall log entries are shown below.

1. Go to Firewall > Logs

2. Select the appropriate log date in the list.

Example of a raw Firewall Log

time     in     out    proto  len sip             spt   dip             dpt   flags                comment
00:00:02 eth4   eth1   TCP     64 195.211.11.19   3591  195.0.83.41     445   DF SYN                FORWARD DROP:
00:00:05 eth4          UDP     75 67.248.44.172   24874 194.78.97.254   51413                       INPUT DROP:
00:00:07 eth4   eth1   TCP     60 201.51.233.168  2593  195.0.83.91     445   DF SYN                FORWARD DROP:
00:00:11 eth4          TCP     60 91.183.93.188   58570 194.78.97.254   2525  DF SYN                INPUT DROP:
00:00:14 eth4   eth1   TCP     48 111.68.26.2     4710  195.0.83.123    445   DF SYN                FORWARD DROP:
00:00:17 eth0          UDP    116 10.32.64.150    17500 255.255.255.255 17500 DF                    INPUT DROP:
00:00:20 eth4   eth1   TCP     60 46.105.24.61    41373 195.0.83.11     80    DF SYN                FORWARD DROP:
00:00:23 eth4          TCP     52 186.108.65.41   61873 194.78.97.254   51413 DF SYN                INPUT DROP:
00:00:25 eth4   eth1   TCP     48 95.25.52.161    2957  195.0.83.105    445   DF SYN                FORWARD DROP:

Example of a parsed Firewall Log

Important

Allowed traffic is not logged by default. To log allowed traffic, the log this rule target option must be enabled in the appropriate firewall rule. Administrators can also use the log only target for troubleshooting.

Understanding Fields and Entries

Field	Description
time	The time when the logged packet was dropped or rejected.
in and out	The interfaces on which a dropped or rejected packet was received and the interfaces via which a dropped or rejected packet was supposed to leave the AXS Guard network.
protocol	The protocol used by the dropped or rejected packet.
Source IP address and Destination IP address	The source and destination IP address of the dropped or rejected packet. If the source or destination IP address belongs to a locally configured LAN with DHCP enabled, the log will display hostnames instead of IP addresses.
Destination Domain	Shows the domain names associated with the IP addresses found in DNS responses. This makes it easier to identify traffic destinations that are being processed by the firewall.
spt and dpt	The source and destination port used by the dropped or rejected packet.
flags	The enabled flags of the dropped or rejected packet. For information about TCP and IP flags, see the appropriate online resources.
length	The size or length of the packet, measured in bytes.
action	The target action refers to the action that the firewall has taken when a network packet matched the conditions specified in a rule. The target action determines whether packets should be allowed, rejected, dropped or only logged. Actions are color-coded, allowing system administrators to quickly identify whether an action was blocked or accepted. Also see the table below for additional information on actions and reasons.
reason	Indicates why traffic was dropped or rejected and allows system administrators to easily pinpoint the matching rule or IP address list. Note that this requires the log this rule target option to be enabled in the firewall rule. Also see the table below for additional information on actions and reasons.

Actions & Reasons	Description
INPUT DROP	This message indicates that a packet was dropped in the INPUT chain of the firewall.
INPUT REJECT	This message indicates that a packet was rejected in the INPUT chain of the firewall and a notification was sent to the source of the packet.
INPUT LOG	This message indicates that a packet was logged in the INPUT chain of the firewall.
FORWARD DROP	This message indicates that a packet was dropped in the FORWARD chain of the firewall.
FORWARD REJECT	This message indicates that a packet was rejected in the FORWARD chain of the firewall and a notification was sent to the source of the packet.
FORWARD LOG	This message indicates that a packet was logged in the FORWARD chain of the firewall.
FORWARD ACCEPT	This message indicates that a packet was accepted in the FORWARD chain of the firewall.
BLOCKLIST BYPASS	This message indicates that logging has been enabled for a whitelist, and it signifies that the traffic has been successfully matched against this whitelist.
BAD1: New not syn	This messages indicates that a packet matched a rule in the _BAD_PKTS chain of the firewall, which checks for TCP packets with the NEW state and in which the SYN flag is not set. This match indicates a bad TCP connection, so the packet is dropped.
BAD2: Unclean	This message indicates that a packet matched a rule in the _BAD_PKTS chain of the firewall, which checks for unclean packets that seem malformed or unusual, i.e. bad packet headers.
BAD3: DOS	This message is an indication of an attempted denial of service (DoS) attack. See the section on Denial of Service checks.

Network Security Logs

About

The network security logs are a compilation of information related to traffic that was processed by the AXS Guard firewall, the IPS, SecureDNS, GeoIP filtering and the application control system.

Accessing the Network Security Logs

1. Go to System > Logs > Network Security.

2. Click on the desired log file to open it.

   

Field	Description
Time	The time at which the log entry was created.
Triggered by	The feature that blocked the network traffic, e.g. Application Control, GeoIP filtering, etc.
In	The network device on the receiving end of the connection.
Out	The forwarding network device.
Source IP	The IP of the sending host.
Source Port	The source port used by the sending host.
Destination IP	The IP of the receiving host.
Destination Port	The destination port on the receiving host.
Action	The target action taken by the security feature in the Triggered by field, e.g. INPUT DROP. Actions are color-coded, allowing system administrators to quickly identify whether an action was blocked or accepted.
Reason	Indicates the reason why traffic was blocked or accepted. In case GeoIP filtering is used, the name of the GeoIP filter will also be shown, e.g. blocklist=predef-geo-us (USA).

What is the Firewall Status?

The AXS Guard Firewall status shows useful information about active connections and network traffic which is being filtered. The filter status is a live view of the AXS Guard Firewall flow.

Network Flow Viewer

About

The flow viewer allows you to consult 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

Usage

1. Go to Network > Tools

2. Select "Flow Viewer"

   

3. Click on an empty space in a row to view details about a connection.

   

Connection Tracking

The firewall connection status page provides a centralized view of current network connections and their state.

1. Log on to your AXS Guard appliance.

2. Go to Firewall > Status > Connections.

   

Color	Description
Green	The peer is connected to a secure device.
Red	The peer is connected to an Internet device.
Yellow	The peer is connected to a DMZ device.
Blue	The peer is AXS Guard itself.
Purple	The host/port is translated (SNAT/DNAT/...).

Accessing the Filter Status

The filter status shows a live flow chart of the firewall checks which apply to a certain path (input, forward and output). The table below explains the different filters which can be consulted.

Filter	Description
INPUT	Shows the filter status of traffic coming to the AXS Guard appliance (INPUT Chain).
FORWARD	Shows the filter status of traffic which is being forwarded from one network zone to another by the AXS Guard appliance (FORWARD Chain).
OUTPUT	Shows the filter status of traffic leaving the AXS Guard appliance (OUTPUT Chain).

To access the Filters Status:

1. Log on to the AXS Guard.

2. Navigate to Firewall > Status.

3. Click on the Desired Filter (Input, Forward or Output).

   

Troubleshooting

My application does not work although I have created a firewall rule for it

Use the following chart to troubleshoot any Firewall problem:

• Telnet: Use the telnet command to verify whether the problem is application related or connection related, for instance telnet 192.168.1.50 25 for SMTP. (Use: telnet + IP address or DNS name, followed by a space and the service port number). See the appropriate telnet documentation for more details.

• Client Application: If a telnet connection can be established, the problem is application related and the client’s application settings should be checked, for instance the browser’s proxy settings. Refer to the application’s documentation for assistance.

• Firewall Log: If a telnet connection cannot be established, check the Firewall Logs by navigating to Firewall > Logs. Click on the applicable date and enter the appropriate search string.

• Accept: If you wish to check log entries related to a certain rule for which the target is set to accept, make sure to verify whether the Log this rule target option is checked in the firewall rule. Accepted packets are not logged by default. If the log shows the specific traffic as accepted, the problem is not firewall or rule related. The related AXS Guard or Back-End service should be checked. Refer to the appropriate AXS Guard Feature How To guides and application logs or the Back-End server’s documentation for further assistance.

• Drop / Reject: If traffic - which normally should be allowed - is dropped, check the rule hierarchy in the firewall policy. The order in which rules are entered in a policy affects the policy behavior. Adding a rule to a policy which allows certain traffic has no effect when that rule is preceded by another rule dropping or rejecting the same traffic. The way a Rule is configured may also cause problems. Make sure to verify al fields of the rule, by navigating to Firewall > Rules > Towards / Through / DMZ Filter.

• Not Logged: Use the tcpdump command as explained in the AXS Guard CLI guide, e.g. tcpdump -ni eth0 (Advanced troubleshooting only). For detailed information about tcpdump, see the appropriate man pages and online resources.

The Firewall log file shows: Bad 1 new not syn

This messages indicates that a packet matched a rule in the _BAD_PKTS chain of the firewall, which checks for TCP packets in the New state and the SYN flag not set. This match signifies a bad TCP connection setup (assymmetric routing), so the packet was dropped.

Firewall log file shown: BAD2: unclean

This message indicates that a packet matched a rule in the _BAD_PKTS chain of the firewall, which checks for unclean packets which seem malformed or unusual, containing bad headers or checksums. The packet is therefore dropped.

I have several secure LANs which cannot communicate

By default, the AXS Guard Firewall does not allow traffic between different secure LANs (network segments). Adequate firewall Rules and Policies must be created and assigned to enable traffic between your secure LANs.

I cannot add or modify a rule in a policy

Modifications are not allowed in (factory) predefined policies, except the ones as mentioned in Policy Naming Conventions.

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