Understanding NAT on Sophos Firewall: SNAT, DNAT, MASQ, PAT

NAT changes a packet’s addresses or ports. It does not decide whether the connection is allowed, nor does it create a route. For data to flow successfully, the NAT rule, firewall rule, routing, and return path must all align.

The best starting point is therefore not to ask “Which type of NAT do I need?”, but rather: Which address or port should change between ingress and egress? If there is no clear answer, the solution usually lies in routing or the firewall rule, not in NAT.

⚠️ A NAT rule is not an allow rule. If the firewall rule allows the traffic but no NAT rule matches, SFOS forwards the packet without translation. If the corresponding firewall rule is missing, the packet is dropped and logged.

When should NAT be used?

• LAN clients need Internet access: usually SNAT with MASQ.
• An internal service must be reachable through a public address: DNAT; for HTTP/HTTPS, check WAF first.
• The external and internal ports differ: service translation using Translated service (PAT).
• Internal clients use the public name of an internal server: prefer split DNS or use a targeted Loopback Rule.
• Non-overlapping networks communicate over a site-to-site VPN: normally routing and firewall rules without NAT.
• Networks overlap: plan NAT based on the VPN type; do not improvise with a generic MASQ rule.
• Only allow or block access: change the firewall rule; do not create a NAT rule.

For the specific task of publishing a server, Publish a server with DNAT on Sophos Firewall covers the assistant, manual rule creation, hardening, go-live, and rollback. This article explains the NAT model so that you can interpret such rules and troubleshoot issues.

Other closely related special cases include NAT64 with Direct Web Proxy, Proxy ARP for additional public IPv4 addresses, and NAT for IPsec issues.

How to interpret Original and Translated correctly

Under Rules and policies > NAT rules > Add NAT rule, Original describes the packet as it arrives at the firewall. Translated describes the change that SFOS applies to it.

The rule is selected based on these fields:

• Original source
• Original destination
• Original service
• Inbound interface
• Outbound interface

The Translated source (SNAT), Translated destination (DNAT), and Translated service (PAT) fields are results, not additional match criteria. NAT rules are evaluated from top to bottom; the first matching rule wins.

NAT rules are available for IPv4 and IPv6. Select the appropriate address family under Rules and policies > NAT rules before creating a rule; the IPv4 example addresses below do not belong in an IPv6 rule. Add NAT rule > New NAT rule opens manual configuration. New rules are enabled by default. Rule position offers Top and Bottom; you can subsequently change the order by dragging and dropping. Check criteria and position before Save so the new rule does not unintentionally take over production traffic.

Two packet examples

A client at 10.10.10.80 connects through Port2 to 198.51.100.20:443. An SNAT rule can change only the source to MASQ. The destination and service remain Original.

When a service is published, an external client connects to 203.0.113.10:5555. DNAT changes the destination to 172.16.16.10; PAT changes the service to 443. The resulting rule is:

• Original destination: 203.0.113.10
• Original service: TCP 5555
• Translated destination (DNAT): 172.16.16.10
• Translated service (PAT): TCP 443

PAT is therefore not a separate address NAT type alongside SNAT and DNAT. It is the port or service translation within a NAT rule.

SNAT and MASQ for outbound traffic

SNAT changes the source address. A typical LAN-to-WAN rule uses the internal network as the Original source, the WAN interface as the Outbound interface, and MASQ as the Translated source. The destination and service remain Original or are restricted to the scope actually required.

By default, MASQ uses the address of the outbound interface. The factory configuration includes Default SNAT IPv4 for this purpose. If it is not needed, Sophos recommends disabling it rather than deleting it: it may be recreated when a WAN interface is created or updated.

After a migration from SFOS 17.5 or earlier, an additional disabled default SNAT rule may appear at the bottom of the table. It is intended to replace cleaned-up Linked MASQ rules and must not be confused with an actively used factory rule.

