Skip to content

Firewall Guide

Introduction

About this Document

This document is an introductory guide to the AXS Guard Firewall usage and configuration. It is intended for system administrators or technical personnel with a good understanding of network security and TCP/IP. For in-depth information about the AXS Guard Firewall architecture, concepts and operation, please refer to the AXS Guard Advanced Firewall Concepts guide.

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.

Relation between Rules, Policies and User Levels

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 with Connection Tracking

What is SPICT?

An important principle behind the AXS Guard firewall is the use of connection tracking. Connection tracking refers to the ability to maintain connection information, such as the source and destination IP address, port number pairs (also known as socket pairs), protocol types, connection states, timeouts, etc. in memory tables. This property is known as stateful. Stateful firewalling is inherently more secure than its "stateless" counterpart, simple packet filtering. Connection tracking also considerably accelerates firewall checks (up to 90%), since packets belonging to a same established or assured connection do not require additional firewall checking. In the illustration below, we assume that the HTTP traffic is allowed by the AXS Guard Firewall.

logo

Five different connection states exist: New, Established, Related, Invalid and Assured.

Connection States

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.

The related state is used to handle special protocols such as IRC (chat), FTP (File Transfer Protocol), ICQ (instant messaging), etc.

An FTP connection uses two different channels to exchange information: one to control the connection and one to send data. When the control channel is successfully established, a second channel for the data is negotiated in the payload section (data section) of the first connection. The Firewall isn’t aware of this, so the second connection is denied for security. This problem is resolved by adding a module to the connection tracking system, which examines the payload of the first connection. Upon detection of the negotiation, a second connection is triggered based on the first one and given the related state. This second connection is then used to transfer the data.

NAT Helpers

NAT helpers automatically add the necessary connection information to the connection tracking tables for specific protocols so that any associated connections can be properly NATed. For information about NAT, see the System Administration How To.

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 network or firewall zone is a physical network (subnetwork) to which the AXS Guard is connected. The 4 AXS Guard network zones are explained below.

Zone Types

Network Zone Description

LAN

The AXS Guard Ethernet ports connected to the (to be secured) Local Area Network.

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), i.e. a server hosting a corporate website.

logo

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. Three main paths exist: the towards, the through and the output path.

Path Types

Field Description

Towards AXS Guard

Traffic destined for a process running on the AXS Guard appliance, e.g. PPTP traffic.

Through AXS Guard

Traffic traveling through the AXS Guard appliance from one network zone to another, e.g. from a client in the Secure LAN to a server in the DMZ.

Output

Network traffic generated by and sent from a process running on the AXS Guard appliance.

logo

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.

logo

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.

logo

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

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

  • TCP and UDP matches

  • Matches based on the data path (see Firewall Data Paths)

  • 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. You can add multiple destination 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.

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 and Reject

A target action specifies the action to perform on a matched packet. Possible target actions are listed and explained in the table below.

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.

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.

img

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.

image

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.

Firewall Block Lists

About

Block lists Predefined block lists Custom block lists Block list types White list Black list

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: white lists and black lists. Black lists block specific network traffic and can be overruled by white lists. White lists allow network traffic that may otherwise be blocked by a black list.

Example:

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

Geo-blocking

Geo-blocking is a technology which limits Internet traffic based on geographic location. It allows you to determine whether users can access your network or applications based on their specific location. This feature also allows you to easily block malicious traffic from unauthorized locations as well as automated cyberattacks, which typically flood your system logs.

Geo-blocking is done through the use of dedicated blocklists, which can be easily recognized by their predef-geo prefix. They are updated automatically via the AXS Guard cloud and cannot be modified, only enabled or disabled.

You can drastically reduce the level of malicious attacks, spam, ransomware and other threats by limiting traffic to countries where you actually conduct business.

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-specific block lists are not supported.

