Firewall Guide

Introduction

About this Document

This document serves as an introduction to the AXS Guard firewall. It is intended for system administrators and technical personnel who are already familiar with network security and TCP/IP.

The AXS Guard firewall is built on the iptables framework. As part of the Netfilter subsystem in the Linux kernel, iptables enables fine-grained control over packet filtering, network address translation (NAT), and traffic classification.

By leveraging this proven technology, the AXS Guard firewall offers stateful inspection, connection tracking, and customizable rule sets that allow administrators to define precise security policies across multiple network zones.

Examples used in this Guide

All examples and configurations in this guide assume you are logged in as an advanced administrator. Some options may not be visible if you have lower access privileges (e.g., full administrator or regular user).

Due to ongoing software development and documentation updates, the screenshots in this guide might look slightly different from the current user interface.

Essential Terminology

Overview

This section will lay the groundwork for understanding and configuring your AXS Guard firewall by defining key terms and concepts that appear throughout this guide. A firm grasp of this terminology is crucial for successful firewall implementation.

Topics covered in this section include:

• A general definition of firewalls and their purpose.
• Essential terminology for understanding how the AXS Guard firewall operates.
• Predefined rules & policies.

What are Firewalls?

A firewall acts as a security barrier, safeguarding your network from unauthorized access. It achieves this by examining network traffic and blocking any connections that are unwanted or not authorized. In the following section, we will briefly explain some key terminology to enhance your understanding of the AXS Guard firewall's operation and configuration.

Security Structure

Rules

A rule is the most granular element of the AXS Guard firewall. It describes the traffic to be matched and dictates how that traffic is processed – whether it is accepted, dropped, or logged. Rules must be added to a policy to be enforced.

Policies

A policy is a logical collection of one or multiple firewall rules, organized in a specific, critical order. Policies can be applied to various AXS Guard security levels, i.e. individual users, groups, computers, or the system level.

Security Levels

The level defines the scope at which a firewall policy is applied (user, group, computer, or system-wide). System-wide settings should be the most stringent by default, as they apply to all connected devices and computers. This aligns with the principle of Zero Trust.

Firewall Rights

This is a general term referring to the firewall permissions and restrictions applied at a specific security level, determining what type of traffic a given user, group, or computer is allowed or forbidden to send across the network.

Firewall Policy Scopes

Firewall rules must be added to a firewall policy to be enforceable. These policies, in turn, must be assigned to a user, a group, a computer, or implemented at the system level. These assignment levels define the scope of the policy.

Static Policies

System-wide policies, referred to as static policies within the administrator tool, govern the network traffic of all hosts connected to the AXS Guard LAN. They are also required to allow internet access to AXS Guard services, such as OpenVPN. On the LAN side, these policies are enforced independently of user authentication and mandate the implementation of the most stringent security to align with the zero-trust model.

Dynamic Policies

In contrast, computer, group, and user-level firewall policies, referred to as dynamic policies in the administrator tool, only apply to a specific computer, group, or user to whom they are assigned. User and group policies are enforced after successful authentication with the AXS Guard appliance (identity-based security). The illustration below explains the relationship between rules, policies, and the four AXS Guard levels at which policies can be assigned.

Predefined Rules & Policies

Introduction

The AXS Guard firewall comes with a set of factory-predefined rules and policies that you can use right out of the box. You can easily create custom rules and policies using the AXS Guard's web-based administrator tool or the AXS Guard Cloud, or you can use predefined ones as a template for your own modifications. This is done with the Edit as New function.

Firewall rules and policies can be recycled and aren't necessarily active right after creation. AXS Guard offers the flexibility to create rules and policies for future use, and to assign a single policy to different groups, users, or computers. There's no need to delete rules or policies that are no longer immediately relevant; you can simply disable them.

The Power of Policies

Policies allow for the easy and central management of a vast number of rules. Here are some key advantages:

• Centralized Management: A large number of related rules can be managed efficiently through policies.
• Scalability: A single firewall policy can be linked to many users (e.g., by using a group policy).
• Flexibility: Policies are recyclable, meaning they can be saved, enabled, or disabled as needed.

Example

Consider the following scenario to see the advantage of firewall policies: An office with 500 users is divided into 6 groups. All users need access to the AXS Guard email system, which consists of 4 specific email services: POP, IMAP, SMTP, and LDAP (for the address book). This translates to 4 firewall rules.

• Without firewall policies: Adding these 4 rules individually to 500 users would require 2,000 configuration actions (4 rules x 500 users).
• With firewall policies at the user level: You would add the 4 rules to 1 policy and then assign that policy to 500 users, resulting in just 505 configuration actions (4 rules + 1 policy creation + 500 assignments).
• With firewall policies at the group Level: The most efficient approach involves adding the 4 rules to 1 policy and then assigning that policy to the 6 groups. This drastically reduces the effort to only 11 configuration actions (4 rules + 1 policy creation + 6 assignments).

Firewall Concepts

SPI & Connection Tracking

About

Connection tracking, also known as stateful packet inspection (SPI), 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.

Benefits

• 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 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 security policies.

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 5 different connection states: New, Established, Related, Invalid and Assured.

State	Description
New	This is the state for the first packet of a connection. It indicates that the firewall's connection tracking system has not seen any previous packets belonging to this flow. For TCP, this is typically the SYN packet.
Established	After the initial handshake (e.g., SYN-ACK for TCP) and traffic has been seen in both directions, the connection state changes to Established. This means the firewall recognizes it as an ongoing, legitimate conversation.
Related	This state is for connections that are related to an already established connection but aren't part of the same primary flow. Common examples include FTP data connections or ICMP error messages responding to an Established connection. This often requires "connection helpers" or ALGs (Application Layer Gateways) in the firewall to understand the relationship.
Invalid	This state is assigned to packets that cannot be identified as belonging to any known connection, or that are malformed, out of sequence, or otherwise "unexpected." These packets are often dropped by firewalls as a security measure.
Assured	This state is an internal flag within the connection tracking system. It means that a connection has been "confirmed" or "assured" after a certain amount of successful two-way traffic. This is important for managing the connection tracking table; "assured" connections are less likely to be dropped if the system starts running out of tracking entries.

FTP Example

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.

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, 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 used to control the flow of network traffic between different zones. There are three 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 and OpenVPN 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.

Important

By default, separate LANs within your network are shielded from each other, meaning network traffic between them is not allowed. To allow traffic, you'll need to configure the necessary rules and policies.

Traffic Flows

Definition

Traffic flows describe the direction of network traffic as it is processed by the AXS Guard firewall, based on the traffic's origin and destination. These flows determine how traffic interacts with the iptables chains (INPUT, FORWARD, and OUTPUT) and influence the security policies applied. There are three primary types of traffic flows: towards, through and output.

Flow Types

Flow Type	Description	iptables Chain
Towards	Traffic destined for a service running on the AXS Guard appliance (e.g., OpenVPN or SMTP).	INPUT
Through	Traffic passing through the appliance from one network zone to another (e.g., LAN to DMZ or Internet).	FORWARD
Output	Traffic generated by the AXS Guard appliance itself (e.g., system updates, DNS queries).	OUTPUT

Security Levels

AXS Guard enforces network security on 4 levels:

System Level

AXS Guard system-wide security, which applies to all users and devices that are connected to the LAN. Always apply the strictest settings at this level. Ideally, user authentication should always be enforced and nothing should be allowed by default at this level (zero trust).

Computer Level

These are AXS Guard security rights assigned to a workstation, server, printer, or any other networked device in the secure LAN. They should be limited to the minimum necessary, such as access to update servers on the Internet. For workstations, it is recommended to enforce user authentication and assign appropriate group- and user-level access rights (identity-based firewalling).

Group Level

Pertains to security rights associated with a group of AXS Guard users.

User Level

User-level security rights are associated with a specific AXS Guard user and can be used to override rights assigned at the group level, for example if a user needs specific job-related access privileges which are not defined at the group level.

Identity-based Security

Introduction

System-level firewall rules apply to all users and devices, regardless of identity, and therefore should enforce the strictest baseline security measures (zero trust).

The AXS Guard firewall is designed to enforce identity-based security, where firewall policies are dynamically applied based on the authenticated user or device. These policies — collectively referred to as AXS Guard firewall scenarios — govern network access for users depending on their authentication status and assigned network privileges.

Firewall policies can be tailored and enforced at multiple security levels within the AXS Guard system, enabling granular control over who can access what resources under different scenarios. Each possible user or device state corresponds to a distinct firewall scenario, as explained in the following section.