Multiple internal clients or servers can share the same public source IP: SFOS distinguishes their connections using different port numbers. This source-port mapping is not the same as DNAT service forwarding to a server.

Create an independent LAN-to-WAN SNAT rule

An independent SNAT rule can serve multiple firewall rules. First check existing NAT rules, the route, outbound interface, and return path, and save the previous state including IDs and positions. This example permits only HTTPS from the client network to a specific test destination; replace all addresses and interfaces with your own values.

1. Open Rules and policies > NAT rules, select IPv4, then Add NAT rule > New NAT rule. Set Rule name, for example LAN-Web-Standalone-MASQ. Choose Top or Bottom under Rule position, then deliberately drag the rule above more general matching rules; do not blindly put it first.
2. Set Original source to Clients_LAN (10.10.10.0/24), Original destination to a host object for 198.51.100.20, and Original service to HTTPS. The documentation destination is not a real test server. General Internet access can deliberately use a broader destination scope; keep services limited to those required.
3. Set Translated source (SNAT) to MASQ, and both Translated destination (DNAT) and Translated service (PAT) to Original. Set Inbound interface to the actual LAN interface, Port2 in the example, and Outbound interface to the actual WAN interface, Port1 here. Select Save and record the NAT Rule ID.
4. Under Rules and policies > Firewall rules, select IPv4 > Add firewall rule > New firewall rule if no suitable allow rule exists. Set the name and position, Action Accept, Source zones LAN, Source networks and devices Clients_LAN, Destination zones WAN, Destination networks to the same destination, and Services HTTPS. Configure appropriate security settings and Log firewall traffic, then Save. Do not create another Linked NAT Rule.
5. Establish a new HTTPS connection to your own test destination and close it normally. Compare both Rule IDs in Log Viewer; Packet capture should show the expected WAN source address on egress. For a wrong NAT match, check higher rules first; for missing replies, check routing and the return path. To roll back, disable only newly added rules and restore changed positions; do not remove a shared allow rule. Verify the previous state with a new session.

Create a LAN-to-WAN rule with linked NAT

For a scoped IPv4 allow rule, you can link SNAT while creating the firewall rule. First check whether an existing SNAT rule already translates the flow as required; if so, no additional Linked NAT Rule is needed. The route and return path must be correct independently of NAT.

1. Open Rules and policies > Firewall rules, select IPv4, and create a rule through Add firewall rule > New firewall rule. Choose a clear name, such as LAN-Web-Out, and an appropriate position; set Action to Accept and enable Log firewall traffic.
2. Set Source zones to LAN and restrict Source networks and devices to the client network that needs access. For example, use a network object named Clients_LAN for 10.10.10.0/24; adapt both the name and subnet to your environment. Set Destination zones to WAN. Under Destination networks, select the required destinations, and under Services, only the required services, such as HTTPS for this web flow. Any is not a blanket requirement. Account for DNS and any other necessary services separately.
3. Select Create linked NAT rule. Give the NAT rule its own name, such as LAN-Web-MASQ, and an appropriate position. Set Translated source (SNAT) to MASQ: this flow should use the address of the actual outbound interface, while the firewall rule continues to restrict sources, destinations, and services.
4. Select Save inside the linked NAT configuration first, then select Save again for the firewall rule. Saving only the nested NAT dialog does not complete the procedure.
5. Check the firewall rule under Firewall rules and the linked SNAT rule under NAT rules; record both entries and their Rule IDs. Review the order in each table separately. A matching NAT rule above the linked rule can take precedence; linking does not guarantee priority.
6. From an allowed client, establish a genuinely new connection to the permitted destination and service, then close the test connection normally so a session log can be generated. Filter for that flow in Log Viewer and compare Firewall Rule ID and NAT Rule ID with the recorded IDs. If the firewall ID is wrong, check firewall criteria and order first; if the NAT ID is wrong, check higher NAT rules first. The presence of both entries alone does not confirm working Internet access.

Important SNAT limitations

