SonicWall email Security Deployment Pre-Requisites

12/20/2019 1,009 People found this article helpful 483,867 Views

Description

Before you begin to Deploy your SonicWall Email Security solution, there are several pre-requisite that need to be met relating to DNS and Firewall configuration. We will first look at the DNS requirements and options as they directly relate to SonicWall Email Security.

Resolution

When you want to run your own Mail Server or Email Security Server, it does not matter what version and make of mail server or Email Security Server you're using - as long as the ultimate mail server is using SMTP as the e-mail transfer mechanism or running as a MTA - you'll need to configure the MX Records for your domain that reference either your Mail Server or Email Security Server, depending on your configuration needs.

MX is an acronym that stands for Mail eXchange. The concept of MX is defined in RFC 1035. It specifies the name and relative preference of mail servers for a DNS Zone. MX is a DNS resource record used to define the host(s) willing to accept mail for a given domain. I.e. an MX record indicates which computer is responsible for handling the mail for a particular domain.

Without proper MX Records for your domain, only internal e-mail will be delivered to your users. External e-mail from other mail servers in the world will not be able to reach your server simply because these foreign servers cannot tell to which server they need to "talk" (or open a connection to) in order to send the mail destined for that domain.

You can have multiple MX records for a single domain name, ranked in preference order. If a host has three MX records, a mailer will try to deliver to all three before the server will queue the e-mail.

MX Records must be in the following format:

sonicwall.com. IN MX 10 mail.sonicwall.com.

The Preference field is comparative to any other MX Record for the zone and can be on any value between 0 and 65535. Low values are more preferred. The preferred value is usually 10 but this is just a convention, not a rule. Any number of MX Records may be defined in DNS for your Zone or Namespace. If the host or Email Security server is going to participate in DNS queries for the domain it requires an A Record.

MX Records do not need to point to a host in the same zone, i.e. an MX Record can point to an A Record that is listed in any zone on that DNS or any other DNS server. The key here is that the MX Resource Record should point to an A Record that references the IP Address of the SonicWall ES Server.

External and Internet-connected networks

When connecting your mail server to the Internet (or to another ex-organizational mailing system that uses SMTP) you must always make sure that the rest of the world can successfully resolve your domain's MX Record. Failing to do so will cause e-mail traffic not to be delivered to you.

In order to properly configure your domain's MX Record you should contact your ISP (Internet Service Provider) or whoever is responsible for hosting your DNS Domain name. They will ask you for your FQDN (Fully Qualified Domain Name) and IP address of your mail server. Make sure you know them.

When your mail server is connected directly to the Internet

In cases where no NAT (Network Address Translation) is being used and where your mail server is directly connected to the Internet via a Public IP Address assigned to it, you will need to provide them with the FQDN and IP address of your mail server.

Note: This is, by far, the least secure method for connecting a mail server to the Internet, unless it is done in a DMZ on your Firewall.

Let's say you have the following LAN configuration:

In the above example you need to give the mail server's IP address as your MX Record.

You should make sure the ISP has had all the necessary routing tables updated in order to provide Internet availability to your internal IP network range. Although this is not something that you as the Network/Security Administrator can control, it is something to be aware of.

Note: It doesn't matter if the real host name of the mail server is NOT "mail". Internet hosts don't mind that, they just need to know what the name of the mail server is, and what the IP address is for that hostname.

When NAT is being used

In cases where NAT (Network Address Translation) or PAT (Port Address Translation) is being used you will need to provide them with the IP address of your external NAT interface or external interface of your Firewall, and configure your NAT device with Static Mapping for TCP Port 25, and have all TCP Port 25 traffic forwarded to the internal IP address of your mail server.

Let's say you have the following LAN configuration:

In the above example you need to give the NAT's Public IP address of 192.91.1.1 as your MX Record.

Note: Make sure you properly configure the NAT device to forward all TCP Port 25 traffic to 192.168.0.10.

When a Mail Relay is being used

