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

Hi,

please try changing your source port to WAN.

Ian

Hi.  Changed my Source to WAN in Firewall Rule.  Didn't change anything in DNAT.  

Same result.  

Update!  I got it to work by watching this video, but somewhat :D

https://www.youtube.com/watch?v=-ekWg2Lvo5M&t=1006s

First, I did change Source to WAN.  Also changed Destination networks to #Port2 (port connected to WAN)

Second, Went to NAT Rule, and changed source to Any, Original destination as #Port2. 

When I tested this, still failed.

I somehow remembered I've tried changing UDP to TCP before, in XG v.17.  I tried changing everything to TCP, and I was 'seen' from outside.

I know both needs  to be open.  Does this mean TCP allows you to be seen from outside?  And UDP is needed from the inside?  

Why are you working with PAT here? You only need PAT when the destination port on LAN/DMZ differs from the port adressed on the Internet, e.g. port 10080 translating to real port 80 of a Webserver. It makes no difference which protocol stack (TCP/UDP) is used. So if the service on the local server is adressed as UDP12345 the port on the internet will be UDP12345 as well unleast you don‘t want to have the external to access UDP23456 which then will be translated to UDP12345 while NAT-ing. Normally you only do PAT if the original service is allready in use for something else, It is no security plus to change only the external reachable port.

I believe the failure is the firewall rule here. You there have to allow source and destination PRE-NAT. To continue with my example above where the port will be changed in NAT the firewall rule has to be: Source:WAN, network ANY (unless the external allways comes from the same IP), destination Port or Alias that has the adressed external IP, service UDP23456.

At least this is how NAT and firewall work together since XG v18.

Hi kerobra_retired 

You'll see I updated my post earlier, cause I just got it to work.  

By getting it to work, I mean the port 12345 is 'seen' as open from outside.  I used canyouseeme.org.

But come to think of it, your question did remind me of something.  You are right.  I wanted to open ports, and allow it to pass through, but to a specific docker app, that is accessible through IP Address, and port number.  My Server hosts a lot of docker apps.  The Server has a fixed Internal IP Address.  It hosts several docker apps on bridge mode, therefore, each docker app is also using the same IP Address as the server.  Though it's accessible using different ports, e.g. 10.10.15.1:8080 gives me web interface of app 1.  10.10.15.1:8989 gives me web interface of app2.  I'd like traffic to TCP port 12345 to be direct traffic to Server IP address 10.10.15.1 port 7777. 

I've done this in V17.  Don't know how to do it in V18. 

Hi.  Any ideas on this?  

Not sure if I have to narrate it once again, I'll try to be clearer.  Maybe it will help explain the need.

I am using Unraid NAS.  It allows me to use Docker containers.  My NAS has an IP of 192.168.0.5.  When I created Docker containers, it also retains IP address of NAS.  I get to access the Docker containers via NAS_IP_address:8112 (Deluge torrent client).  Deluge requires at least one port open for TCP and UDP to allow incoming connections for seeding.  Though I prefer maybe 5 ports per TCP and 5 for UDP.  I want the traffic to be able to go through to Deluge Docker container only.  And for that container to be able to seed properly.

There are other containers that require opening up of ports as well.  I'll give the scenario of Syncthing (Torrent p2p client).  To be able to access this Docker container, I use NAS_IP_address:8384.  This particular container requires TCP port 22000 to be open, to be discoverable by remote Syncthing client, UDP as well.  As in the case above, I want only Syncthing to have it's TCP port 22000 open.  

With version 18 of Sophos XG, how do you open ports/ port forward given the scenario above.

Does this Post help? 

https://community.sophos.com/products/xg-firewall/f/recommended-reads/121919/how-to-configure-firewall-rule-and-nat-rule-on-xg-v18

Because assuming your Firewall Rule or your NAT rule is not matching, this will not work. 

LuCar Toni to be honest, I've read it over and over.  But since I'm talking about containers, I don't know how specifically to forward it to the Docker container itself, and not just the NAS.  I don't want all Docker containers to be exposed.  

