Page 1 of 2 12 LastLast
Results 1 to 10 of 20

Thread: Multi-Node Installation behind Firewall and NAT, with Web Proxy Issues

Hybrid View

  1. #1
    Join Date
    Jun 2009
    Posts
    10
    Rep Power
    6

    Default Multi-Node Installation behind Firewall and NAT, with Web Proxy Issues

    Hello there.

    We've been testing Zimbra FOSS Edition for a couple weeks now on a single-node pilot and all went very well. Now we started to implement it on a multi-node pilot to answer some security requisites of the architectural installation of the network we're on, and we're faced with 3 day headcracking problem that doesn't want to get resolved.

    Our installation consists in:

    Intranet:
    Zimbra LDAP/Store
    Internal DNS

    - Firewall -

    DMZ:
    Zimbra MTA/Proxy
    External DNS

    - The Intranet Server has a private IP address translated to an IP address at the DMZ subnet.
    - The DMZ server connects to the Intranet Server through it's translated IP address and is able to communicate through ports: 389, 514, 22 , 8080, 8443, 7025, 7072, 7110, 7995, 7143, 7993.
    - Both the internal and external DNS Servers have an MX and A record pointing to the MTA Server.

    All good until this point, now comes the tricky part. We're using a web proxy to let clients access they're mailboxes.

    The proxy is located in the DMZ (as obvious) available at ports 80 and 443 and is communicating fine with the Intranet Server translated IP at port 8080. BUT when a user tries to login the following happens:

    - Proxy (DMZ) queries the Route Handler (Intranet)
    - Route Handler search the user storage and finds the name of the Intranet Server
    - Route Handler resolves the Intranet Server on the Internal DNS server (/etc/hosts has only the localhost entry for testing purpose, no need for good certificates at this point)
    - Route Handler answers to the Proxy with the internal private IP:8080 of the server instead of its translated one.
    - Proxy fails, obviously, because it can't connect to the internal private IP.

    Here's the nginx log:

    2009/06/16 15:55:42 [error] 20927#0: *24 zmauth: route handler IntranetServerTranslatedIP:7072 sent route IntranetServerInternalIP:8080, client: Gateway, server: name, URL: "/zimbra/", host: "DMZServerIP", referrer: "http://DMZServerIP/"

    2009/06/16 15:56:42 [error] 20927#0: *24 upstream timed out (110: Connection timed out) while connecting to upstream, client: Gateway, server: name, URL: "/zimbra/", upstream: "http://IntranetServerInternalIP:8080/zimbra/", host: "DMZServerIP", referrer: "http://DMZServerIP/"

    Already thought of changing the A record of the Intranet Server in the Internal DNS to resolve to it's translated IP, but then the zimbra services won't start because as they resolve the name of the host they won't be able to communicate with the translated IP, and of course fail initialization.

    I'm not sure but a possible solution, if we manage to implement it, would be to allow traffic at the firewall, between the private internal address and it's translated one, creating some kind of loopback, that way the change described in the previous lines would work, in theory. But that besides doesn't feeling like a very secure alternative might be a little to tricky to try out, as loop's always are.

    On a final note as, Im getting too long here, our version and OS are as stated in "zmcontrol -v":

    Release 5.0.16_GA_2921.RHEL5_64_20090429051405 CentOS5_64 FOSS edition

    So the question is, in this scenario what should be my next approach? Is there a way to change how the route handler works, or how it resolves the server's name found?
    Last edited by Mcnf; 06-16-2009 at 06:47 AM.

  2. #2
    Join Date
    Jun 2009
    Posts
    10
    Rep Power
    6

    Default

    Any ideas?

    We really could use some insight on, how and if it's possible to work with the Zimbra side in this question, before we consider to make changes on the architectural side of the system.

    Thanks in advance.

  3. #3
    Join Date
    Jun 2009
    Posts
    10
    Rep Power
    6

    Default

    Should I assume that no one really knows anything about this matter?

  4. #4
    Join Date
    May 2007
    Location
    Oklahoma
    Posts
    703
    Rep Power
    9

    Default If your problem is one of resolution...

    Can you just not add the entry to the hosts file so it resolves to the public IP?

    I may not be understanding the issue in its entirety but it seems like that would work.

  5. #5
    Join Date
    Jun 2009
    Posts
    10
    Rep Power
    6

    Default

    Already tried that solution and it doesn't work, simply for the fact that zimbra services need to resolve the server hostname to work, meaning that if the server hostname resolves to its public ip, it's services won't even be able to start, as i said before.

    What I could really do is change the behaviour of the route handler component, but that's too deep in the zimbra engineering process for me to do it without some kind of advice from the developing team or someone with that kind of knowledge.

    Thank you for the answer tho.
    Last edited by Mcnf; 06-22-2009 at 06:31 AM.

  6. #6
    Join Date
    May 2007
    Location
    Oklahoma
    Posts
    703
    Rep Power
    9

    Default My squid proxy server...

    has a WAN and LAN NIC. I force it to access my mail server across the LAN by using the hosts file in the proxy server. Maybe you could setup a second NIC not in the DMZ.

    Just thinking out loud.

  7. #7
    Join Date
    Jun 2009
    Posts
    10
    Rep Power
    6

    Default

    Yes that would work of course, but also will make the all concept of DMZ useless, because if that machine is compromised then all the intranet is reachable, and thats really not ok.

    I might really have to change both servers to the DMZ, even if that makes me a little nervous, because of the exposed storage mailboxes.

  8. #8
    Join Date
    May 2007
    Location
    Oklahoma
    Posts
    703
    Rep Power
    9

    Default I'm not suggesting...

    that you put your proxy on the WAN. I'm just suggesting you put the hosts file entry in your proxy so it is forced to hit the mail server using the LAN IP address instead of the DNS resolved public IP address.

    Also, correct me if I'm wrong, but any machine sitting in the DMZ is accessible by the Internet. It's basically a one to one NAT map of your public IP to a private IP. So why would you be willing to compromise a mail server in the DMZ but not put a WAN card in a proxy server? A firewall running an appliance is no more secure than a firewall running on a PC. Again, I'm not suggesting you use a WAN interface on a PC if you are not comfortable doing so. But it is no less secure than a computer sitting in the DMZ.

  9. #9
    Join Date
    Jun 2009
    Posts
    10
    Rep Power
    6

    Default

    First of all, I'm sorry i haven't replied earlier but some other things came up, and we we were not able to advance this pilot for a couple weeks.

    Well now that I'm back on it again, I'll start by answering each reply. Thank you all for your collaboration in advance.

    Quote Originally Posted by Bill Brock View Post
    that you put your proxy on the WAN. I'm just suggesting you put the hosts file entry in your proxy so it is forced to hit the mail server using the LAN IP address instead of the DNS resolved public IP address.

    Also, correct me if I'm wrong, but any machine sitting in the DMZ is accessible by the Internet. It's basically a one to one NAT map of your public IP to a private IP. So why would you be willing to compromise a mail server in the DMZ but not put a WAN card in a proxy server? A firewall running an appliance is no more secure than a firewall running on a PC. Again, I'm not suggesting you use a WAN interface on a PC if you are not comfortable doing so. But it is no less secure than a computer sitting in the DMZ.
    Bill, I don't think you understood our setup, our proxy IS in the DMZ and can reach the NAT'ed private address of our mailbox servers just fine.

    The problem is when the Route Handler (sitting on our LAN, and therefore resolving names in the internal DNS server, to the private addresses of the LAN servers) returns when queried, the NOT NAT'ed private address of the mailbox server, to the proxy. Then obviously the proxy can't reach the private LAN.

    Quote Originally Posted by LMStone
    Not sure I understand your network config...

    Are you saying the proxy/MTA server and the DNS server have public IP addresses and the Zimbra LDAP/mailstore and Internal DNS servers have private IP addresses?

    Are you also saying DMZ DNS server supplies just public IPs, whereas the Internal DNS server supplies private IPs?

    Please also supply the /etc/hosts and /etc/resolv.conf files for the Zimbra servers. You can change the IPs/hostnames if you like.

    Thanks,
    Mark
    Mark, I'm gonna try to explain our setup a little better:

    Intranet - Private subnet
    Firewall - Separation between subnets, communication is done with NAT'ed IP's of Intranet subnet to the DMZ subnet
    DMZ - Private subnet
    Internet - Public (we aren't doing NAT to the outside at this moment, as this is just a pilot and it isn't fully functional yet)

    Intranet:

    Zimbra LDAP/Store:
    Private IP in the Intranet subnet;
    Resolves names at the Internal DNS;
    Has a NAT'ed IP on the DMZ subnet.

    Internal DNS:
    Private IP in the Intranet subnet;
    Resolves all the servers in the Intranet to their private Internal LAN IP's;
    Resolves the MTA/Proxy server in the DMZ to it's IP on the DMZ subnet.

    - Firewall -

    DMZ:

    Zimbra MTA/Proxy:
    Private IP in the DMZ subnet;
    Resolves names at the external DNS;
    Can reach the NAT'ed IP on the DMZ subnet of the Internal LDAP/Store server just fine.

    External DNS:
    Private IP in the DMZ subnet;
    Resolves the MTA/Proxy server in the DMZ to it's IP on the DMZ subnet;
    Resolves the LDAP/Store server in the Intranet to it's NAT'ed IP on the DMZ subnet.

    All the servers have only the localhost entry in /etc/hosts.
    All the servers have the corresponding DNS server in /etc/resolv.conf depending on their location, as I mentioned above.

    I dont think pasting the results of cat'ing those files here would be necessary as this already is going to be a huge post, and the 2 lines above are perfectly clear (I think).

    Quote Originally Posted by Rich Graves
    The simplest fix would be a DNAT on your proxy server. It's silly, because you'll be NAT'ing twice (where each NAT simply reverses the other's work), but you wouldn't have to change anything about either Zimbra or your firewall setup.

    -t nat -A PREROUTING -d (private ip) -j DNAT --to-destination (public ip)

    As far as any Zimbra server knows, the DMZ server is communicating directly with the private IP address.

    That will satisfy any policy requiring separation of application and database servers.

    But consider that your Zimbra MTA/proxy host in the DMZ will likely have Zimbra superuser credentials available in cleartext via zmlocalconfig. The :7071 admin port may be firewalled off, but if you have LDAP write access, you can change the server configuration, or any user's password. Depending on your needs, putting Zimbra on a single host on the internal network and using a non-Zimbra antispam appliance and a non-Zimbra passthrough might make more sense. nginx is a load-balancing tool, not a security tool.
    06-27-2009 12:51 AM
    Rich, yes that would work because the main problem it's in the fact that there is a NAT between the two subnets, reversing the original NAT with another one would definitly be a workaround.

    About the fact that the superuser password would be available in clear text in zmlocalconfig, I don't know if I'm doing things right but grepping zmlocalconfig returns all passwords not visible:

    Code:
    zmlocalconfig | grep password
    
    ldap_amavis_password = *
    ldap_nginx_password = *
    ldap_postfix_password = *
    ldap_replication_password = *
    ldap_root_password = *
    mailboxd_keystore_base_password = *
    mailboxd_keystore_password = *
    mailboxd_truststore_password = *
    mysql_root_password = *
    zimbra_ldap_password = *
    zimbra_logger_mysql_password = *
    zimbra_mysql_password = *
    What do you guys think?

    I have a couple of ideas that Im gonna try out and then let you know the result.

    Thank you for your collaboration.

    Regards,
    Miguel

  10. #10
    Join Date
    May 2007
    Location
    Oklahoma
    Posts
    703
    Rep Power
    9

    Default You are right, I don't understand.

    But I do know that the proxy server will resolve from it hosts file before it resolves from the DNS server. If the private (LAN) IP of the mail server is entered in the hosts file of the proxy server, it will hit the mail server with that IP and not the WAN IP. Your Internal DNS server will not even be involved at this point.

    But since you say this won't work, and I am assuming you have tried it, then I completely don't understand the issue and hopefully others in the forum can help you.

Similar Threads

  1. Replies: 2
    Last Post: 09-06-2006, 01:15 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •