NAT rules

Network Address Translation (NAT) allows you to translate IP addresses and ports for traffic flowing between networks.

It translates private IP addresses into public IP addresses, allowing private IP networks to connect to the internet and hiding the internal network behind the public IP address.

You can create source NAT (SNAT) and destination NAT (DNAT) rules to enable traffic flow between private and public networks by translating non-routable, private IP addresses to routable, public IP addresses. You can create NAT rules for IPv4 and IPv6 networks.

You can specify loopback and reflexive rules for a destination NAT rule. These rules remain independent of the original rule from which they’ve been created. Changing or deleting the original NAT rule doesn’t affect them.

Linked NAT rules are SNAT rules and are created from firewall rules. XG Firewall automatically adds a linked NAT rule to match traffic for email MTA mode.

To allow traffic flow between overlapping local subnets, you need to configure NAT over policy-based IPsec VPN on VPN > IPsec connections. For details, go to knowledge base article 123356.

  • To add a NAT rule manually, select Add NAT rule and then select New NAT rule.
  • To create destination NAT rules and the related firewall rules automatically, select Add NAT rule and then select Server access assistant (DNAT).

Server access assistant (DNAT)

Use this to create DNAT rules to translate incoming traffic to servers, such as web, mail, SSH, or other servers, and to access remote desktops. The assistant also creates a reflexive SNAT rule (for outbound traffic from the servers), a loopback rule (for internal users accessing the servers), and a firewall rule (to allow inbound traffic to the servers) automatically.

Rule table actions

  • To see IPv4 or IPv6 rules in the rule table, select IPv4 or IPv6.
  • To hide or show the rule filter, select Disable filter and Enable filter respectively.
  • To reset the rule filter, select Reset filter.
  • To turn off rules, select the rules and then select Disable.
  • To delete rules, select the rules and then select Delete.
  • To change the sequence of a rule, drag and drop the Rule handle button . XG Firewall evaluates rules from the top down until it finds a match. Once it finds a match for the packet, it doesn’t evaluate subsequent rules. So, position the specific rules above the less specific rules.

Click More options to specify the following actions:

  • To turn on or turn off a rule, select the switch.
  • To edit or delete a rule, select the action.
  • To add a rule next to an existing rule, select the action.
  • To unlink a rule from the firewall rule, select Unlink rule.
  • To reset the number of times a rule was in use, select Reset usage count. This is useful when troubleshooting.

Firewall rules and NAT rules

Firewall rules allow or drop traffic entering and exiting the network. NAT rules translate IP addresses for traffic the firewall rule allows. So, you must create firewall rules even when you have NAT rules.

If XG Firewall doesn't find a firewall rule that matches the traffic criteria, it drops the traffic and logs the event. If it doesn't find a matching NAT rule, it allows the traffic to flow but doesn't translate the IP address.

For NAT rules, the matching criteria are the original (pre-NAT) source, destination, and service, and the inbound and outbound interfaces. The order in which XG Firewall looks up and applies NAT and firewall rules is as follows:
  • Outgoing traffic: XG Firewall applies the firewall rule first and then the SNAT rule.
  • Incoming traffic: XG Firewall looks up the DNAT rule first to determine the translated (post-NAT) destination. It then matches the firewall rule based on the source and destination zones, source and destination networks, services, and schedule. For the destination zone, it uses the zone to which the translated (post-NAT) destination belongs.

    Example: For traffic from the WAN or the LAN zones to your web server in the DMZ, you can create a DNAT rule to translate your public IP address (original destination) to the web server's IP address (translated destination).

    When packets arrive, XG Firewall looks up the DNAT rule. It identifies the zone containing the translated destination that you specified. In this example, it identifies DMZ as the destination zone.

    So, to create a firewall rule matching this traffic, you must set the destination zone to DMZ.

    For an example of how to create a DNAT rule and the corresponding firewall rule, see the related link on this page: Create DNAT and firewall rules for internal servers.

Source NAT

You can create source NAT rules for outgoing traffic to enable internal clients and servers to access external hosts. XG Firewall implements one-to-one, many-to-one, and many-to-many translation. Some of these involve port address translation.

You can also define interface-specific NAT to translate the IP addresses of one or more internal hosts to the IP address you specify for an outbound interface.

You can’t create a source NAT rule using a public interface that’s a bridge member because bridge members don’t belong to a zone. If you configure a public interface as a bridge member, source NAT rules using the interface are deleted.

Destination NAT

You can create destination NAT rules for incoming traffic to enable external hosts to access internal clients and servers. You can specify one-to-one, many-to-one, many-to-many, and one-to-many translation from your public IP addresses to private IP addresses.

You can also specify a load balancing method and health check for the translated destination hosts, for example, web or email servers.

Service translation

XG Firewall implements port forwarding with service translation. Services are a combination of protocols and ports. The translated protocol must match the original protocol.

XG Firewall implements one-to-one, many-to-one, and many-to-many translation. For many-to-many translation, the ports for the original and translated services must be equal in number.

Note The web admin console of XG Firewall and the user portal are accessible over HTTPS through the default ports 4444 and 443 respectively. If your public IP addresses are configured with HTTPS port forwarding to internal web servers, go to Administration > Admin settings and specify unused ports for the Admin console HTTPS port and the User portal HTTPS port. Alternatively, specify a different port for your web servers.

Loopback rules

You can create loopback rules from destination NAT rules to allow internal hosts to communicate with other internal hosts over the external IP address or the domain name. For example, create a destination NAT rule to translate incoming traffic to your servers and create a loopback rule.

To create a loopback rule, specify the following destination NAT rule criteria:

  • Original source: Any
  • Translated source: Original
  • Translated destination: Don’t set to original.