As XG can only difference between the IP and the Port, the basics of networking will give you the option to forward a certain Port or everything to a certain IP.

In Docker, you can give a container a own IP alias, which you could expose, if you like. 

https://docs.docker.com/engine/tutorials/networkingcontainers/

That is more likely a docker question, how to do this. 

I am kinda confused about the statement, you got this running in V17 and not in V18, as the basics behind this never change. 

Actuallly, I was also thinking it may be the only solution for now on the XG v18.  Each Docker container get their own IP.  I hope others can share if they know anything else better.

For v18, I used server access assistant, to create a DNAT rule.  

Internal (NAS IP) External (port 2) Services Deluge TCP 12345 (I created this one)  External source ANY  

In Deluge TCP, Protocol TCP  Source POrt 1:65535  Destination port  12345

When I check open ports using canyouseeme, it says port 12345 is open.

In above scenario, which container gets traffic from port 12345?  All the Docker apps as they all have the same NAS_IP_address?

In v17, I think I have something like this in DNAT

Source WAN, Network, ANY, All the time

Destination:  WAN, Services:  TCP 12345

Protected Servers:  NAS. Port I have 8112 (the container port for me to access Deluge).

Both scenario says port is open, but not sure if doing it right.

What about PAT?  Is this where i would be using PAT?  Allow data through Protocol TCP   Source Port 1:65535  Destination port  (What does it mean by destination port?  When will this be different?)

Actuallly, I was also thinking it may be the only solution for now on the XG v18.  Each Docker container get their own IP.  I hope others can share if they know anything else better.

For v18, I used server access assistant, to create a DNAT rule.  

Internal (NAS IP) External (port 2) Services Deluge TCP 12345 (I created this one)  External source ANY  

In Deluge TCP, Protocol TCP  Source POrt 1:65535  Destination port  12345

When I check open ports using canyouseeme, it says port 12345 is open.

In above scenario, which container gets traffic from port 12345?  All the Docker apps as they all have the same NAS_IP_address?

In v17, I think I have something like this in DNAT

Source WAN, Network, ANY, All the time

Destination:  WAN, Services:  TCP 12345

Protected Servers:  NAS. Port I have 8112 (the container port for me to access Deluge).

Both scenario says port is open, but not sure if doing it right.

What about PAT?  Is this where i would be using PAT?  Allow data through Protocol TCP   Source Port 1:65535  Destination port  (What does it mean by destination port?  When will this be different?)

You should read a bit more of firewall basics and ports/services in general.

When you forward a port from your public IP via NAT and open the port in the firewall the destination system becomes completely responsible for the packets. So first of all the NAS has to handle the incoming packets now. And the docker apps or webservers behave like you configured it. Only the specific port that is targeted will trigger a docker app or webserver. The same port cannot be used twice for different services. If a webserver runs on port 80 it can deliver multiple websites, but then the url gives the decision, which site has to be served.

A firewall can only do 2 things: open a port or not. It cannot decide because of URLs, it can only let a connection through or it can block it. If you need this functionalty you will have to go for the webserver protection if you do not trust the security of your NAS.

PAT is the same as NAT, but for ports. With NAT you translate an IP (typically a public IP) to a local IP, normally the external port will be the same as the internal port, e.g. port 443. With PAT you can translate one port to another, e.g. externally reachable is <publicIP:8765> which points to <internalIP:80>. You can configure things like <externalIP:80> points to <internalsystem1:80>, <externalIP:81> points to <internalsystem2:80> and so on.

A very good explanation

Thank you

Ian

Thanks for the explanation kerobra_retired  So from the looks of it, I need PAT.  I am required to open ports from outside, but want it to go through different port number on the server inside.  

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.