Alongside MASQ, Translated source (SNAT) can use a single IP or an IP range. The SFOS 22 description explicitly permits any interface-assigned IP as the source and specifies Add to create an IP/range object. The SFOS 23 description of NAT types still explicitly includes single IPs and ranges; omitted sentences in its Add description do not mean support was removed. The fixed address must be reachable in your environment and compatible with the expected return path.

• A range under Translated source does not create a fixed one-to-one mapping. SFOS uses the next available address in the range.
• A public interface that is a member of a bridge cannot serve as a source NAT interface. If an interface in use is later made a bridge member, SFOS deletes the affected SNAT rules.
• Override source translation for specific outbound interfaces allows one SNAT rule to use different translated sources for different outbound interfaces. Use Expand to add more mappings.
• For route-based VPNs with Any as the local and remote subnets, or with a dual-IP configuration, MASQ may use the XFRM address as the inner source. The WAN address remains visible in the outer tunnel header.

Before changing a bridge configuration or modifying production SNAT pools, document the affected rules and then test them using a genuinely new traffic flow.

DNAT, PAT, Loopback, and Reflexive Rules

DNAT changes the destination address. PAT also changes the service or port being addressed. The protocol must remain the same: TCP can be translated to another TCP port and UDP to another UDP port, but TCP cannot be translated to UDP.

If multiple original services or Any are selected, Translated service (PAT) must be Original. An unambiguous port-forwarding rule uses one specific original service and one specific translated service. Translated destination (DNAT) can be an IP address or FQDN. Service translation supports a single destination port or equal numbers of original and translated ports: for example, many ports in one original service to one port (many-to-one), or equally sized port sets (many-to-many). Many-to-many requires equal port counts; multiple separately selected original services do not allow PAT translation. The protocol must always remain the same.

The firewall rule corresponding to DNAT

For inbound traffic, SFOS first determines the matching DNAT rule. It then evaluates the firewall rule. This results in an unusual but important mapping:

• Destination zone: the zone of the internal destination after DNAT, such as DMZ.
• Destination networks: the public destination address before DNAT.
• Services: without PAT, the service being accessed. With PAT, the official Sophos example includes both the original and translated services in the firewall rule.

In the reverse direction, the firewall rule is evaluated first; SFOS then applies the matching SNAT rule.

A NAT rule does not replace this firewall rule. For a complete DNAT setup, including source restrictions, IPS, logging, and an external acceptance test, follow the DNAT runbook.

Loopback Rule

A Loopback Rule can allow internal clients to connect through the public IP address or public FQDN. Split DNS is often more transparent: internally, the same name resolves directly to the server’s internal address, avoiding the need for hairpin NAT.

The Server Access Assistant creates a Loopback Rule only if a firewall WAN interface is selected as the public address and External source networks and devices is set to Any. Entering a public IP address or a more restrictive external source does not create this automatic Loopback Rule.

In manual DNAT configuration, Create loopback rule is a separate option. The underlying DNAT rule must use Original source Any, Translated source (SNAT) MASQ, and a Translated destination (DNAT) other than Original. These are not the assistant’s fields. Do not remove an external source restriction merely to obtain loopback: first consider split DNS or a separately planned internal rule. After saving, test internal access and external restrictions separately.

Reflexive Rule

A Reflexive Rule creates a reverse SNAT rule for a DNAT rule. It reverses the match criteria and can translate outbound server traffic using the corresponding public identity. If the original destination is not an IP address or is translated, the Reflexive Rule uses MASQ as the translated source.

During manual DNAT creation, Create reflexive rule generates this mirror rule; Create loopback rule is independent. Generated rules use the original rule’s ID and name but remain separate. For rollback, identify and disable every generated entry separately, then check with new internal and external connections.

Loopback and Reflexive Rules remain separate rules. Changing or deleting the original DNAT rule does not automatically update or remove them. After changing the public address, internal destination, or service, check the derived rules separately.

