Multiple Source IPs in NAT rules

Lucas_Wilson

Hi,

I currently have a Web API that requires HTTPS traffic forwarding to our internal Web server through the USG Flex H series.

We've got a group of IPs that all require this same NAT rule applying to them, but I couldn't figure out a way to do this and as a result I have had to configure 6 individual NAT rules that virtually do the same thing, just with a different source IP.

Is there not a way to reference an IP Address Group object as a Source for a NAT rule?

Any help appreciated.

Lucas

PeterUK

Its a good idea but at this time you can not which seems odd why they didn’t at the time.

Its also my hope they add FDQN (non-wild card) support for Source IP NAT.

Zyxel_Melen

Hi @Lucas_Wilson

On the USG FLEX H series (running uOS), the NAT (Virtual Server) configuration currently requires a single IP address or "Any" for the Source IP field. It does not natively support selecting an Address Group object directly within the NAT rule settings at this time.

To achieve your goal without maintaining six separate NAT rules, you can use the following approach:

1. Simplify the NAT Rule: Set the Source IP in your NAT (Virtual Server) rule to `Any`. This allows the NAT translation to trigger for any incoming traffic on the specified port.
2. Restrict Access via Security Policy: Since NAT only handles the translation, the actual access control is managed by the Firewall/Security Policy.
   1. Go to Object > Address > Address Group and ensure your 6 IPs are grouped there.
   2. Navigate to Security Policy > Policy Control. Create (or edit) the rule that allows traffic to your internal Web server (usually from **WAN** to LAN/DMZ).
      1. In the Source field of this security policy, select your Address Group object.
      2. Set the Destination to your internal server's IP and the Service to HTTPS.
   3. By setting the NAT rule source to `Any` and restricting the Security Policy to your specific Address Group, the firewall will drop any traffic from IPs not included in your group before it reaches the server, effectively achieving the same result with only one NAT rule and one Security Policy rule.

I hope this helps! Please let us know if you have any further questions.

Lucas_Wilson

Hi @Zyxel_Melen,

Thanks for your response.

Unfortunately, this approach isn’t particularly helpful for our use case.

With your suggestion, the issue we would encounter is that when staff connect via the full-tunnel client-to-site VPN, all of their HTTPS (port 443) web browsing would be redirected to the internal web server.

I hope this feature can be added in a future firmware update, it exists on many other SMB firewall brands.