SonicWALL SD-NAT (loopback NAT) for internal published services

If you're having a small network with a SonicWALL firewall and you've published a service using destination NAT (DNAT) to the internet (or another interface/networks), you sometimes want to to access the same published service using the same (public) address from the inside.

Example:

When SystemB is in the same subnet or same network zone as the API-Gateway and you want to access the API-Gateway address from SystemB, you can either use SplitDNS (internal DNS resolution resolves the public FQDN to the internal address), or only use public ip-addresses in that network/zone, or provide the API-Gateway multiple virtual addresses, or you use a "lookback NAT" which is a source- and destination-NAT at the same time.

The SonicWALL then changes the destination ip-address of every DMZ packet from the external ip-address of the API-Gateway to the internal ip-address of the API-Gateway and at the same time, changes the source ip-address from SystemB to its own internal interface ip-address. Changing the source-address makes sure that the API-Gateway does not sends the traffic directly back to SystemB, but instead to the SonicWALL, which then changes back the destination-NAT for the answered packets.

In the SonicWALL NAT-Table this setup looks like this:

Of course you have to setup the suiting access-rules in the SonicWALL as well. Keep in mind the SonicWALL internal traffic flow first checks the access rules, then changes the address using the NAT table. So you may have to setup Rules like DMZ>DMZ (or LAN>LAN) but as a destination the WAN-address objects!

I've set this up in many setups for over 10 years with very different SonicWALLs, FortiGates and other Firewalling-devices, and it works well (e.g. tested with SonicWALL on SonicOS3/4/5/6 from TZ-series, NSA-series to SuperMassive-series).
🚩However keep in mind, opening services using NAT might be a possible security-hole (for example VPN might help), publishing services to the internet always should go through an application reverse proxy like a WAF, API-Gateway or something else, the published services should be hardend, closely monitored and be located in a DMZ, have strong encryption and authentication (mutual TLS). Also I personally prefer to use SplitDNS and different virtual addresses in order to keep original ip-addresses (not having to use X-Forwarded-For which might cause lots of logging-volume on your logs/Logging-System/SIEM) etc.

SonicWALL firewall internal packet flow

I've worked with SonicWALL firewalls for over 10 years in hundreds of different installations. In order to understand how a firewall handles traffic, it helps to know how traffic is treated interally. For example it helps to know if the nat engine is traversed before the policy check or after, in order to configure the nat-policy and the access rules correclty.

Since generation 5 SonicWALL firewalls use cavium octeon cpus and they process everthing in cpu. This is a strength and a weakness of the firewall, after it can treat traffic very dynamically and using software-updates the handling of the traffic can be changed. However compared to for example asic processor architecture the performance usually is lower. So there are pros and cons.

The SonicWALL firewall internal packet flow looks like the following:

 Packet fragmentation is handled as follows:

The packet capture feature can be helpful to understand the packet flow. However in rare cases it can mislead you after it is not 100% accurate when facing bugs in SonicOS:
https://www.sonicwall.com/en-us/support/knowledge-base/170513143911627