If a DNAT rule distributes traffic across multiple internal destinations, SFOS considers them available unless Health check is enabled. A health check is mandatory for First alive; for the other distribution methods, it must be enabled explicitly and configured with ICMP or TCP to suit the service, so that SFOS sends no new traffic to a failed server.

Choose how multiple DNAT destinations are used

Choose Load balancing method for the required behavior, not just the number of servers:

• Round robin: connections go to destinations in sequence. With 10.10.10.1 through 10.10.10.3, the fourth request returns to .1. Use this for even distribution without session persistence.
• First alive: all requests go to the first available server; other destinations are backups. The health check determines when to switch.
• Random: selection is random, with no fixed client mapping.
• Sticky IP: a hash of the source and original destination binds that pair to one server. With health checks enabled, an available destination takes over on failure. When the original server returns, only new connections return to it; established sessions remain intact.
• One-to-one: first original destination to first translated destination, second to second, and so on. Both lists must contain equal numbers of IP addresses. This is a fixed DNAT mapping, not allocation from an SNAT pool.

For Health check, select Probe method ICMP or TCP and, for TCP, the actual port to check. Probe interval sets the time between checks, Response time-out the response deadline, and Deactivate host after the number of failed attempts. A ping confirms host reachability, not a working web service. Match intervals and timeouts to the service; overly sensitive values can unnecessarily remove a slow destination. Before production, verify distribution with new connections and check a planned failure and recovery. Save the previous method and probe settings for rollback.

Check port conflicts before publishing

Before forwarding HTTPS, record the actual WebAdmin, User Portal, and VPN Portal ports under Administration > Admin and user settings. Do not infer which service uses 443 from an older NAT guide. WebAdmin and User Portal each require a unique port. Resolve conflicts first with another published IP or external service port; do not change management ports without preparation. If a change is necessary, secure an independent management path and then test portals, VPN clients, and external DNAT access separately. The DNAT guide covers publication.

Linked NAT Rules and Server Access Assistant

A Linked NAT Rule is always an SNAT rule linked to a firewall rule. All match criteria from the firewall rule continue to apply, including users and schedules. Only translated sources and interface-specific translated sources can be changed in the NAT rule.

The link does not bypass normal NAT ordering: an independent NAT rule placed higher in the table can match first. If a generic SNAT rule already covers the same traffic, Sophos does not recommend adding a Linked NAT Rule. In MTA mode, however, SFOS creates one automatically.

The Server access assistant (DNAT) creates a DNAT rule, a Reflexive Rule, and a firewall rule. It adds a Loopback Rule only for the previously described combination of a WAN interface and the external source Any. The assistant places the rules at the top of the tables and enables them. You must then check the sources, rule position, additional generated rules, and alias IP use. For an alias IP, the assistant initially sets the physical interface as the translated source in Reflexive or Loopback Rules; if the alias address should be used, you must manually select a corresponding IP Host.

Carefully clean up migrated Linked MASQ rules

After migration, a cleanup notice may appear below the rule filter. Delete linked NAT rules (only MASQ; Destination: WAN) removes only linked rules with translated source MASQ whose firewall rule uses only destination zone WAN. This is not risk-free housekeeping: user and schedule conditions and the previous order may be part of the intended behavior.

First save the configuration, IDs, and affected flows. The disabled Default SNAT IPv4 or Default SNAT IPv6, or a deliberately planned independent SNAT rule, must replace the required translation at the correct position. Check the replacement and firewall restrictions, enable it, and compare new permitted and prohibited test flows before removing old rules. If results differ, restore the saved rules and order. Understood. Don’t delete rules retains rules and permanently dismisses the notice; X hides it temporarily. When uncertain, document first rather than delete.

Distinguishing NAT, VPN, and SD-WAN

NAT does not change a routing decision. Even after translation, SFOS needs a route to the destination. For VPN traffic, the correct place to configure translation also depends on the tunnel type:

• Policy-based IPsec: use the NAT settings of the IPsec connection to translate the local and remote subnets, especially when they overlap. If an additional SNAT rule must match policy-based traffic, set its Outbound interface to Any; it does not apply when specific WAN interfaces are selected.
• Route-based IPsec with selected local and remote subnets: use the NAT settings of the IPsec connection to translate these subnets.
• Route-based IPsec with Any/Any: use NAT rules for the forwarded traffic.

For VPN traffic in NAT rules, set Inbound interface to Any. For VPNs and DNAT translating public to private IP addresses, Outbound interface must also be Any. This is an interface matching requirement, not permission for arbitrary sources or services; Original criteria and firewall rules still restrict them.

Non-overlapping networks generally do not require NAT. For overlapping networks, document the real and translated networks on both sides; otherwise, DNS, rules, and logs become ambiguous later.

For DNAT to a server behind a route-based IPsec tunnel, Sophos documents a special SD-WAN setup: the DNAT rule uses MASQ as the Translated source so that replies return to the firewall. The SD-WAN route matches the original WAN address or WAN interface as its destination and, when PAT is used, the external port. The gateway object points to the XFRM interface. Do not apply this special case to local servers as a general DNAT pattern.

Reach a remote server using DNAT and an SD-WAN route

This IPv4 procedure applies only to a server behind the remote firewall. First check route-based IPsec connections on both firewalls, tunnel status, remote reachability, allowed sources, service, return path, and existing NAT/SD-WAN order. Save the configuration and affected positions. The example uses external TCP 5555 and internal TCP 443, not public RDP; replace documentation addresses with your own values. A separate firewall allow rule and hardening remain necessary.

1. Under Hosts and services > IP host > Add, create Remote_Web: IP version IPv4, Type IP, IP address the remote server’s address, for example 172.16.16.10; select Save.
2. Under Routing > Gateways, IPv4 gateway > Add, choose a clear name. Set Gateway IP to the remote gateway address, for example 10.12.13.2, and Interface to its XFRM interface, for example xfrm1-10.12.13.1. Under Monitoring condition, enter the IP address of a genuinely reachable host behind the gateway; check gateway/tunnel status before publishing.
3. Under Rules and policies > NAT rules > Add NAT rule > New NAT rule, create a named IPv4 rule. Restrict Original source to authorized external sources. Set Original destination to the published WAN interface, such as #Port1, Translated source (SNAT) to MASQ, Translated destination (DNAT) to Remote_Web, Original service to a TCP 5555 service object, and Translated service (PAT) to TCP 443. Set both interface fields to Any for this VPN DNAT case. Review the position and select Save. In this special case, MASQ provides the return path to the firewall.
4. Under Routing > SD-WAN routes, select IPv4 > Add and enter a name. Under Destination networks, remove Any and select the same original WAN interface #Port1, not Remote_Web. Under Services, remove Any and select the external service TCP 5555, not TCP 443. Under Link selection settings, choose Primary and Backup gateways and set Primary gateway to the remote gateway; select a backup only if its remote path actually exists and has been checked. Select Save.
5. Establish a new connection from an authorized external source. Check NAT/firewall IDs, translated destination and service, XFRM egress, and replies in the capture. For wrong egress, check SD-WAN criteria, order, and gateway monitoring; for missing replies, check the remote service and return path. For additional servers using the same gateway, extend the same SD-WAN route with their external ports/WAN addresses; use separate routes for different gateways. Newly included combinations must remain restricted by NAT and firewall rules.

If the change fails, disable the new remote DNAT rule, remove the new SD-WAN route or restore its previous configuration, and restore positions. Do not delete shared gateway/host objects. Roll back derived NAT rules separately and verify the previous flow with a new connection.

Translating firewall-generated traffic with sys-traffic-nat

NAT rules in WebAdmin translate forwarded traffic. For traffic generated by the firewall and for translating firewall interface addresses, use sys-traffic-nat in the Device Console.

