Add Custom Inspection Checks

In document F IREWALL/VPN REFERENCE GUIDE (Page 110-119)

If you want to detect some pattern in traffic that is not defined in the predefined Situations (for example, a particular internal file server in your network being accessed) or if you want to create a modified version of some existing Situation, you can create a new Situation element. This is explained in Configuration of Situations (page 164).You can add your custom Situations to the Rules tree by selecting a Situation Type for them.

Using Inspection Rules

Setting Default Options for Several Inspection Rules

You may want to set default settings for some rules to avoid defining the same settings for several rules individually. The Continue action in Exception rules is used to set such default options. In Inspection rules, all settings in the Action Options and the Logging cell can be set using Continue rules. However, the Rules tree ignores any logging options set with Continue rules. In the Rules tree, the rules either inherit the logging settings from a higher level in the tree or define a specific logging option as an override.

The Continue rules in Inspection rules work in the same general way as those in Access rules, see Configuring Default Settings for Several Rules (page 95).

For general information on using rules, see Using Policy Elements and Rules (page 79).

Example of Inspection Rules

The example in this section illustrates a common modification to the default Inspection rules in StoneGate and general steps on how the scenario is configured.

Eliminating a False Positive

The StoneGate administrators in this example have just started using Inspection rules,

installing a policy that includes only the rules defined in the Default Inspection Rules template.

When they install the Firewall Policy, they soon start receiving alerts.

After some investigation, the administrators realize that the alert is caused by a custom-built application, which communicates in a way that happens to match the pattern of how a certain exploit would be carried out by an attacker. The custom-built application is only used by a specific server and a few clients in the internal network, so they quickly modify the Inspection rules to exclude those particular hosts for the Situation in question. The administrators:

1. Create Host elements to represent the server and the clients.

2. Create a Group element that includes the client’s Host elements.

•The administrators name the Group so that it is immediately clear from the name that the Group contains those hosts that must contact the server running their custom-built application. This makes the new rule easier to read than if they included the hosts directly in the rule.

3. Add the following rule in the Inspection rules in their policy:

•If the Situation matches traffic between any other hosts than those included in the Group, the IP address does not match those defined in the new rule, so the processing will continue to the next rule, which terminates the traffic and triggers an alert.

•The logging would not have to be set to None, because it is the default option, but the administrators want to do so anyway to make sure any rules they add in the future cannot accidentally set logging on for this rule.

4. Install the new policy on the Firewalls.

Table 10.2 Rule for Eliminating a False Positive

Situation Source Destination Action Logging

The Situation element that is mentioned in the alerts in the Logs view.

The Group defining the

clients. The Host for the

internal server. Permit None

C HA PT E R 11


Network address translation (NAT) means changing the IP address and/or port information in packets. Most often, NAT is used to allow internal hosts to communicate via networks where their actual address is not routable and to conceal the internal network structure from outsiders.

The following sections are included:

Overview to NAT (page 114)

Configuration of NAT (page 117)

Using NAT and NAT Rules (page 120)

Examples of NAT (page 123)

Overview to NAT

Network address translation (NAT) changes the source or destination IP address or port for packets traversing the firewall. It is most often used to hide internal networks behind a single or just a few routable IP addresses on the external network. NAT is also often used to translate an external, routable destination address into the private internal address of a server. For

destination NAT, it is also possible to perform port translation (sometimes referred to as PAT) when the protocol in question uses ports. Port translation can be used to redirect a standard service, such as HTTP (port 80/TCP), to a non-standard port (for example, port 8080/TCP). The NAT rules are stored in policy elements, which are discussed in Firewall Policies (page 71).

NAT is applied to traffic that has been already been allowed by Access rules that have connection tracking on. If you have Access rules that turn off connection tracking for some traffic, you cannot use address translation with those connections.

There are five possible methods for network address translation (these methods are explained in more detail in the next sections):

Static source translation, which translates each single IP address to some other single IP address (one-to-one relationship).

