[SOLVED] SNAT versus Port Forwading

[Lonniebiz]

When I say domain, I'm simply talking about a website domain such as abc.com, or cba.com, or bca.com.

Perhaps I should have said I have 40 websites that are spread arbitrarily between 3 public IPs.

As for your other question, the issue is that I'm not confident that Zentyal will OUTBOUND convert internal IPs to External IP's correctly. From what I understand, port-forwarding is an inbound technique for forwarding from and external public ip and port INBOUND to an internal ip and port. Are you saying the with port-forwarding alone, replies from the windows web server will always go back on the same public IP that they came in on (were requested on) Inbound to the webserver?

Since my window's webserver has more than one private IP, how do I know that each private IP will be converted to the correct public IP on the reply outbound? There is nothing that explicitly implies that it would.

Therefore, I'm using SNAT to explicitly tell Zentyal the correct outbound mapping between internal IP and public IPs.

If one of my websites is requested, the authoritative DNS, which is not Zentyal is going to tell the user's browser that the website is located at say 55.55.55.55.

Then the browser will send a request for abc.com to Zentyal public virtual interface for 55.55.55.55. Zentyal will forward this to 192.168.0.5:80, which is my window's webserver.  The web server is set to only accept request for abc.com on 192.168.0.5. It replis with the webpage, and now Zentyal must convert 192.168.0.5 back to 55.55.55.55. From what you are telling me, you say it will do this automatically, right? Perhaps that's so. Yet I've created SNAT rules to ensure this fact. Are you saying that's totally unnecessary? Are you saying that by doing port-forwarding it is effectively implied that it will go out on the same public IP it came in on?

I thought the purpose of SNAT was to control IP translations outbound. I thought port-forwarding was to control things inbound. Please disabuse me of my misconceptions. If this isn't what SNAT is for, then why would you ever use it?

It seems to me, that the purpose of SNAT is to ensure that internal IPs are translated to particular public IPs while traveling outbound through Zentyal. Is this not so?

[half_life]

If you have already taken care of the public IP's via port forwarding, isn't it as simple as adding the same port forwarding rules with snat enabled for your internal networks?  Caution -- be careful not to include your Zentyal servers internal IP address in the snat -ed range.

[christian]

This is a bit clearer now.
We can discuss forever, you've decided to achieve it using SNAT, do it it indeed works.

SNAT is not required for external users. Port forwarding is enough.

For internal users, you have different approaches depending on different parameters like DNS, proxy and network layout.

- if internal users rely on external DNS, either because they don't use proxy or because you haven't defined these web sites on Zentyal (or other internal) DNS, then SNAT will do the trick

From network standpoint, this is, at least to me, quite strange however: in order to reach local web site (as I understand that web server is on same network as internal users), users will go to Zentyal's external interface, re-enter Zentyal from outside to reach internal web server thanks to port forwarding. Then, thanks to SNAT, such internal user will be seen as external, therefore packets from web server will go through Zentyal again before traversing one more time to be send to internal client. Wow !!! 

How can you avoid this ?

1 - obviously defining DNS entries so that these web sites are known internally with their internal IP.
2 - another option is to have internal users using explicit HTTP proxy (assuming this proxy is the Zentyal one):
   internal user sends request to proxy. Proxy (Zentyal) resolves name using external DNS, thus requests external public IP that is forwarded to internal web server. answer goes back to proxy (Zentyal again) which relays to internal end-user. Not tested here but this should work

[Lonniebiz]

According to jbahillo's explanation of SNAT (which is the second posting in this entire thread), there are two type of Network Address Translation (NAT) in Zentyal:

1) Destination Network Address Translation (DNAT), which is call “Port-Forwarding” under Zentyal's Firewall menu. This is intended to be used on INBOUND ( or in other words INCOMING traffic ). Or in other words still, it is used for traffic that's source is EXTERNAL from Zentyal's perspective and whose DESTINATION IP/port must be translated before it can be routed internally. A practical example to consider, is mine, where I have a windows webserver inside my Zentyal network which is assigned a private IP address. This web server has no knowledge of any Public IP addresses. Therefore, without Zentyal's help, no request from the internet can possibly be routed to this webserver, because it will not answer for any public IP address on the internet, and furthermore (without Zentyal's help through port-forwarding) no public traffic would ever be routed to this internal windows web server. In order for this web server to received a request from the internet on port 80, the traffic would first be routed to a public IP address utilized by the Zentyal gateway which is on its external interface (a Public IP address must be assigned to Zentyal's external interface directly, or virtually assigned to Zentyal's external interface by adding an additional virtual public IPs to Zentyal's public interface). DNAT port-forwarding is used, so that a request from the internet, made to a public IP on Zentyal's external interface, is then passed to a private internal IP of the windows webserver connected to Zentyal's private internal interface.

This port-forwarding rule has now facilitated INBOUND traffic to the web server using a Zentyal gateway. But, now, what about OUTBOUND traffic, for when the windows webserver replies to the request from its own internal private IP address? Again, without Zentyal's help, the source IP of that reply would be an internal IP address. So therefore, on the way out of the Zentyal gateway, another network address translation is needed, so that when the user on the Internet receives the webpage, it is sourced  from a public IP. Well, if your Zentyal server only has one public IP address, Zentyal is smart enough to do that outbound source network translation automatically.  However, if you have multiple public IP addresses assigned to Zentyal's external interface, is Zentyal smart enough to outbound-sourceIP-translate replies from the webserver's private IP address to the same public IP address that the request initially was port-forwarded from? I don't think it is, and that's why you need SNAT.

2) Source Network Address Translation –  located at Zentyal > Firewal > SNAT. While DNAT port-forwarding is used for translating destination IP/ports for incoming traffic, SNAT is used to translate SOURCE IP/ports for outgoing traffic. This is particularly necessary in circumstances where Zentyal has muliple Public IP addresses assigned to its external interface, and it ensures that packets with a particular private-sourceIP-addresses are converted to a particular public-sourceIP-addresses before being routed through the Zentyal gateway.


To me, it seems the essence of comparing the SNAT to Port-forwarding, is that one is used to translate sources and the other is used to translate destinations. If you want to make sure that outbound traffic is source from a particular public IP addresss and port, use SNAT. If you want to make sure that INBOUND traffic gets routed to a particular private IP address and port, use port-forwarding (DNAT).