Scenarios

This section explains the various AXS Guard firewall scenarios that apply to users and devices which are connected to the secure LAN. A diagram illustrating these scenarios is included below.

Authenticated Users

This scenario applies to authenticated users. Depending on the user's configuration, one of the following firewall policy application methods (A, B, or C) will be used, always followed by the computer and AXS Guard system policies:

• A. Group Firewall Policies: The user's firewall rights are based solely on their AXS Guard group membership.
• B. Combined Group and User Policies: The user's specific firewall rights are applied first (if any). These are then combined with the firewall rights derived from their AXS Guard group membership (as in A). Additionally, specific firewall rights can be assigned directly to users, which can either be more restrictive or more permissive than their group policies.
• C. Overruling User Policies: The user's group firewall policies are entirely overruled and do not apply. Only the user's specifically assigned firewall rights are in effect.

In addition to the above, the following policies are always applied:

• Computer Policies: The user's AXS Guard computer firewall policies apply (if configured). These policies are based on the computer's IP address.
• System Policies: The AXS Guard system-wide policy applies. Any traffic not explicitly allowed at the system level is blocked (zero trust).

Unauthenticated Users

This scenario applies to unauthenticated users. Since no user information is available, only the following policies are applied:

• Computer Policies: If configured, AXS Guard computer firewall policies apply, based on the computer's IP address.
• System Policies: The AXS Guard system-wide policy applies. Any network traffic not explicitly allowed at this level is blocked (zero trust).

Computer-level Security

This firewall scenario applies to all computers, servers, printers, tablets and other networked devices. Authentication does not apply in this case.

• Computer Policies: If configured, AXS Guard computer firewall policies apply. These policies are linked to a device's IP address.
• System Policies: The AXS Guard system-wide policy applies. Any network traffic not explicitly allowed at this level is blocked (zero trust).

Best Practices for Computer Firewall Rights

Computer firewall rights should ideally only be assigned to servers or devices with static IP addresses that require specific, limited access to the internet (e.g., to Microsoft update servers). In all other scenarios, using user and group-based firewall rights is highly recommended (identity-based firewalling).

Relying heavily on computer-level firewall rights presents several inherent drawbacks:

• Security Risk: Bypassing the authentication process (user identification) is inherently insecure.
• Exposure to Misuse: If rights are assigned at the computer level rather than the user or group level, your network may be exposed to risks like the misuse of the computer's IP address or unauthorized access to network resources.
• Maintenance Challenges: Maintaining a list of computers is significantly more difficult than managing users, especially in large organizations.
• Lack of Granularity for Shared Devices: You cannot assign user-specific firewall rights at the computer level. If multiple users share a single computer, granular control requires user authentication.
• Troubleshooting Complexity: Troubleshooting network problems becomes harder with manually-maintained computer lists. User authentication, conversely, automatically links each user to an IP address, making tracking, monitoring and troubleshooting much simpler.

Prioritize User Authentication: Implement user authentication whenever possible. The Single Sign-On (SSO) tool allows users to seamlessly authenticate with AXS Guard after logging on to their client PC.

System-level Security

This scenario applies to:

• Unauthenticated users.
• Computers that are not listed in the AXS Guard computer list.

At this level, only system-wide firewall policies apply, and any unspecified traffic is blocked by default (zero trust). Maximum security and restrictions should always be enforced here, meaning permissions must only be granted at the group or user level.

Firewall Rules

Naming Conventions

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 firewall (forwarded traffic).
dmzf-	DMZ filtering rules.
pr- & pf-	Automatically-generated port redirection and port forwarding rules.
cm-	Rules pushed via the AXS Guard cloud.
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.

Advanced Rules

The AXS Guard firewall leverages iptables, offering system administrators significant flexibility to configure advanced rules for specific use cases.

While advanced firewall rules provide powerful customization, incorrect use can lead to insecure configurations. If you're not familiar with iptables, avoid using them. AXS Guard is not liable for any insecure configurations resulting from the improper use of advanced rules.

Advanced firewall rules always take precedence over other configured rules on the system. Misconfigurations can inadvertently disable essential rules needed for remote support or automatic system updates.

