Difference between revisions of "SUSE Linux Enterpise Server 9 NAT HOWTO"
|Line 1:||Line 1:|
== Introduction ==
== Introduction ==
Revision as of 21:18, 3 November 2006
Our preferred configuration for our servers exposed to the public Internet is to NAT them behind a firewall. Zimbra's default configuration does not expect a NAT'd server, so a few configuration changes are required for the Zimbra server to function correctly. While the forums describe what needs to be accomplished, I have found no detailed "HOWTO" for SUSE Linux Enterprise Server 9 ("SLES9" or "ES9"), and so I decided to write one.
As this is a first draft, I would be grateful for any improvements and/or corrections.
L. Mark Stone
3 November 2006
This HOWTO assumes you already know what an A record, a PTR record and an MX record are, and that you know how to configure them for your Zimbra server to be RFC compliant on the public DNS servers that are authoritative for your domain. In other words, configuring things so the world can find your Zimbra server is beyond the scope of this HOWTO. :-)
For a NAT'd Zimbra box to work correctly, Zimbra must be tricked into using DNS that reference private IP addresses for itself, even though public DNS records will point to public IP addresses.
To do this, we need to make changes in four places:
1. The /etc/hosts file 2. The local installation of BIND on the ES9 Zimbra server 3. The order of DNS lookups 4. The /opt/zimbra/postfix/conf/main.cf file
Here we will use the actual public and private IP addresses of our Zimbra server "viognier.reliablenetworks.com".
lmstone@shiraz:~$ host viognier.reliablenetworks.com viognier.reliablenetworks.com has address 18.104.22.168 lmstone@shiraz:~$ ping 172.16.1.23 PING 172.16.1.23 (172.16.1.23) 56(84) bytes of data. 64 bytes from 172.16.1.23: icmp_seq=1 ttl=64 time=49.9 ms 64 bytes from 172.16.1.23: icmp_seq=2 ttl=64 time=83.3 ms --- 172.16.1.23 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 49.918/66.613/83.308/16.695 ms lmstone@shiraz:~$
In our case, we installed Zimbra before making the following changes, so we had to tweak the installer to use "reliablenetworks.com" as the domain instead of "viognier.reliablenetworks.com", and we had to accept and click through the installer's error notification that it couldn't find our MX record. It would be nice if someone could test an ES9 install after making the changes below, and confirm here that the install proceeds without any errors.
Regardless, you'll still need to edit the main.cf file after the Zimbra installation is complete.
Using vi or another editor, open up /etc/hosts and add a line at the end in the format:
[private IP address] [fqdn] [hostname]
Here is our /etc/hosts file after competing the edits:
Install and Configure BIND
ES9 does not install BIND as part of the default install. But, the YaST DNS Server configuration tool is installed by default, and the tool will install BIND for you when you first launch the tool, if BIND is not already installed. Be sure to run Online Update after you first install BIND to get the latest patches.
First, launch the DNS Server tool:
Next, go to the "Start-Up" tab in the YaST tool, and configure BIND to start up at boot time:
Now we need to set up the forwarders. Select the "Forwarders" tab and add in the IP addresses of the DNS servers your colocation provider or ISP provides for you:
Now it's time to go to the "DNS Zones" tab and add your domain as a Master. You can accept all of the other defaults. While you are there, add a A record pointing to the private IP address of your server, and an MX record, too:
For some reason, Zimbra throws an error in /var/log/zimbra.log on startup if Zimbra can't talk to BIND, so if we allow localhost to perform a zone transport, the error goes away. Choose the "DNS Zones" tab under "Basics":
Still on the "DNS Zones" tab, go to "NS Records" and add the public DNS servers which are authoritative for your domain. If you are not sure what these are, go to http://www.dnsreport.com and get a report for your domain. Doing this will save you from copying over your entire public zone file when your Zimbra host tries to find other public servers with the same domain name.
Hit "OK" as necessary to save your changes and start BIND running.
Configure The Order of DNS Lookups
If you closed YaST, open it up again and go to "Network Devices" => Network Card:
Although you could use static DHCP, we have found it safer to fix the (private) IP address of the server manually:
Choose "Host name and name server" from the list in the above screenshot, and in the new window, fill in "127.0.0.1" as the first nameserver, and the nameservers from the forwarders list you filled in above as your secondary and tertiary nameservers.
Save and close this YaST module to put all of your changes into effect.
Reality Check: Test Before Going Any Farther
At this point, a good reality check would be to open up a command prompt and run the "host" command twice. On our system, running "host viognier.reliablenetworks.com" returns the private (not the public) IP address of the server. Running "host www.yahoo.com" returns a few public IP addresses. This shows that our networking settings and BIND are configured correctly.
Edit Zimbra Postfix main.cf File
Postfix does a lot of DNS lookups as part of its anti-spam capabilities. To be effective, and to prevent backscatter (especially when your Zimbra box is a backup MX for someone else), it is necessary to tell Postfix explicitly that it really has a public IP address. To do that, we need to edit /opt/zimbra/postfix/conf/main.cf.
The only safe way to do this is to su to the zimbra user, and then run the "postconf" command. Here's what we ran to configure our box:
After you do that, as the zimbra user run "postfix reload" so Postfix becomes aware of the change.
The Last Word...
Obviously, please be sure to use your own private and public IP addresses, not ours!
You may want to tail /var/log/zimbra.log for a while, to make sure everything is working correctly before putting your new Zimbra server into full-fledged production use.