Zentyal Forum, Linux Small Business Server
Zentyal Server => Installation and Upgrades => Topic started by: Lonniebiz on June 25, 2013, 03:41:37 pm
-
Can someone please point me to the documentation that will provide me a more complete conceptual understanding of SNAT as it is used under the Firewall menu of Zentyal?
When you add a SNAT, these fields are requested:
1) SNAT address
2) Outgoing interface
3) Source
4) Destination
5) Service
6) Log
Let say I have public IP 55.55.55.55 and I want a private IP 192.168.0.5 to serve all traffic for that public IP. When someone tries to go to 55.55.55.55, I want that traffic sent to 192.168.0.5, and when 192.168.0.5 uses the internet I want the internet to see it as 55.55.55.55. So, what would I put for the SNAT address, Source, and Destination in this example?
Also, please compare SNAT to Port forwarding. Are these just two different ways of allowing private IPs to serve public IPs? If so, under what circumstances do you suggest using one over the other?
-
Hi Lonniebiz:
I think the best way of understanding SNAT is having an equivalence:
DNAT (standard /destination NAT or portforwarding): Incoming NAT
SNAT (source nat): outcoming destination.
Case where you don't need snat: Your zentyal has an eth0 with a single public IP (or behind a router which still has a single public IP), and you have a , say, webserver behind that Zentyal. Then you will only need DNAT for allowing incoming packages to get redirected to that webserver. You don't have to care about the outgoing ones as they will go out (as every package) through that public IP
This would be different if eth0 has two or more public IP's. Say x.x.x.x and y.y.y.y. Let's say that standard traffic goes out through x.x.x.x, but requests to the webserver come acros y.y.y.y IHere you need SNAT to do NAT1:1, in a mirror way, as if you only set DNAT packages will arrive from y.y.y.y to the server but will go out through x.x.x.x (which the original requester knows nothing about)
Then you have to use here DNAT for the incoming packages on y.y.y.y so they are send to - say 172.16.10.10, and SNAT so outgoing packages from that 172.16.10.10 go through y.y.y.y
Hope to have given you some approach (there will for sure be others) that allow you to understand this.
-
Thanks for taking the time to articulate this.
I do indeed have multiple IPs and I have setup a SNAT for a server that doesn't use the non-virtual interface IP. It is working fine, but I do have one more question.
When you set up a SNAT, one of the form field entries is "destination". I set that to "Any". Can you think of a circumstance that you would set that to anything other than "Any"?
-
Hello Lonniebiz:
I can think of a case where some internal tool connect to some customer server, which is secured allowing just connections from one IP. Let's say that your net goes through x.x.x.x but that you need that an app running in machine 172.16.2.50 connects to 1.1.1.1 customer machine, which only allows connections from y.y.y.y.
Then, logically you won't make all your net pass through that second IP, you'll reserve it for this customer app connections, and the rest of connections from your lan will go through x.x.x.x
-
I have a use case on my system. I have a tomcat server running internally that I provide vehicle location information to the general public with. I port forward from my external interface to allow access. I have a link on my website that points to that redirected port. To achieve the same functionality on the local network I need to use snat. Think of it this way,
I click on the link from my website (zentyal server)
It port forwards to my internal tomcat server.
The tomcat server responds to me directly
My browser is not waiting for a connection from the internal server since it sent the request to the gateway machine. It therefore ignores it. With snat the response is routed back through the gateway to the requesting machine.
-
half-life: that's exactly what I understand from SNAT purpose. Capability to change source address so that packets return to another route or destination.
This being said, am I correct thinking that is pages were served by your web server accessing Tomcat application or, similar approach, if you were using reverse proxy, such SNAT would not be required ???
-
That would be correct. Reverse proxy is in simplest terms rewriting the header information to change source and destination as it flows into and out of the proxy. If I were running two internal web services open to the public it would behoove me to setup a reverse proxy for management reasons. Being as it is only one service it was just as expedient to do it this way. Long term I expect to return to a proxy setup for work (Cherokee) but for right now what I have works. Have a look if you are curious. www.gltconline.com. The bus locator is the service that is running on tomcat. Don't beat up on me too much, I am a photographer not a graphic artist ;-)
-
Nice web site ;)
I like the "Liberty loop CW". I never though about loop as a straight line ;D (joking)
My point with either reverse proxy or web site was not to challenge your design but to make other users thinking about difference between application running at the border of your intranet/internet infrastructure versus forwarding that is opening your border (kind of hole in the wall) for external connections.
But this is not the point of this thread and your example is, again, 100% what I have in mind when thinking about SNAT.
-
What can I say, the previous AGM didn't take the time to generate shape files for the routes so there are errors like this in several places. I have it on my plate to fix these things probably next month. It isn't really a loop as much as it is a circulator anyways.
-
half_life,
I think I'm going to try that SNAT technique you mentioned. Here's why:
I have serveral websites on multiple IPs that are being served by a non-zentyal-web-server that is sitting behind the Zentyal gateway.
Although these websites are currently accessibility to the world wide web (due to port-forwarding and SNAT), they're not accessible on the local lan.
Since Zentyal is not the authoritative DNS for these sites, one way to solve this problem is to add a DNS entry for each site that points to the local IPs for each site. Because all local machines are using the Zentyal gateway, request to these site would then go directly to the webserver after Zentyal tells the local ip.
However, this approach is a bit of a burden; although there are only 3 public IPs involved, there are over 40 domains to do this for!
Therefore, I'm going to try to use your SNAT suggestion instead, and because of this, I may be able to reduce this work to about 3 entries. What do you think?
Any additional comments as to the exact way you set that up for tomcat would be appreciated.
-
either I don't understand your design or you don't understand SNAT
If you want to access local web server from local machines but lack of DNS entry, I really don't see what SNAT will bring, except extra complicated path between clients and servers :-\
Adding 3 DNS record is a matter of seconds while implementing SNAT has much more side effects, even if it sometimes help a lot solving routing issues.
Well, it depends on how you are accessing Tomcat. As discussed with half_life, if you have front-end web server that is not really front-end but redirecting requests to Tomcat, for sure you may face issue that can be solved using some NAT/SNAT approach (but in such case, DNS will not help).
Another approach is to access Tomcat from front-end Apache (e.g.) web server that is building pages from application server and sends it back to end-user (hint: mod_jk)
-
You have 40 domains and only one port 80. My friend that is what I meant when I was talking about "management reasons". You are a strong candidate for reverse proxy. Nginx. Apache or Cherokee will do what you need.
-
Although these websites are currently accessibility to the world wide web (due to port-forwarding and SNAT), they're not accessible on the local lan.
Can you please provide more technical detail describing why SNAT helps accessing these internal web sites from internet.
I strongly believe that such detailed explanation will help you to decide whether this technology is the right one for you or not.
-
I'm using port forwarding to ensure that a request made to a particular public IP gets routed to the correct internal IP on port 80.
The windows-web-server is behind the Zentyal gateway and answers for 3 private IP addresses (192.168.0.5, 192.168.0.6, 192.168.0.7)
The Zentyal server has one public IP address for itself (on its external interface), 55.55.55.54 and three more public IPs on it via external virtual interfaces: 55.55.55.55, 55.55.55.56, 55.55.55.57.
There are 40+ domains being hosted on the windows web-server. The most important domain has an IP all to itself 55.55.55.55 (as a search engine optimization attempt), while most of the other site share the same public IP 55.55.55.56. Lastly, there is another sub-domain that only does SSL, and it is on the third IP 55.55.55.57.
The reason, I'm using SNAT, is because if a request is made for a particular IP, I want the web-server to reply as though its only IP is the one to which that request was requested. I don't want a user to request a webpage on one IP, and receive a reply from another IP.
For example, if a request is made to 55.55.55.55, port forwarding will send that to 192.168.0.5. When the window's web-server replies, SNAT converts its source IP from 192.168.0.5 back to 55.55.55.55. When the user receives the page, source is 55.55.55.55 as the user would expect.
If a request is made to 55.55.55.56, port forwarding will send that to 192.168.0.6. When the window's web-server replies, SNAT converts its source IP from 192.168.0.6 back to 55.55.55.56. When the user receives the page, source is 55.55.55.56 as the user would expect.
If a request is made to 55.55.55.57, port forwarding will send that to 192.168.0.7. When the window's web-server replies, SNAT converts its source IP from 192.168.0.7 to 55.55.55.57. When the user receives the page, source is 55.55.55.57 as the user would expect.
All this is setup an working for all 40 websites. From the web, you can access them all, just as described above.
My remaining task is to discover the least step-intensive way, to also make all 40 website resolve from any machine that requests them "INSIDE the LAN".
I don't want to have to add 40 DNS entries to do this.
I do not want to create custom host files for each machine in the LAN.
Ideally, I want to create 3 "rules" (which might not be the technical term... maybe it's "routes", not sure) that tell Zentyal, if an internal IP request one of the public IP's on Zentyal's virtual interfaces, forward that request to a particular interal IP.
For example, if 192.168.0.3 tries to go to 55.55.55.55, I want Zentyal to send that to 192.168.0.5, because 55.55.55.55 maps to 192.168.0.5 already for requests coming from the internet, so need to map that same way for internal IPs requesting 55.55.55.55 too.
For example, if 192.168.0.5 tries to go to 55.55.55.55 (which is ultimately itself), I want Zentyal to send that to 192.168.0.5 (back to itself), because 55.55.55.55 maps to 192.168.0.5 already for requests coming from the internet, so need to map that same way for internal IPs requesting 55.55.55.55 too.
I hope I'm making myself clear enough (even if it sounds crazy) for you all to offer suggestions.
-
Thank you for this long and detailed explanation.
However, I give up because I still don't understand.
I'm confused with what you call "domain" and also confused with the
The reason, I'm using SNAT, is because if a request is made for a particular IP, I want the web-server to reply as though its only IP is the one to which that request was requested. I don't want a user to request a webpage on one IP, and receive a reply from another IP.
As you have 3 public IPs plus forwarding to 3 internal web servers, how could request to one IP receive answer from another one ?
Furthermore, except if you are using IP addresses in URLs, how could internal IP be known to external user and generate any confusion ?
Based on your explanation, I believe (well, I hope) web sites are not bound to all 3 virtual IPs isn't it?
Regarding the "domain" concept, I know you're not faulty. This is more a Microsoft and commonly accepted naming convention to use "domain" for a web site. But this is a wrong short-cut and bad habits.
You may have 40+ web sites and I don't know how many domains built using this model (extract for Wikipedia (http://en.wikipedia.org/wiki/Domain_name))
The domain name is a component of a Uniform Resource Locator (URL) used to access web sites, for example:
URL: http://www.example.net/index.html
Top-level domain name: net
Second-level domain name: example.net
Host name: www.example.net
This is not nitpicking ;) and it may make your life quite easy once understood because your 40+ web sites may result in only, almost, CNAME records that are pretty easy to manage (not need, as you write, unless if you have specific needs, to maintain local host files) .
So, as a matter of conclusion, I can't really help as I'm not on the same track ans very confused with your approach. My feeling is that you perhaps face problem because your unique web server is service same content on all IPs (primary and virtual IPs) therefore the risk for receiving wrong content and tentative to control it using SNAT as if web server was sending back it's IP instead of URL made of host+domain.
But I might be totally wrong :-[
-
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?
-
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.
-
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 !!! :o
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
-
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.
-
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 ??? :-X
- 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.
-
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 :-[
-
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.
-
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 – 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.
-
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:
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:
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:
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:
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:
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:
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:
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:
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:
interface: eth1
Orginal Destination: 55.55.55.56/32
Protocol: 443
Source: Any
Destination IP: 192.168.0.6
Replace Source Address: Yes
-
Now make yourself a favour and draw it on an paper ;D
Does it really make sense to have all these flows through Zentyal with all this rewriting stuff :o ???
Well, at least it works :P and if you are happy enough with this solution, please stamp your first post title as [SOLVED]
-
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.
-
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 :
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.
-
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 8) 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. ;)
-
What?! :o
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)
-
Oops, sorry :-[ so this means my English is definitely broken and too poor if you don't understand from the very beginning that I push you to:
- use reverse proxy for external connections
- configure DNS for internal connections.
I'll try to improve... but for the the time being, I don't know how I could be clearer ???
-
I resolved my issue with the source IP address being wrong on traffic from internet users to the windows web server by indicating a source IP range on the port-forwarders of the internal interface (eth1).
In order to do this, I had to create a networking object under the Networking > Objects menu that represented the entire range of IPs that any computer would ever be assigned on my LAN (192.168.0.1-254).
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:
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:
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. Also notice that the source is a network object that represents the internal IP range, so that this rule is not applied to any internet sourced traffic:
interface: eth1
Orginal Destination: 55.55.55.55/32
Protocol: 80
Source: source object 192.168.0.1-254
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:
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:
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. Also notice that the source is a network object that represents the internal IP range, so that this rule is not applied to any internet sourced traffic:
interface: eth1
Orginal Destination: 55.55.55.56/32
Protocol: 80
Source: source object: 192.168.0.1-254
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:
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:
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. Also notice that the source is a network object that represents the internal IP range, so that this rule is not applied to any internet sourced traffic:
interface: eth1
Orginal Destination: 55.55.55.56/32
Protocol: 443
Source: source object 192.168.0.1-254
Destination IP: 192.168.0.6
Replace Source Address: Yes
Before, I was using "ANY" instead of the source object 192.168.0.1-254 for the source on the internal interface port-forwarders. This had the unforeseen ramification of also applying this rule for traffic coming in from the internet and it changed the source to 192.168.0.1 for internet sourced traffic . . . making the windows web server think that all its traffic was coming from 192.168.0.1 (which isn't too helpful for web site traffic analytics). By narrowing the source scope from ANY to just the internal IP range, internet traffic was no longer affected by my internal interface port-forwarders.
I'd like to thank Christian, Half-Life, and jbahillo for teaching me the fundamentals that led to this solution.
-
Me earlier ---
Caution -- be careful not to include your Zentyal servers internal IP address in the snat -ed range.
I believe you just found the reason that I included that little tidbit. You have it fixed now which is good. I believe you can see how difficult this is going to be going forward if you expand further in terms of number of internal servers. One more thing, have you considered server outages and continuity in your design?
All in all you have learned quite a bit about firewall rules with your approach and this is a good thing. What you accomplished is very difficult and is to be commended. Congratulations.
-
Yeah, I had to play with this myself a bit before I could truly understand what you had said. When I reread your replies later, my brain began to comprehend.
You asked if I had given any thought to continuity during server outages. Well, I know that any machine can break, and it is hard to cover every scenario without a large budget. However, here are my current thoughts.
If the Zentyal gateway were to break, my plan is to move some cat5 cables around. You see, the windows web server has 2 network cards. Initially, it was not behind Zentyal, and network-card-1 was assigned public IPs directly and was plugged directly into the ISP gateway. When I added internal IPs to the windows webserver, I added them to Network Card 2. I then unplugged the cable from Network-Card-1 and plugged it into Network-Card-2 and the other side of that cable was moved to a switch behind Zentyal. So, if for some reason the Zentyal server breaks, I will simply plug the windows webserver into the ISP gateway directly again via network-card-1, and that network card is already set to serve the public IPs directly.
If the windows web server breaks, I'm going to have some more downtime, because I'd have to rebuild it from a backup. My plan it to get a better server, and convert that windows web server to a virtual machine and back up that virtual machine routinely. Virtual machines are nice, because if you have a backup of one, you can boot that back up from another physical machine if the primary machine fails.
So, at this point, my continuity plan is a be manual for this network.
I am administering another Zentyal network at a company, were I have a little more of a continuity plan. For example, there I have two Zentyal domain controller were one is replicating the other. DHCP issues IPs that include both DNS servers. I also have two dhcp servers on the same LAN with pools that do not overlap. I've tested the continuity at this company by shutting down the primary Zentyal server. After doing this, users were still able to login to their workstations just fine, and they also continued to get DHCP and DNS just fine. This continuity on this network is no so manual as the first.