To create advanced firewall rules, consult the relevant man pages or online documentation, such as the iptables manual. An example of an advanced rule is provided below. Omit the iptables command itself; only use the options and parameters as shown in the example:

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

Match Types

A match refers to a condition or set of conditions that a network packet must meet for a specific firewall rule to be applied to it. There are 4 types of matching:

• Generic matches.

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

• Matches based on the traffic flow.

• Special matches.

Protocol Match

Match	Description
Protocol	Only matches when the packet contains the specified protocol.
Source	Only matches when the packet contains the specified source IP address. 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 address 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.

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.

Flow-based Match

Traffic Flow	Description
Towards	Matches the specified interface type, i.e. Secure, DMZ or Internet.
Through	In-interface: the interface where the traffic to be matched is expected to arrive. Out-interface: the interface where the traffic to be matched is expected to exit.
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.

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.

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.

Target Actions

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

Target	Description
Accept	The packet is accepted and may continue its route. Accepted network traffic is not logged by default. To log accepted traffic, the log rule target option must be enabled.
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.

Zone Restrictions

Creating firewall rules involves specifying where traffic is coming from and where it's going to. To maintain your network's security, AXS Guard places strict limitations on certain interface combinations (zone combinations) within firewall rules. These limitations exist because some combinations are inherently dangerous and could severely compromise your network's security and integrity.

For example, AXS Guard specifically disallows rules that would allow traffic directly from the Internet (INT) to your local area network (LAN). To manage traffic from the Internet to your DMZ, you should use dedicated DMZ filter rules.

What happens if you try to configure a prohibited combination?

If you attempt to create a rule with a dangerous or prohibited interface combination, AXS Guard will generate an error message and prevent the rule from being created. In cases where the interface combination can't be validated during configuration (e.g., if no incoming interface is selected), AXS Guard will automatically drop packets that match these invalid combinations.

The following illustration shows the allowed interface (zone) combinations for firewall rules.

Firewall Policies

What are Firewall Policies?

A firewall policy comprises one or more firewall rules and can be assigned to users, groups, computers, or the system itself (refer to AXS Guard security levels for further details). Firewall policies are either static or dynamic. A specific type of policy, the DMZ filter policy, is detailed in DMZ Filter Policies. Policies, similar to rules, offer the advantage of reusability, allowing them to be saved and activated or deactivated as required.

Important

A rule always needs to be added to a policy before it can be assigned; you cannot assign rules directly. Firewall policies can contain a single or multiple rules.

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 networked 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

This section explains how to create and activate a custom firewall policy. The process involves three steps: creating the rule(s), assigning them to a policy, and then assigning the policy to a user, group, computer, or the system.

Creating Rules

1. Go to Firewall > Rules > Towards / Through / DMZ Filter.

2. Click on Add New.

3. Configure the rule settings and options as explained in the table below.

4. Save the rule. Once the rule is saved, it can be assigned to a policy.

   

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	Valid values are: IP addresses IP ranges (CIDR notation) e.g. 192.0.2.0/24 FQDNs FQDNs will be resolved and the resulting IP addresses will automatically be added to the rule. If a subdomain is resolved by the AXS Guard appliance, its IP address will also be added to the rule. E.g. axsguard.com will match: axsguard.com cloud.axsguard.com The resolving status is indicated by a color: Black: Resolving succeeded Orange: Resolving queued Red: Resolving failed
Source Port	Enter the source port to be matched by the rule. A port range can be specified using the x:x format, e.g. 80:82.
Source List	Select the appropriate source list(s) to match.
Excluded Source IP	Exclude a single IP address or an entire IP range (CIDR) from the provided source list or network.
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.
Destination List	Select the appropriate destination list(s) to match.
Destination Port	Enter the destination port to be matched by the rule. A port range can be specified using the x:x format, e.g. 80:82.
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 not enforced. To enforce the rule, you must add it to a policy and then add the policy to a user, group, computer or the system.

Important

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

• LAN designates any Ethernet interface that is set to the type secure.
• SEC designates all secure interfaces, including VPN 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 add your custom firewall 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.

Once the policy is created, it must be assigned to a user, group, computer or the system in order to be enforced.

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 will appear.

   

5. Search and select the desired firewall policy or policies.

6. Update your configuration.

The policy is now assigned and will be enforced for all users who are members of the 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