Reflexive rules

You can create a mirror NAT rule for destination NAT rules. It reverses the matching criteria of the destination rule. For example, create a destination NAT rule to translate incoming traffic to an internal server. The corresponding reflexive rule will allow traffic from the server to the source specified in the destination NAT rule.

If the original destination isn’t an IP address or is translated, the translated source is masqueraded.

Linked NAT rules

You can create linked NAT rules when you create firewall rules. These are SNAT rules and appear in the NAT rule table.

XG Firewall introduced linked NAT rules in 18.0 to ensure a smooth migration from earlier versions in which the NAT configuration was part of the firewall rule.

All the matching criteria of a firewall rule, including users and schedule, apply to its linked NAT rule. You can't edit these settings in the NAT rule. You can only specify the translated sources, including interface-specific translated sources in a linked NAT rule.

XG Firewall matches linked NAT rules only with traffic related to the firewall rule to which it's linked. However, if it finds a match with a rule above the linked NAT rule, it applies the first rule's settings.

Tip We recommend that you don't create new linked NAT rules when a generic NAT rule matches the traffic. Create NAT rules independently to simplify your configuration because you need fewer NAT rules than firewall rules. For example, you may only need a single SNAT rule to masquerade outgoing traffic in a simple environment. You don't need to create an SNAT rule for each firewall rule.

Migrated NAT configurations

When you migrate from an earlier version to SFOS 18.0, XG Firewall migrates the NAT settings of firewall rules as NAT rules and lists them in the NAT rule table. You can't define a gateway-based NAT configuration any longer.

Source NAT settings are migrated as linked NAT rules. These rules are linked to the original firewall rule. You can identify these by the firewall rule ID and name in the NAT rule table.

Destination NAT settings are migrated as independent NAT rules and aren’t linked to a firewall rule.

Table 1. Rule migration

Pre-migration rules

Post-migration rules

User/Network rules

Source or destination NAT rules based on the pre-migration criteria.

Email clients

Source NAT rules

DNAT/Full NAT/Load balancing

Destination NAT rules with corresponding firewall rules.

Email servers

Destination NAT rules

NAT settings are migrated as follows:

Source NAT (SNAT) rules:

  • Masqueraded and translated source addresses are migrated as they are.
  • If the rule wasn’t configured with gateway-specific NAT, the translated destination is set to MASQ.
  • Default source NAT rules aren’t created for public interfaces that are bridge members.

User-network rules with gateway-specific NAT policy and email client (business application) rules: These are migrated as firewall rules and linked (source) NAT rules. The migrated NAT rules will have the following settings:

  • Inbound and outbound interfaces are set to Any.
  • Translated destination is set to Original.
  • Override source translation for specific outbound interfaces is selected in the migrated NAT rule.

Translated source for the outbound interface is set based on the following pre-migration configurations:

Gateway-interface relationship before migration

Translated source after migration

Gateway doesn’t have an interface attached

Not migrated

Interface attached to the specified gateway isn’t attached to another gateway

NAT policy host of the gateway

Interface attached to the specified gateway is also attached to the default gateway

  • NAT policy host of the default gateway
  • Original for the other gateways

Interface attached to the specified gateway is attached to other gateways (and not to the default gateway)

  • NAT policy host of the first gateway
  • Original for the other gateways

Override default NAT policy for specific gateway was selected

NAT policy host of the specified gateway (not the default NAT policy host)

Destination NAT rules: When you migrate a destination NAT (business application) rule, the corresponding migrated NAT rule lists inbound interfaces based on the source zone. They are as follows:
  • Interfaces that belong to the source zone specified in the destination NAT rule.

  • Bridge interface, if it belongs to the source zone.

  • The default Any if no interface belongs to the source zone.

Destination NAT rule with source NAT rule: DNAT rules are migrated as independent firewall and NAT rules. If a reflexive rule was selected, it is migrated as a firewall rule and a linked NAT rule.

Email server (business application) rules: Their migration follows the DNAT rule migration principles. Other migration settings are as follows:

Email server rules

Migrated settings

Users and groups

Migrated to firewall rules

Allowed client networks

Source networks and devices in firewall rules

Blocked client networks

Exclusions to Source networks and devices in firewall rules

Protected zones

Destination zones are set to Any in firewall rules

Protected zones in reflexive rule

Source zones in firewall rules

Protected servers

Translated destination (DNAT) in destination NAT rules

Protected servers in reflexive rule

Source networks and devices in firewall rules

Clean up linked NAT rules in the rule table

Source NAT settings are migrated as linked NAT rules. These rules are linked to the original firewall rule.

When you migrate to SFOS 18.0, many linked NAT (source NAT) rules may be created in the NAT rule table. They are linked to firewall rules that didn't have NAT settings configured or had implemented NAT based on users and schedule prior to migration.

We didn't prune these rules automatically to ensure that there's no behavior change after migration. However, you can delete them. They are linked NAT rules with the following criteria:

  • Translated source set to MASQ.
  • Linked to firewall rules that have destination zone set only to WAN.

At the bottom of the rule table, we added a default source NAT rule (Default SNAT IPv4 or Default SNAT IPv6) with translated source set to MASQ. The rule is turned off by default. You can reposition this rule to replace the deleted rules and turn it on.

In the NAT rule table, the box below the rule filtering menu gives the following options for these linked NAT rules:

  • Understood. Don't delete rules: Won't delete the rules. Won't show the box again.
  • Delete linked NAT rules (only MASQ; Destination: WAN): Deletes the linked NAT rules with translated source set to MASQ and linked to firewall rules that have destination zone set only to WAN.
  • Select the X button on the upper right to hide the box temporarily. The box reappears when you open the page later.