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

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

  1. #1
    Mcnf is offline Member
    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
    Mcnf is offline Member
    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
    Mcnf is offline Member
    Join Date
    Jun 2009
    Posts
    10
    Rep Power
    6

    Default

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

  4. #4
    Bill Brock is offline Outstanding Member
    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
    Mcnf is offline Member
    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
    Bill Brock is offline Outstanding Member
    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
    Mcnf is offline Member
    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
    Bill Brock is offline Outstanding Member
    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
    LMStone's Avatar
    LMStone is online now Moderator
    Join Date
    Sep 2006
    Location
    477 Congress Street | Portland, ME 04101
    Posts
    1,374
    Rep Power
    10

    Default

    Quote Originally Posted by Mcnf View Post
    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?
    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

  10. #10
    Rich Graves is offline Outstanding Member
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    719
    Rep Power
    9

    Default

    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.

Page 1 of 2 12 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

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
  •