FILTERING AND NAT

Filtering and NAT are condensed in a single module and are part of the Security policy menu.

Evaluation of filtering and the impact of NAT

The filter policy is assessed on IP addresses before their modification via NAT, meaning the IP addresses of the network packet before it reaches the firewall. For example, in order to allow access to an internal server from a public network (e.g. the internet), the public address of this server (or the firewall’s public address, for example) has to be entered in the Destination field of the filter rule.

On rules with a "pass" action and the explicit HTTP service enabled, "decrypt" or "log" does not cancel the execution of he following rules. Rules continue to be evaluated. Filter rules can therefore be added after such rules.

This module consists of 2 tabs, each containing an area reserved for filter policies and NAT policies, and their configuration:

  • Filtering: this is a set of rules that allow or block certain types of network traffic according to the defined criteria.
  • NAT: these allow rewriting (or translating) source and destination addresses and ports.

“FastPath” mode

For rules with an inspection in “Firewall” mode, traffic has been optimized and throughput multiplied by a mechanism called FastPath. These rules in “Firewall” mode are recommended for simple access control requirements, for example, for specific internal traffic. This may be traffic dedicated to data backups or replication in a datacenter, or reserved for satellite VPN sites’ access to a main firewall if it already scans traffic.

This mechanism therefore allows lightening a heavy processing load that the intrusion prevention engine may have by saving connections that are eligible for FastPath, meaning that once they have been checked, they no longer need to go through the IPS engine. This optimization is automatic for rules in firewall mode applied to IPv4 traffic, without network translation (NAT) and without scanning the protocol using dynamic connections (FTP, SIP, etc). Rules must also not have the following options or values:

  • Quality of service (QoS),
  • A connection threshold: TCP with or without protection from synflood (synproxy), UDP, ICMP and application requests
  • Rewritten DSCP (DSCP value defined),
  • Rule with an unspecified destination port that does not comply with the protocol indicated (onprobe).

This mechanism is compatible with PBR (policy-based routing) and load balancing options. To ensure a full and coherent overview of traffic, connection tracking will examine the table for log generation in particular.