Ok, I think I may have been confused before.  Deluge Docker Container, which is accessible via NAS_IP:8112, has settings that I can adjust under preferences, such as Incoming ports, and Outgoing ports.  8112 is just for me to access the webgui, and not really of any other significance.  Maybe all Docker apps are accessible via web port 80, but since all of them is using NAS_IP, they can't all be port 80, hence, there's distinction between port NAS_IP:8112 (Deluge), NAS_IP:8384 (Syncthing), etc.  Under each container, it's where I need to set Incoming and outgoing ports.  So not all containers listen on all ports.  As you explained above, the firewall only opens, and close the ports.  It's up to the Apps to listen on certain ports (when it is open).  Correct?

If above is correct, I want to allow incoming port 12345 to my Deluge Docker Container, This is what I've done so far:

Create Service Deluge TCP 12345

Protocol TCP, Source port 1:65535 Destination port:12345

I added NAT rule, Server access assistant (DNAT)

Under Select IP host, I selected NAS_IP

Under Public IP address, I selected #Port2 (my WAN interface)

Under Services, I selected Deluge TCP 12345 (service created above)

External source networks and devices, selected Any

Does above sound right?

Sounds right.

The thing where you have to allow incoming and outgoing ports is the one that controls, which of your docker apps will receive the connection. All other docker apps won't be able to get the connection on the same port.

From a logical view the Deluge docker app will then have open the ports 8112 and 12345. If 8112 is only for you for management, only NATing 12345 should be enough.

Yes, seems 8112 is the management port, not really where ports should be forwarded to.  

Deluge also requires UDP of the same port number, e.g. 12345 to be open.  Under original service section, can TCP and UDP be placed together?  Saw on example in firewall rule where 2 service are together, such as SMTP and SMTPS.   

The rule created by Server Access Assistant for Deluge Docker Container has source as ANY.  I guess whis won't hurt as opposed to #port2 ?  Any only includes #port1, and Vlan, and VPN?  So mostly internal customers except for VPN.

How do I tweak NAT (if still the correct service) to open outgoing?  Deluge says it requires me to open port range e.g, 5000-5005 for outgoing.  I don't think the Server Access Assistant will work here.  I'll need to fill things up manually.  What do I put in:

Source:  LAN. Original Destination:  #port1?  Original Service:  Deluge TCP Outgoing port range?

Translated Source (SNAT): Original Translated Destination (Original) Translated service (PAT): Original

Inbound interface ANY Outboud interface ANY?

Normally you do not have to care about NATing outbound traffic. MASQuerading is here the name for it. Technically it is a SNAT (source nat), what we were talking about until now is DNAT (destination NAT). With masquerading the first IP address of your WAN interface is used, when a local IP address is making a connection to the internet. Since local adresses (like 192.168.0.1) are not routable on the internet the router/firewall exchanges the original source address to its own WAN IP. So the destination servers know the "way back" to serve the request.

What you do have to care about is a firewall rule. In most cases (home routers) any outgoing traffic is allowed by default. With a firewall like a Sophos XG you have more control about it, giving you the possibility only opening the needed ports and leave the rest closed.

Regarding your question about TCP and UDP: I would recommend using one definition for one service (Deluge "TCP 12345" and "Deluge UDP 12345" for example). Then one NAT rule for each service and one firewall rule for eachs service. With the "hit counts" to firewall and NAT rules you can then see, if one of them is useless. If the rule has 0 hits, simply disable/delete it.

ANY means ANY, not only local adresses. The firewall zone plays a lot of importance here, too. "Any" in WAN means every possible public IPv4 adresses.

kerobra said:

 

Regarding your question about TCP and UDP: I would recommend using one definition for one service (Deluge "TCP 12345" and "Deluge UDP 12345" for example). Then one NAT rule for each service and one firewall rule for eachs service. With the "hit counts" to firewall and NAT rules you can then see, if one of them is useless. If the rule has 0 hits, simply disable/delete it.

 

This makes a lot of sense. 

Sorry, I don't quite get the explanation opening ports for outbound traffic. 

When an app such as Deluge says it requires me to open outbound ports on my firewall, say a range of 5001 to 5005, I shouldn't look at NAT rule. Instead, what do I do?  Do I just create a new firewall rule?  With Service Deluge TCP Range: 5001:1005?  

Thanks!

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.