Typical reasons to use CLI source translation include:

• Sending firewall-generated DHCP and authentication requests through site-to-site IPsec; translation can also support requests to firewall services through VPN tunnels. It does not replace service and VPN configuration.
• Using alias addresses when WAN links outnumber physical WAN interfaces, translating the physical interface to the appropriate alias.
• Sending mail traffic with the alias source address required by an upstream relay or MX record.
• Hiding internal addresses from WAN destinations, such as DHCP requests from a LAN interface; using a specific source identity for internal MPLS destinations or selected web servers.

Record the destination, required source identity, route, and peer requirements beforehand. Afterwards, trigger the actual service again and check the source address and reply in the capture. A CLI entry alone proves neither DHCP, authentication, nor mail flow.

⚠️ This Device Console command changes system-generated traffic. First, save the complete output of show advanced-firewall. CLI NAT entries are processed in the order shown there.

Sign in to the Command-line console and select 4 – Device Console, not Advanced Shell. The following example translates traffic to the single destination 192.0.2.10 that leaves through Port1 so that it uses the alias address 203.0.113.10:

show advanced-firewall
set advanced-firewall sys-traffic-nat add destination 192.0.2.10 netmask 255.255.255.255 interface Port1 snatip 203.0.113.10
show advanced-firewall

The destination, netmask, interface, and SNAT address must match your environment. For a single host, 255.255.255.255 is required; a broader mask matches the entire corresponding destination network. Without interface, the entry applies to traffic through any firewall interface to the specified destination.

To roll back the change, use the same complete mapping with delete:

set advanced-firewall sys-traffic-nat delete destination 192.0.2.10 netmask 255.255.255.255 interface Port1 snatip 203.0.113.10
show advanced-firewall

By default, system-generated traffic uses WAN Link Load Balancing. With an alias IP, the main interface remains decisive for the routing decision; sys-traffic-nat only ensures that the required alias address appears as the source. A visible entry therefore confirms the configuration, not the route, return path, or service.

Changing and testing NAT rules safely

Use the table and counters deliberately

Under Rules and policies > NAT rules, IPv4 or IPv6 selects the rule family. Disable filter hides the rule filter, Enable filter shows it, and Reset filter resets it. Hiding a filter does not disable a NAT rule. Ensure the correct entries are visible before changing anything.

Selected rules can be turned off together using Disable, or removed using Delete. Drag the Rule handle to move a rule; specific rules belong above general ones. More options provides the on/off switch, editing, deletion, and insertion of an adjacent rule. Unlink rule removes the link to the firewall rule; document that dependency first and do not use unlinking as a diagnostic shortcut.

Reset usage count under More options resets the usage counter. Record the counter and time first, then generate a new test flow and check the increase alongside Rule IDs; a counter alone does not identify the test flow. The previous counter value is not restored. Before rule changes, save IDs, criteria, status, and order, preferably disable rather than delete, and change only selected entries. If problems occur, restore status and positions and test with a new session; a deleted rule must be recreated from the saved configuration.

SFOS evaluates NAT only for the first packet of a connection. Existing sessions retain their previous translation when a rule is changed or moved. A post-change test must therefore create a new connection; otherwise, you may be assessing the old state.

A reliable test starts with a documented flow: source, destination, service, inbound and outbound interfaces, and the expected Firewall Rule ID and NAT Rule ID. Then follow these steps:

1. Create a new connection and filter by source, destination, and service in Log Viewer.
2. Compare the expected Firewall Rule ID and NAT Rule ID.
3. If the NAT Rule ID is wrong, check the rules above it, all Original fields, and the interfaces.
4. Under Diagnostics > Packet capture, verify that the packet arrives and is forwarded with the expected addresses.
5. Check the route, return path, destination system, and its local firewall.

For DNAT, at least one test must be performed from outside the network. Internal access to the public name tests only split DNS or loopback, not the actual publication from the Internet.

Interpreting findings correctly

