Need help to fix Port forward UDP from external to Internal Server Different ports (port Translation)

Question

My setup. 
 
 External need to access Internal Server, UDP port 12345. 
 
 I created a Firewall Rule first: 
 
 Named the Rule, Rule group (Traffic to Internal Zones) 
 Action: Accept 
 Source zones: Any Source networks and devices: Any During scheduled time: All the time 
 Destination zones: LAN Destination networks: #Port1 (my port connected to internal network) Services: deluge udp (Protocol UDP/ Source port 1:65535 Destination port: 12345) 
 Nothing selected in Match known users, web filtering, App Control, and IPS 
 
 I created a NAT Rule: 
 Named the rule 
 Original Source: #Port2 (where my modem / Internet source is connected) Original Destination: Local subnet (192.168.1.0 with subnet /24) Original service: UDP 
 Translated source (SNAT): Original Translated destination (DNAT): Server (IP Address of my server) Translated service (PAT): deluge UDP (Protocol UDP/ Source port 1:65536 Destination port: 12345) 
 Interface matching criteria left as is: Inbound interface: Any Outbound Interface: Any 
 
 When I check from canyouseeme.org, and check port 12345, it says it cannot see the service on MyPublicAddressHere).

kerobra_retired · Accepted Answer

No you don‘t. 
 You have all of your docker apps (webservers) locally running on different ports as you said initially. But they are all running on the same local IP/server. 
 For this scenario NAT alone is all you need. You create a NAT rule for each port/webserver you want to be reachable from the internet using the same port as you use to connect via LAN. You CAN use PAT in this scenario to ‚hide‘ your locally used ports from the internet but the minimal gain in ‚security‘ (in my opinion it is zero) is not worth raising the complexity for your firewall rules. 
 You only really need PAT when all of your apps would run on the same port, but different local IPs. In most conditions you only have 1 public IP and there, each port can only be used once/for one service. So if you wanted to expose two apps/services that locally both use 8080 you could only publish one of them in the internet with port 8080. For the other app/service you would have to use another port on the internet, e.g. 8081, locally it would stay the same. There you would need PORT (i hate the ‚ADRESS‘ here) TRANSLATION. 
 When your app needs more than one port open you simply create another NAT rule without touching the port. If your app locally does react to 8080 and 8088 then create two NAT rules, one for 8080 and one for 8088. 
 If your app locally does not listen on a specific port it would make no sense creating a NAT rule for that port. 
 As I said above, with NAT (AND PAT) the destination system becomes responsible for the connection. If there is a security problem with the app/service you expose to the internet the firewall alone can‘t protect it. So I would recommend two things: install all security updates/patches for your apps and don‘t do that only once, do it regularly. 
 Second thing: use IPS in the firewall rule (WAN to LAN for example) as this can protect you against known security problems. But don’t only rely on it. It is an additional security layer to properly patched systems. 
 And my last two cents: if you do not really know what you are doing leave it better to someone who does. We have already too much botnet zombies out there.

kerobra_retired · Answer

If I didn't get it right you are on v18 now, correct? 
 Then under "Rules and policies" / "NAT rules" you should see a SNAT rule at the very end of the list called "Default SNAT IPv4" (or maybe IPv6, too, that depends on your internet provider). When you look closer into that rule you can see that it covers all incoming connections ("Any" Original source, "Any" Inbound interface") and the Outbound interface that you defined as your WAN interface. Under "Translated source (SNAT" you should see the default MASQ rule and any other set to "Original". 
 That means everything that leaves your network over the WAN interface will get source-NATed with masquerading. Masquerading uses the public IP of the WAN interfaces for connections from your LAN devices to the internet since a webserver in the internet can't answer requests from your PCs local IP adress for example. 
 
 If you have an internet connection with more than 1 IP adress (e.g. a /29 subnet) then you can use more specific SNAT rules, in most cases this is for example used for an email appliance/gateway that must be resolvable both "forward" through MX (like "mail.yourdomain.com") as backwards to it's IP (like "123.45.67.89" containing a RDNS record) to be more "trusted". But that only mentioned besides. 
 
 So with your "Default SNAT IPv4" NAT rule all outbound connections are covered from the "NAT side" out of the box. What you do have to do is allowing the outbound traffic with "Firewall rules". If you already have an allow rule that allows all traffic from "Source zone LAN to Destination zone WAN" you do not have to use extra rules for your docker apps at all. But like with the incoming rules, I would recommend splitting outgoing rules into smaller parts, so: 1) that you can see, if it is even used at all and 2) are able, to be more specific to the usage of the additional security features like web filtering, IPS, App control or QoS (traffic shaping). 
 
 In XG the Firewall and NAT rules are executed from top to down. If an entry matches the actual connection further rules are not applied. So maybe you have to care about the position of your rules in the ruleset, especially the firewall ruleset. 
 
 When configuring firewall rulesets for my customers I normally do the following: - top rules: incoming NAT connections, if used and webserver protection rules. - after that: Site-to-Site- and/or RAS-VPN-rules. - then: connections between local zones of the firewall like DMZ, (v)LANs - last: outgoing connections by zone, allowing so much traffic as specifically needed. 
 For the outgoing connections there are some "special cases" (e.g. traffic that should not be proxied), these are bound to specific local IP adresses and/or destinations. These come before the more general rules that cover the whole subnet or zone (like "web surfing" or something like that) just before the "Drop all" rule.