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.

No comments:

Post a Comment

Azure Managed Identities (technical service accounts)

Explaination Azure Managed Identities = technical service accounts Password is automatically managed, as it was the case in managed service ...