• Firewall Rule ID and NAT Rule ID are correct: matching is correct; next investigate the destination system, return path, and Security Profiles.
• Firewall Rule ID is correct, NAT Rule ID is wrong: another NAT rule takes precedence, or the Original criteria do not match.
• No NAT Rule ID although translation is expected: no NAT rule matches; if the firewall rule allows the flow, it continues without translation.
• Different Firewall Rule ID: check zones, networks, service, and firewall rule order.
• No log entry: logging is disabled or the traffic does not reach the firewall. Capture on the WAN or inbound interface and check upstream routers or cloud rules.
• DNAT matches, but the server does not respond: check the server service, local firewall, default gateway, and asymmetric return path.

For deeper analysis, see Test a firewall rule, Investigate rule matching, Classify dropped packets, and Packet Capture in WebAdmin.

Understanding NATRule in the XML API

For automation, NATRule represents the same Original/Translated model. The Add NAT policy / Edit NAT policy object description is identical in the SFOS 22 and SFOS 23 references compared. This establishes the documented specification, not successful execution on a particular build. Before a write job, the central XML API security rules apply: tightly restricted management access, TLS verification, a separate service account, protected secrets, a backup, a read query, and an explicit operation on Set confirmed for the object and installed build. The object description alone is not a complete executable request.

Match criteria, translation and rule identity

• OriginalSourceNetworks contains repeatable Network entries for the original sources; OriginalDestinationNetworks contains Network entries for the original destinations. OriginalServices contains repeatable Service entries. These are object references for matching before NAT, not a firewall allow rule. The reference specifies a maximum of 60 characters for each of these network and service names.
• TranslatedSource, TranslatedDestination and TranslatedService are each single values for translation. For an unchanged field, the example uses Original; for source masquerading, it uses MASQ. Entries such as IPAddress, IPRange, IPList, FQDN or TCPUDP_Service describe the appropriate object type in the example, not an arbitrary literal value to send. Check the host, range, list, FQDN and service objects that actually exist, and their support in the build. The PAT limitations described earlier still apply. The parameter table explicitly documents a maximum of 60 characters for the service object value or name in TranslatedService, whereas this table states no corresponding maximum for TranslatedSource and TranslatedDestination.
• InboundInterfaces and OutboundInterfaces each contain repeatable Interface entries. They restrict interface matching but do not create a route. The VPN/DNAT conditions explained above also apply to automation: VPN ingress and VPN egress use Any; for DNAT from public to private addresses, egress is also Any. This does not remove the restrictions imposed by Original criteria and firewall rules.
• Name directly under NATRule is the mandatory rule name: a maximum of 60 characters, UTF-8 permitted, no comma. Description is optional and limited to 255 characters. IPFamily allows IPv4 or IPv6; the reference specifies IPv4 as the default. Status allows Enable or Disable; the documented default is enabled. Explicitly set the family and status in the approved write payload rather than relying on defaults without checking them.
• In the example, LinkedFirewallrule is intended only for creating a Linked NAT Rule within a Set request. Identify the existing firewall rule precisely for this purpose. Linking does not turn the SNAT rule into a DNAT rule or give it guaranteed priority; the Linked NAT limitations remain in effect.

Plan position and interface override separately

Position shows the values top, bottom, after and before in this exact case in the XML example. For relative placement, After or Before contains its own Name with the name of the reference rule. This name is not the mandatory name of the new or edited rule. The example explicitly marks both blocks as applicable only to Set requests. Use only the reference appropriate to the desired placement; do not blindly copy both example blocks. Check the anchor’s existence and current position beforehand, then verify the order actually saved. A successful object status does not yet prove that the planned traffic matches this rule first.

OverrideInterfaceNATPolicy is a separate switch with Enable or Disable, a documented default of Disable, and a relation to interface-specific SNAT source translation. The corresponding InterfaceNATPolicyList belongs to the planned case only when the override is enabled. It contains repeatable Override blocks with specific_interface for the outbound interface and specific_translatedsourceid for the translated source required there. The specific interface described as mandatory is therefore a requirement within this conditional override case, not a requirement for every NAT rule.

At one point, the example comments use the different name OverrideInterfaceDefaultNATPolicy, whereas the element and parameter table use OverrideInterfaceNATPolicy. Do not invent an additional XML tag from this. The table describes the list as optional with a default of NULL; this is not an instruction to send the text NULL. The example also provides no clear location for the monitorindex mentioned there. If automation depends on such unresolved details, clarify them in API help for the installed build or with Support before writing; do not guess additional syntax or effects.

Load balancing and health checks are conditional fields

NATMethod is relevant to the DNAT distribution case, not a mandatory selection for an ordinary SNAT rule. The API reference describes its applicability in terms of the Hosted Server source zone WAN and a Protected Server of type IP Range or IP List. Do not adopt these older terms as additional XML fields absent from the example. The documented values are Round-robin, First_alive, Random, StickyIP and OnetoOne; the reference default is called Sticky IP. Guidance on choosing between the five methods and the equal address count required for One-to-one is provided above.

HealthCheck allows Enable or Disable and is described in the API table as optional, with a default of OFF, and applicable only to load balancing. This does not mean that every NAT request needs health-check fields. Nor does it guarantee that First_alive should operate without checks: the specific NAT guides enforce the health check for First alive. For this case, deliberately plan the check and its values and verify them in the saved state, rather than relying on the general OFF default.

When the health check is enabled, the probe values are in the LoadBalance block:

• ProbeMethod: ICMP or TCP. The mandatory designation applies here to the active health-check case.
• Port: only for TCP, range 1–65535; do not infer a general port requirement for ICMP.
• ProbeInterval: probe interval in seconds, range 5–65535, documented default 60. The range comes from the parameter table; the empty example element does not specify a numeric value of its own.
• ResponseTimeOut: response deadline in seconds, range 1–10, documented default 2.
• DeactivateHostAfter: number of unsuccessful probe attempts before deactivation, optional, range 1–10, documented default 3.

Do not detach the mandatory designations for method, interval and response deadline from their context of an enabled health check. These details also confirm only the API contract described. Whether the probe, service and required failover work must be checked using the new traffic flow described above and a planned failure/recovery test.

Evaluate NATRule responses for the specific object

The following mappings come from Status Message Information for this object. They are XML object status codes, not HTTP status codes. The Message.* values are unresolved message keys from the reference, not verified firewall message texts. Therefore, assess the operation, code, actual response and saved state together; do not infer a limit or a safe retry from the key name.

• Add NAT policy: 200 is associated with Message.NATPolicyAddSuccess, 500 with Message.NATPolicyAddFail and 502 with Message.NATPolicyRecordExists.
• Edit NAT policy: 200 is associated with Message.NATPolicyUpdateSuccess, 500 with Message.NATPolicyUpdateFail and 502 with Message.NATRuleUpdateRecordExist. In particular, the 502 key differs from the one for creation.

The same additional mappings are documented for both operations, Add NAT policy and Edit NAT policy:

In particular, 504 must therefore not be interpreted here solely according to the general API table as a deletion that failed because of a reference: these NATRule rows belong to Add/Edit and specify the port conflict key. Despite their identical key, codes 548 and 549 do not establish a specific maximum number of servers either.

Before every subsequent write attempt, including after a timeout or apparent success, read the NAT entry actually saved and check it in Rules and policies > NAT rules: name, family, status, Original/Translated values, interfaces, override mappings, conditional probe values and position. Compare the response with the previously saved state; do not work around conflicts by renaming, broadening criteria or blindly retrying. Unresolved differences must stop the job. Only after verifying the state should you use a new session to check both Rule IDs and the actual translation. For rollback, restore the saved state and order and account for derived rules separately; the practical server publication procedure remains in the DNAT runbook.

FAQ