- 1 Overview And Planning
- 2 Installing And Configuring Zimbra Proxy
- 2.1 New ZCS Deployment
- 2.2 Adding Proxy Services To Existing Non-Proxy Environments via ZCS Installer [Recommended Method]
- 2.3 Adding Proxy Services To Existing Non-Proxy Environments via CLI [Advanced Method]
- 2.4 Manually Modifying Proxy Services And Related Variables via CLI
- 3 Troubleshooting
- 4 Advance Topics
- 4.1 Ldap Attributes For Proxy
- 4.2 Proxy Configuration And Template Files
- 4.3 Proxy Related CLI Commands
- 4.4 Advanced Proxy Configuration Examples via CLI
- 4.4.1 Configure Zimbra Proxy For POP[S] And IMAP[S] Only
- 4.4.2 Configure Zimbra Proxy For POP[S] Only
- 4.4.3 Configure Zimbra Proxy For POP[S] And HTTP[S] Only
- 4.4.4 Configure Zimbra Proxy For IMAP[S] Only
- 4.4.5 Configure Zimbra Proxy For IMAP[S] And HTTP[S] Only
- 4.4.6 Configure Zimbra Proxy For HTTP[S] Only
- 4.4.7 Configure Or Customize The Zimbra Proxy For The Admin Console
- 4.4.8 Configure Zimbra Proxy For Kerberos Authentication
Overview And Planning
Overview Of Proxy And Related Components
Zimbra Proxy is a high-performance reverse proxy service for passing IMAP/POP3/HTTP[S] client requests to other internal ZCS services. A reverse proxy server is an Internet-facing services that protects and manages client connections to your internal services. It can also provide functions like: GSSAPI authentication, throttle control, SSL connection with different certificates for different virtual host names, and other features described later below.
The Zimbra Proxy services allows other zimbra services [mailbox, webapp, etc.] that can be hidden from the Internet by acting as a reverse proxy for the other services and allows end-users to access the mail system via a single Login URL [for example, userA and userB can both use mail.domain.com] instead of knowing their specific mailbox hostnames [for example, userA uses mail12.domain.com and userB is uses mail13.domain.com]. It acts as the first entry point for all the HTTP/IMAP/POP traffic and then intelligently routes all static UI (HTML/CSS/JS etc) and dynamic (SOAP/REST/IMAP/POP) requests to the appropriate upstream server. The proxy configuration options for POP/IMAP allows end users to configure their POP/IMAP clients to use this single mail server hostname. The proxy configuration options around HTTP[S] allows end-users to use this single hostname for ZWC, REST, CalDAV, Zimbra Connector for Outlook, Zimbra Connector for BES, Zimbra Mobile Sync connections and so forth. The Zimbra Proxy service will also do URL rewriting so these internal hostnames that are providing the various services aren't exposed to the public or end-clients. For example, a Zimbra briefcase share from userA on mail12.domain.com to userB on mail13.domain.com will simply have mail.domain.com [per our example above] within the url. [ see bug 82236 ]
With ZCS 8.5, the proxy components are installed by default and therefor would be enabled on a single ZCS server deployment. Normally though, the proxy services would be installed on Internet-facing servers and the other specific ZCS services [zimbra-store for example] would be on installed on internal servers. Generally, these packages are installed on dedicated Internet-facing servers intended to just do the proxy services or those that also run the zimbra-mta package. When the Zimbra Proxy package is installed, the proxy feature is enabled with default values that normally require no modification.
The Zimbra Proxy installation components consists of the zimbra-proxy and zimbra-memcached options during the installation package choice menu. The zimbra-proxy packages is Zimbra’s modified version of Nginx , pronounced like “engine-ex”. And the zimbra-memcached packages is our modified version of memcached , pronounced like “memcache-dee”. A third component needed for our proxy environment to work is the Zimbra Proxy Route Lookup Handler or called the “Nginx Lookup Extension” (NLE for short). This is a java servlet that is installed from the zimbra-store package on the Zimbra mailbox servers. This servlet handles nginx queries for the user account route information (the server and port number where the user account resides).
In a typical use case, the proxy services extracts the user login details and then fetches the route to the upstream mail server or web servers’ address from NLE servlet, and finally proxies the interactions between clients and upstream ZCS servers. To accelerate the speed of future route lookups for a user, memcached caches the lookup results. Therefore, the subsequent login with the same username will directly be proxied without calling to the NLE servlet.