@half_life – When you add a port-forwarding entry, there is a check box that says "Replace source address" ( Replaces the original source address of the connection with the Zentyal's own address. This could be necessary when the destination does not have a return route or has restrictive firewall rules)

I have not tested this feature. To me, the description given (for this checkbox) is unclear. I'm not sure it be sophisticated enough to replace the source IP address with the correct public IP when mulitple public IPs are assigned to Zentyal's external interface.

[christian]

I start understanding better what you don't understand, I hope.

Let's split it into small part in order to not mix-up everything.

Access from internet:

- you internal web server has internal IP that is unknown from outside.
- port forwarding, listening on Zentyal's external interface, will redirect requests made on specific port to internal IP. You don't need anything more than this. Why ? because web server will not "send" any network packet to external client but only reply to incoming packet and this incoming packets do contain source IP. If Zentyal is defined as your default gateway, web server doesn't need to know how to reach this external IP. packets are sent back to Zentyal (default gateway) and Zentyal handles forward back to client.
- you will notice on my above explanation that I describe "port forwarding" as request made on specific port. If, as you perhaps do, forward all requests made to 55.55.55.55 to 192.168.0.5 for same port, then your internal server is happily fully exposed to internet as if it was connected outside. This is perhaps not what you want isn't it   
- you will also notice that I clearly (I hope) say that Zentyal must be default gateway for web server. In case it's not, then you do need SNAT in addition to port forwarding.
- one point however to be taken in account: if you have multiple external IPs on Zentyal, default route will use only one single IP (as explained above) that will differ from the one used for incoming packets. In such case, packets will return back using different route without SNAT.

Access from you LAN:

We have discuss it already at length. You can use SNAT if you want... but I would not promote this.

To summarize, I think you have 2 very different problems deserving to be discussed in dedicated threads:

- access to internal web sites from internet
 => my answer is reverse proxy is the first choice is you have many sites. Then port forwarding. SNAT to be used only in some very specific cases. Never use full IP (all ports) forwarded internally !

- access from LAN to internal sites that are only defined on external DNS:
 => my preferred choice is to define such sites on internal DNS.

[christian]

Regarding access from internet, what I would like to highlight is that using reverse proxy instead of port forwarding and SNAT and stuff like this, you will need only on external IP plus you will have full control on what you redirect inside and where.
This will provide much more flexibility in addition to much higher security because only HTTP requests handled by reverse proxy will be redirected.
Furthermore, you may introduce here URL rewriting and similar stuff if needed.
On top of that, it can be often quite "generic" meaning depending on how your internal sites are organized, you are not obliged to define each andevery server at reverse proxy level.

This will make your deployment network independent, meaning you can move internal site from one server to another without having to change anything but internal DNS and you can even add load balancing plus failover if needed.

Well, plenty of advantages, the only real cons being that such component doesn't exist out-of-the-box in Zentyal's design 

[Lonniebiz]

Christian,

Thanks for being so thorough. You mentioned my circumstance for implementing SNAT to begin when you said:

“- one point however to be taken in account: if you have multiple external IPs on Zentyal, default route will use only one single IP (as explained above) that will differ from the one used for incoming packets. In such case, packets will return back using different route without SNAT.”

My current setup is successfully using SNAT to ensure that the source IP address is the same Public IP address that was originally requested by the internet user's browser (and not Zentyals default route IP address).

I agree with your warning about only forwarding ports and not the whole IP. It is kind of interesting to me how port-forwarding basically circumvents the firewall's packet filter rules, in that the packet filter rules may be blocking a port, but by implementing port-forwarding you are kind of poking a whole in the firewall for that port. Yes, I certainly wouldn't want to do that for all ports (even though the windows webserver does have a firewall of its own blocking all unnecessary ports).

Regarding access to these websites from the LAN, currently when I try to access one of these website, the web browser gets the site's public IP address from DNS, so the browser then sends the request to the public IP through Zentyal's internal interface to Zentyal's public interface.

Here's what happens next. Instead of Zentyal forwarding this request to the windows web server (back on the internal LAN), it instead tries to service the request using Zentyal's own apache webserver and I get the “It works” page. Apparently, those port-forwarding entries I've added previously (for traffic from the internet) do not apply for traffic that comes to Zentyal's external interface from Zentyal's internal interface.

Although you were suggesting it for internet user's access, I can see how I might use your suggestion of port-forwarding to fix this internal access issue, because when you add a port-forwarding entry, you can specify the internal interface instead of the external interface as I've been doing so far. Perhaps I could just add additional port-forwarding entries to the internal interface for routing these public ips internally.

I don't understand the concept of reverse proxy in the context of how that is used in Zentyal, I'll have to look that up.

Here's the problem I have with using internal DNS. Each time you add additional website to the windows web server, you'll have to also add an additional internal DNS entries to Zentyal. Ideally, I'd like to implement a solution that solves this problem at the IP level, because the number of websites may grow, but the number of IP addresses mappings will remain 3.

[christian]

Regarding internal users, I don't understand how you conceptualize this 
Why can't you have internal users using internal DNS first ? that's so easy and useful.

I'd like to implement a solution that solves this problem at the IP level, because the number of websites may grow, but the number of IP addresses mappings will remain 3.

Wait a minute: why would you have one IP = one web site ?
Adding DNS record for new web site is a matter of few seconds, let say one minute it you take plenty of time. Less time to do it than to explain it here BTW. So there is clearly no administration overhead, however perhaps need for synchronized action if you are not the one creating new web sites here and there but no more than this.
Thus you can have one single IP handling as many web sites as you want. e.g. look at Zentyal vhost. There is no need to add new IP when you add new vhost.  (hum... pay attention to HTTPS  )

What could reverse proxy bring here ?

Reverse proxy basically listen for HTTP requests on one single IP and handled this request, like proxy would to, to send it to real web server running behind this reverse proxy.
Like for standard proxy where end-user request stops at proxy level which sends another request outside, with reverse proxy, external request ends at external reverse proxy border and reverse proxy sends HTTP request inside. In te meantime, you have plenty of feature to control, authentication, rewrite, redirect etc... and not IP forwarding.

If you realize that all this long debate is mainly due to the fact that you have built solution based on multiple IP addresses to segregate (?) services, you may also realize that using one single IP and component designed to handle such kind of request is clearly the right approach.

BTW, why don't you use only one single IP ? because of HTTPS ?  because of different domains ?

[half_life]

@half_life – When you add a port-forwarding entry, there is a check box that says "Replace source address" ( Replaces the original source address of the connection with the Zentyal's own address. This could be necessary when the destination does not have a return route or has restrictive firewall rules)

In this case you are forwarding your internal network while rewriting source address.  It is SNAT .   I also do not share your belief that one is more complicated than the other. 

Some thoughts for future expansion:   If you really expect to grow the number of sites responding on each IP address you might now consider how you will implement load balancing.  That is of course unless you truly expect to remain static in size. 

[Lonniebiz]

Update: The message below is not the final solution, so don't implement it. A better solution is arrived at later in this thread.

Wow. I've got it working perfectly, without the need to enter internal DNS entries for each of the 40 websites!
Thanks for everyones help. You've all given me enough understanding to pull this off.

I will tell you exactly how I did it:

In summary, I've added 3 virtual interfaces to Zentyal's external interface, so that Zentyal can handle traffic for 3 additional public IP Addresses: 55.55.55.55, 55.55.55.56, 55.55.55.57.

I have a windows webserver inside the Zentyal network assigned these private IPs: 192.168.0.5, 192.168.0.6, and 192.168.0.7.

I essentially need the following mappings:

55.55.55.55:80 gets served by 192.168.0.5:80
55.55.55.56:80 gets served by 192.168.0.6:80
55.55.55.57:443 gets served by 192.168.0.7.443


This webserver serves over 40 websites. One website has a dedicated IP 55.55.55.55 (for SEO considerations) , and the other websites are mainly on 55.55.55.56, and the other IP is dedicated to a SSL website.

So that internet users can access the windows webserver via 55.55.55.55, I have this port-forwarder:

Code: [Select]

interface: eth0
Orginal Destination: 55.55.55.55/32
Protocol: 80
Source: Any
Destination IP: 192.168.0.5
Replace Source Address: No
So that internet users, will see 55.55.55.55 as the source address on replies by the windows webserver, I have this SNAT entry:

Code: [Select]

SNAT address: 55.55.55.55
Outgoing interface: eth0 eth0:object1, eth0:object2, etc
Source: 192.168.0.5
Destination: Any
Service: Any
So that LAN users may also access all websites served by 55.55.55.55, I added this port-forwarder to eth1 (not eth0). Also notice that I had to check the box for "Replace Source Address", which I didn't do this for my port-forwarders on eth0:

Code: [Select]

interface: eth1
Orginal Destination: 55.55.55.55/32
Protocol: 80
Source: Any
Destination IP: 192.168.0.5
Replace Source Address: Yes

Here's the port-forwarder allowing internet users to access this same windows webserver via 55.55.55.56:

Code: [Select]

interface: eth0
Orginal Destination: 55.55.55.56/32
Protocol: 80
Source: Any
Destination IP: 192.168.0.6
Replace Source Address: No
So that those internet users will see 55.55.55.56 as the source address on all replies by the windows webserver I have this SNAT entry:

Code: [Select]

SNAT address: 55.55.55.56
Outgoing interface: eth0 eht0:object1, eht0:object2, etc
Source: 192.168.0.6
Destination: Any
Service: Any
So that LAN users may also access all websites served by 55.55.55.56, I added this port-forwarder to eth1 (not eth0). Also notice that I had to check the box for "Replace Source Address", which I didn't do this for my port-forwarders on eth0:

Code: [Select]

interface: eth1
Orginal Destination: 55.55.55.56/32
Protocol: 80
Source: Any
Destination IP: 192.168.0.6
Replace Source Address: Yes
Here's the port-forwarder allowing internet users to access this same windows webserver via 55.55.55.57:

Code: [Select]

interface: eth0
Orginal Destination: 55.55.55.57/32
Protocol: 443
Source: Any
Destination IP: 192.168.0.7
Replace Source Address: No
So that those internet users will see 55.55.55.57 as the source address on all replies by the windows webserver I have this SNAT entry:

Code: [Select]

SNAT address: 55.55.55.57
Outgoing interface: eth0 eht0:object1, eht0:object2, etc
Source: 192.168.0.7
Destination: Any
Service: Any
So that LAN users may also access all websites served by 55.55.55.57, I added this port-forwarder to eth1 (not eth0). Also notice that I had to check the box for "Replace Source Address", which I didn't do this for my port-forwarders on eth0:

Code: [Select]

interface: eth1
Orginal Destination: 55.55.55.56/32
Protocol: 443
Source: Any
Destination IP: 192.168.0.6
Replace Source Address: Yes

[christian]

Now make yourself a favour and draw it on an paper 
Does it really make sense to have all these flows through Zentyal with all this rewriting stuff   

Well, at least it works  and if you are happy enough with this solution, please stamp your first post title as [SOLVED]

[Lonniebiz]

I'm very happy with this solution, because with it, I've prevented having to add 40 internal DNS entries in order to serve these websites internally on the LAN.

Furthermore, upon adding additional websites to this windows webserver (in the future), I will not have to touch my Zentyal configuration; those additional website will be using the same IPs, everything will automatically route correctly internally and externally with out touching the current Zentyal configuration.

Thanks for all the help!

edit: Actually, I discovered some issues, read on to see the final solution.

[Lonniebiz]

Bad news. I just discovered a negative consequence to the solution we discovered yesterday (the one that I've outlined in detail in a previous reply).

Although the web pages became accessible from both the internet and the local LAN (which was the objective), I've discovered an issue with source addresses not being the actual source and instead being 192.168.0.1 (the internal interface address of Zentyal).

I expected this to be the case for the port-forwarder I added to eth1 (the internal interface), but after adding that port-forwarder to eth1, it also effected the source address of users accessing web pages from the interent; instead of there source IP being their actually source IP (from the windows web server's perspective) it was instead 192.168.0.1 (even though I did not check "Replace Source Address" for the port-forwarder on eth0).

When I remove the port-forwarders on eth1, then internet users' source IP is again correct. Apparently, the port-forwarder on eth1 is somehow translating the source IP for the internet users also. I guess that do indeed pass through eth1 to get to the windows web server, but I thought that by that time the destination would have already be translated by the port-forwarder on eth0 and therefore I thought eth1's port-forwarder would not Replace source due to that fact :

Code: [Select]

interface: eth1
Orginal Destination: 55.55.55.55/32
Protocol: 80
Source: Any
Destination IP: 192.168.0.5
Replace Source Address: Yes
If I uncheck "Replace Source Address", this also prevents internet users from having Zentyal as their source IP, but without checking this box, internal requests to the windows web server fail. I want to have my cake and eat it too

Back to the drawing board . . . time to reconsider other suggestions already posted. I let you all know how I ultimately resolved this.

[christian]

Bad news. I just discovered a negative consequence to the solution *we* discovered yesterday (the one that I've outlined in detail in a previous reply).

Do not mix-up everything 
This is not the solution we discovered but the one you try to build.
We are spending (wasting ?) time trying to explain to you that such complex stacking of port forwarding + SNAT for both external and internal clients in order to not spend few minutes dealing with DNS entries makes very little sense if any.

But you have to learn by yourself before you realize that working at the lowest level is not always the best approach  especially when is makes things complex unless you master every single component.

- Trust me or not but using SNAT should be kept for very specific (BTW very few) cases.
- port forwarding is for sure helpful but as soon as you need to deal with large number of web sites, reverse proxy is a must
- and for internal clients, DNS is a so straightforward and easy solution that anything else looks strange

TTFN. 

[Lonniebiz]

What?! 

Christian, it is clearly your fault that I tried this stupid solution. Had you not taught me anything about this stuff I wouldn't have become so dangerous!

Edit: (sarcasm intended)