White lists cannot be used to overrule dynamic firewall policies assigned at the user, group or computer level. They only allow you to overrule IP entries in black lists.

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, it generally consists of the concerted, malevolent efforts of a person(s) or 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. 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. Check the "Enable Firewall Denial of Service checks" option to block DoS attacks.

  3. Update your configuration.

    DoS Checks

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.

Overview of Predefined Rules

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.

Overview of Predefined Policies

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.

    Looking up and Enabling a Firewall Policy

  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.

    Group Level Firewall Policy 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 takes three steps.

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. Select TCP and Destination Port 1494 (used by Citrix).

  4. Save the rule

    Creating a New Firewall 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. In case of TCP and UDP, you can specify source and destination ports.

Source IP

The IP address(es) or subnet from which traffic originates. Use the CIDR notation to specify a subnet, e.g. 1.1.1.1/24 You can specify multiple IP addresses or ranges at once with a comma-separated list, e.g. 1.1.1.1/24,2.2.2.2/16,3.3.3.3/8

Destination IP

The IP address(es) or subnet on the receiving end of the connection. Use the CIDR notation to specify a subnet, e.g. 1.1.1.1/24 You can specify multiple IP addresses or ranges at once with a comma-separated list, e.g. 1.1.1.1/24,2.2.2.2/16,3.3.3.3/8

Target

Select the appropriate target for matching traffic. When selecting accept, you have the option to enable Limit this Rule Target. If this option is enabled, allowed traffic causing the limit burst threshold to be exceeded will be dropped to prevent attempted DoS attacks. The AXS Guard limit burst threshold is a hard coded variable and cannot be modified.

Log this Rule Target

If enabled, matching traffic is logged.

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.

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.

    Creating a New Firewall Policy

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.

    Changing the Order of Rules in a Policy

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.

Enabling and Disabling Firewall Logging

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.

    Enabling NAT Helpers

Configuring Block Lists

  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.

    Creating New Block Lists

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:

  • Black lists block specific network traffic and can be overruled by white lists.

  • White lists allow network traffic that may otherwise be blocked by IP entries in a black list. Note that white lists 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.

List

Add individual IP addresses or network ranges. Use the CIDR notation to specify network ranges, e.g. 192.168.0.1/24. If no netmask is specified, /32 is automatically assumed.

Note: Use a comma-separated list to add multiple IP addresses simultaneously.

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.

    Firewall Rule 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 the 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. A typical log entry is 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

Accepted traffic is not logged by default. The log rule target option must be checked in the rule.

Field and Comment Entries in the Firewall Log

Field Description

time

The time when the logged packet was dropped or rejected.

in and out

The interfaces on which the dropped or rejected packet was received and the interface on which the packet should have left the AXS Guard.

proto

The protocol used by the dropped or rejected packet.

len

The size of the dropped or rejected packet.

sip and dip

The source and destination IP address of the dropped or rejected packet.

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.

comment

This field provides more information about the action that was performed on a given packet.

Comment 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 dropped in the INPUT chain of the firewall and a notification was sent to the source of the packet.

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 dropped in the FORWARD chain of the firewall and a notification was sent to the source of the packet.

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 headers)

BAD3: DOS

This message is an indication of an attempted denial of service (DoS) attack.

Network Security Logs

About

The network security logs are a compilation of information related to traffic dropped by the AXS Guard firewall, IPS and 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.

    Network Security Logs

Field Description

Time

The time at which the log entry was created.

Triggered by

The process that blocked the network traffic.

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.

Comment

The action taken by the application in the Triggered by field, e.g. INPUT DROP.

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"

    Network Flow Viewer

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

    Connection Details

Connection Tracking Information

  1. Log on to the AXS Guard.

  2. Go to Firewall > Status > Connections.

    Connection Tracking Screen

This shows the tracking of all connections to and from AXS Guard.

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

    Example of a Filter Screen

Troubleshooting

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

Use the following chart to troubleshoot any Firewall problem:

Firewall Troubleshooting Chart

  • 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

Back to top