Dynamic source translation, which translates several IP addresses to a single IP address or a small pool of IP addresses (many-to-one/many-to-some relationship) differentiated by port.

This method is not supported with Multi-Link if the Loose connection tracking mode is used.

Static destination translation, which translates each single IP address to some other single IP address (one-to-one relationship).

Destination port translation, which translates a port to a different one (one-to-one relationship).

•Both source translation and destination translation for the same connection.

Dynamic destination translation is done automatically as part of the Server Pool feature, see Inbound Traffic Management (page 213).

Additionally, when NAT is performed, return address translation is needed to allow reply packets to reach the correct sender or to show the source address that the destination host expects.

However, return address translation does not normally need configuration as it is done automatically with the help of connection tracking.

Static Source Translation

In static source translation (one-to-one source translation), the source IP address of a certain host is always translated using the same specific IP address. Often, the original source address is the actual assigned IP address for a device on an internal network or DMZ. The translation is then done to a public IP address belonging to the public IP address range assigned by the Internet service provider (ISP).

Illustration 11.1 Static Source Translation

In Illustration 11.1, the packet starts out with the source (SRC) and destination (DST) addresses (1). The firewall replaces the source address of the packets with a new source address (2). Connection tracking information is used to automatically translate any reply packets: as the server responds, the destination address in the server’s response (3) is replaced with the original address (4), ensuring that the responses find their way back to the host.

You can also define static translation using whole networks. There is still a fixed one-to-one relationship between each original and translated IP address, so the original and translated networks must be of the same size. The addresses map to their counterparts in the other network. For example, if you translate the network to, the host is always translated to

Dynamic Source Translation

Dynamic source translation allows translating a large number of original IP addresses to a much smaller pool of translated addresses, even a single IP address.

Dynamic source translation, sometimes referred to as hide NAT, is often used to mask the internal networks of a company behind one or a few public, routable IP addresses provided by an ISP.

Illustration 11.2 Dynamic Source Translation Internal Network

Public Server Source packet

Translated packet Reply packet

Translated packet

1 2

4 3

Internal Network Public Server Source packet

Translated packet Reply packet

Translated packet

1 2

4 3

when the reply packets arrive. For this, the firewall uses the source port: as each different host makes connections (1), it is assigned a unique port (one of the unreserved high ports) to track its connections (2). Based on the port used in the reply packets (3), the destination is

translated to the original source address and port (4).

Static Destination Translation

Most typically destination translation is needed when you have servers behind NAT to translate new incoming connections from the server’s public IP address to the private one. You can use static destination translation for both IP addresses and ports.

Illustration 11.3 Destination Translation

In the example in Illustration 11.3, a host on the Internet connects to a server on the internal network. The host connects to the external, public IP address (1). StoneGate then translates the destination address to the private IP address of the server on the internal network (2). The server sends its response back (3), and StoneGate automatically translates the source address back to the external IP address (4).

You can also define static translation for whole same-size networks at once. This works in the same way as in static source translation.

Destination Port Translation

Destination translation can also be used to translate ports. For example, Web traffic to the corporate Web servers on a DMZ would typically come in on port 80. However, an administrator may wish to run the Web service on a non-standard port for security or network management reasons. The original destination port can be translated using static destination port translation with or without destination address translation.

Internal Network External Network Source packet

1 Translated packet


Reply packet 3

Translated packet 4

Configuration of NAT

Address translation is configured as part of the Firewall Policy using NAT rules. NAT rules are configured on the IPv4 NAT and IPv6 NAT tabs in Firewall Policy and Firewall Template Policy elements. Firewall Sub-Policies cannot contain NAT rules.

Illustration 11.4 Newly Inserted NAT Rule

Illustration 11.4 shows a NAT rule that has just been inserted into a policy. The Source, Destination, and Service cells are set to <none> and they must be changed to something else for the rule to match any traffic. The Used on cell is also used for traffic matching: you can add specific Firewall elements in this cell to make the rule valid only on those firewalls, or you can leave it to the default ANY to make the rule valid on all firewalls where the policy is installed.

The table below explains briefly what each NAT rule cell does (more information is included in the task flow further in this chapter). The columns are presented here in the default order, but you can drag and drop them to your preferred order in your own Management Client.

Note – NAT rules are applied only after a packet matches an Access rule and is allowed by the firewall. The Access rule must have connection tracking enabled (default).

Table 11.1 NAT Rule Columns

Cell Explanation


(Not editable.) Automatically assigned ID number that indicates the order of the rules in the policy. The rules are matched against traffic in the order of the ID numbers. For example, rule 4.3 is the third rule added in this Firewall Policy element to the insert point that is the fourth NAT rule in the upper-level Template Policy element.

Source A list of matching criteria that defines the IP addresses and interfaces that the rule matches. The Source and Destination cells accept any elements in the Network Elements category, as well as User and User Group elements. Both the Source and the Destination defined must match the source and destination of a packet for the packet to match the rule. The addresses you insert must be valid for the address translation operation, for example, static source address translation requires that the Source cell contains a single continuous IP address space.


Service Allows limiting the rule’s scope to a specific protocol (similar to Access rules). The Service cell accepts only Service elements.

Source, Destination, and Service

are used to match the rule to traffic. Used on makes the rule match on particular firewalls.

NAT cell defines how the translation

is done.

Considerations for Designing NAT Rules

The basic design principle of NAT rules is the same as in Access rules: the rules are read from the top down, and more specific rules must be placed above more general rules that match the same traffic. The traffic is matched based on the Source, Destination, Service, and Used on cells. The Source and Destination addresses in the cells must be valid for the address

translation operation (the Source cell for source address translation and the Destination cell for destination address translation). When the first matching rule is found, the NAT defined for the rule is applied and the rest of the NAT rules are ignored. All NAT operations for the same connection must be defined in the same NAT rule (if you want to apply both source and destination translation to a connection).

Default Elements

The Default template contains NAT rules that exclude from address translation the communications between the firewall and the Management Server that controls it and the communications from the firewall to the Log Server where the firewall sends its log data. You must not use NAT rules to translate the addresses in these system communications, but define Locations and Contact Addresses instead. See NAT and System Communications (page 120).


The network address translation that is applied to connections that match the rule.

You can also set outbound load balancing parameters in this cell (see Outbound Load Balancing NAT (page 122)). If you leave this cell empty, address translation is not applied to matching connections, that is, the rule specifies that NAT is not to be applied to matching connections (to make an exception to the other NAT rules below).

Used on The firewalls on which the NAT rule is applied. Used for creating NAT rules when a shared policy is used on several different firewalls. The Used on cell accepts only Firewall and Firewall Cluster elements.

Comment Your free-form comment for this rule. Note that you can also add separate comment rows in between rules.


(Not editable.) Automatically assigned unique identification for the rule. Works as a link between the log entries and the rule that has generated the log entries. The rule tag consists of two parts (for example, @180.2). The first part of the tag is

permanent and belongs to only that rule. The second part changes when the rule is changed. The first part and the second part are separated by a period.

Hit (Not editable) Shows the number of connections that have matched the rule. This information is only shown if you have run a Rule Counter Analysis for the policy. The cell shows “N/A” if there is no information available about the rule.

Note – NAT is applied after an Access rule has allowed the connection but before a routing decision is made. Make sure the Access rules allow the connection with the original (before NAT) addresses, and that the translated (after NAT) addresses are included under the correct interface in the Routing view, if necessary.

Table 11.1 NAT Rule Columns (Continued)

Cell Explanation

Configuration Workflow

The following sections provide an overview of the configuration tasks. Detailed step-by-step instructions can be found in the Online Help of the Management Client and the Administrator’s Guide PDF.

In document F IREWALL/VPN REFERENCE GUIDE (Page 110-119)

Related documents