In cases where you have a DMZ (Demilitarized Zone) with a Mail Relay host (i.e. Linux, Windows 2000/2003 + IIS and SMTP, a dedicated appliance and so on) you will need to provide the FQDN and IP address of your Mail Relay machine, and configure the Firewall to only allow TCP Port 25 traffic to be sent to the Mail Relay's IP address, not to your real mail server.

You should then configure the Mail Relay to forward the incoming e-mail traffic to the real mail server (after scanning it for spam, viruses and so on).

Let's say you have the following LAN configuration:

In the above example you need to give the Mail Relay's IP address or Registered A Record as your MX Record.

Note: Make sure you properly configure the Firewall device to forward all TCP Port 25 traffic to 192.91.1.17, and to allow 192.91.1.17 to send TCP Port 25 traffic to your internal mail server or SonicWall Email Security Server at 192.168.0.10. Also, make sure you let the internal mail server communicate only with the Mail Relay device and that you set up an SMTP Connector on the mail server or Correct Outbound Path in the SonicWall WebUI and configure it to relay or Smart-host all external mail to the Mail Relay.

Note: Some networks might use the Internet Router as their NAT device, and let the Firewall do just that. In those cases, the scenario is a mixture between option #2 (NAT) and this one.

Internal networks

As stated above, there is usually no need to configure MX Records for internal use, simply because internal (i.e. inter-organization) e-mail and replication traffic is usually controlled via Active Directory-store information. However there are some cases where you will want to configure internal MX Records.

While these MX Records will generally not cause any harm even if you configure them without actually needing them, you must pay close attention to various configuration issues, especially when Mail-Relays and Smart-Hosts are involved. Therefore I cannot say for sure if configuring non-necessary MX Records will cause any problems to your local network. If you do not know for sure (and this might be the case since you've bothered to read this article in the first place) I suggest you consult a network specialist before doing any changes. The following are some reasons that you may wish to create internal MX Records.

Fault Tolerance
In case your mail server fails you'd like to still be able to receive incoming e-mail messages. Most small to medium sized companies will pay their ISPs some monthly fee and that will buy them storage space on the ISPs mail servers. For that to happen, a new MX Record will be added to their DNS information, pointing to the ISPs mail server with a higher priority. For example:

mail.sonicwall.com
A
192.91.1.17

mail.isp.com
A
212.143.25.1

sonicwall.com
MX
mail.sonicwall.com
10

sonicwall.com
MX
mail.isp.com
100

Load Balancing

Medium to large sized companies will want to configure some load balancing features for their incoming mail servers. For that to happen, the company must set up a number of mail servers, each one with a different IP address (actually, one can use Network Load Balancing - NLB, or even clustering but that's a topic for a different article). Then new MX Records will be added to their DNS information, pointing to the mail servers, all with the same priority. For example:

maila.sonicwall.com
A
192.91.1.11

mailb.sonicwall.com
A
192.91.1.12

mailc.sonicwall.com
A
192.91.1.12

mail.isp.com
A
212.143.25.1

sonicwall.com
MX
maila.sonicwall.com
10

sonicwall.com
MX
mailb.sonicwall.com
10

sonicwall.com
MX
mailc.sonicwall.com
10

sonicwall.com
MX
mail.isp.com
100

Testing the MX Record configuration is critical especially when configuring it for the first time with a new ISP you don't know that well and so on. Use NSLOOKUP or DIG or any other DNS querying tool such as www.mxtoolbox.com or www.dnscolos.com to make sure your records are set straight.

The next item of importance to consider when deploying a SonicWall Email Security solution is that of Round Robin DNS and Load Balancing.

Balancing Mail

Using the MX record that you created above, you can balance mail in two ways. You can also configure DNS to provide a kind of mail service fail-over.

Define multiple MX records with the same priority e.g.;

Not Finding Your Answers?

ASK THE COMMUNITY

Was This Article Helpful?

YES NO

SonicWall email Security Deployment Pre-Requisites

Description

Resolution

Categories

Not Finding Your Answers?

Was This Article Helpful?

Article Helpful Form

Article Not Helpful Form

Follow Us

Subscribe to newsletter

Stay In Touch