Gateway mode deployment
After completing the Quick Start Wizard, you may need to configure some items that are specific to your network topology or the operation mode of your FortiMail unit.
This section contains examples of how to deploy a FortiMail unit operating in gateway mode. Other sections discuss deployment in the other two modes.
This section includes the following topics:
- Configuring DNS records
- Example 1: FortiMail unit behind a firewall
- Example 2: FortiMail unit in front of a firewall
- Example 3: FortiMail unit in DMZ
Configuring DNS records
You must configure public DNS records for the protected domains and for the FortiMail unit itself.
|
If you are unfamiliar with configuring DNS and related MX and A records, first read DNS role in email delivery. |
For performance reasons, and to support some configuration options, you may also want to provide a private DNS server for exclusive use by the FortiMail unit.
This section includes the following:
- Configuring DNS records for the protected domains
- Configuring DNS records for the FortiMail unit itself
- Configuring a private DNS server
Configuring DNS records for the protected domains
Regardless of your private network topology, in order for external MTAs to deliver email through the FortiMail unit, you must configure the public MX record for each protected domain to indicate that the FortiMail unit is its email gateway.
For example, if the fully qualified domain name (FQDN) of the FortiMail unit is fortimail.example.com, and example.com is a protected domain, the MX record for example.com would be:
example.com IN MX 10 fortimail.example.com
|
|
If your FortiMail unit will operate in gateway mode, configure the MX record to refer to the FortiMail unit, and remove other MX records. If you fail to do so, external MTAs may not be able to deliver email to or through the FortiMail unit, or may be able to bypass the FortiMail unit by using the other MX records. If you have configured secondary MX records for failover reasons, consider configuring FortiMail high availability (HA) instead. For details, see FortiMail high availability modes. |
An A record must also exist to resolve the host name of the FortiMail unit into an IP address.
For example, if the MX record indicates that fortimail.example.com is the email gateway for a domain, you must also configure an A record in the example.com zone file to resolve fortimail.example.com into a public IP address:
fortimail IN A 10.10.10.1
where 10.10.10.1 is either the public IP address of the FortiMail unit, or a virtual IP address on a firewall or router that maps to the private IP address of the FortiMail unit.
If your FortiMail unit will relay outgoing email, you should also configure the public reverse DNS record. The public IP address of the FortiMail unit, or the virtual IP address on a firewall or router that maps to the private IP address of the FortiMail unit, should be globally resolvable into the FortiMail unit’s FQDN. If it is not, reverse DNS lookups by external SMTP servers will fail.
For example, if the public network IP address of the FortiMail unit is 10.10.10.1, a public DNS server’s reverse DNS zone file for the 10.10.10.0/24 subnet might contain:
1 IN PTR fortimail.example.com.
where fortimail.example.com is the FQDN of the FortiMail unit.
Configuring DNS records for the FortiMail unit itself
In addition to that of protected domains, the FortiMail unit must be able to receive web connections, and send and receive email, for its own domain name. Dependent features include:
- delivery status notification (DSN) email
- spam reports
- email users’ access to their per-recipient quarantined mail
- FortiMail administrators’ access to the web UI by domain name
- alert email
- report generation notification email
For this reason, you should also configure public DNS records for the FortiMail unit itself.
Appropriate records vary by whether or not Web release host name/IP (located in Security > Quarantine > Quarantine Report in the advanced mode of the web UI) is configured:
Case 1: Web Release Host Name/IP is empty/default
When Web release host name/IP is not configured (the default), the web release/delete links that appear in spam reports use the fully qualified domain name (FQDN) of the FortiMail unit.
For example, if the FortiMail unit’s host name is fortimail, and its local domain name is example.net, resulting in the FQDN fortimail.example.net, a spam report’s default web release link might look like (FQDN highlighted in bold):
https://fortimail.example.net/releasecontrol?release=0%3Auser2%40example.com%3AMTIyMDUzOTQzOC43NDJfNjc0MzE1LkZvcnRpTWFpbC00MDAsI0YjUyM2NTkjRSxVMzoyLA%3D%3D%3Abf3db63dab53a291ab53a291ab53a291
In the DNS configuration to support this and the other DNS-dependent features, you would configure the following three records:
example.net IN MX 10 fortimail.example.net
fortimail IN A 10.10.10.1
1 IN PTR fortimail.example.net.
where:
example.netis the local domain name to which the FortiMail unit belongs; in the MX record, it is the local domain for which the FortiMail is the mail gatewayfortimail.example.netis the FQDN of the FortiMail unitfortimailis the host name of the FortiMail unit; in the A record of the zone file for example.net, it resolves to the IP address of the FortiMail unit for the purpose of administrators’ access to the web UI, email users’ access to their per-recipient quarantines, to resolve the FQDN referenced in the MX record when email users send Bayesian and quarantine control email to the FortiMail unit, and to resolve to the IP address of the FortiMail unit for the purpose of the web release/delete hyperlinks in the spam report10.10.10.1is the public IP address of the FortiMail unit
Case 2: Web Release Host Name/IP is configured
You could configure Web release host name/IP to use an alternative fully qualified domain name (FQDN) such as webrelease.example.info instead of the configured FQDN, resulting in the following web release link (web release FQDN highlighted in bold):
https://webrelease.example.info/releasecontrol?release=0%3Auser2%40example.com%3AMTIyMDUzOTQzOC43NDJfNjc0MzE1LkZvcnRpTWFpbC00MDAsI0YjUyM2NTkjRSxVMzoyLA%3D%3D%3Abf3db63dab53a291ab53a291ab53a291
Then, in the DNS configuration to support this and the other DNS-dependent features, you would configure the following MX record, A records, and PTR record (unlike Case 1: Web Release Host Name/IP is empty/default, in this case, two A records are required; the difference is highlighted in bold):
example.net IN MX 10 fortimail.example.net
fortimail IN A 10.10.10.1
webrelease IN A 10.10.10.1
1 IN PTR fortimail.example.net.
where:
example.netis the local domain name to which the FortiMail unit belongs; in the MX record, it is the local domain for which the FortiMail is the mail gatewayfortimail.example.netis the FQDN of the FortiMail unitfortimailis the host name of the FortiMail unit; in the A record of the zone file for example.net, it resolves to the IP address of the FortiMail unit for the purpose of administrators’ access to the web UI and to resolve the FQDN referenced in the MX record when email users send Bayesian and quarantine control email to the FortiMail unitwebreleaseis the web release host name; in the A record of the zone file for example.info, it resolves to the IP address of the FortiMail unit for the purpose of the web release/delete hyperlinks in the spam report10.10.10.1is the public IP address of the FortiMail unit
Configuring a private DNS server
In addition to the public DNS server, consider providing a private DNS server on your local network to improve performance with features that use DNS queries.
Public and private DNS servers (gateway mode)
In some situations, a private DNS server may be required. A private DNS server is required if you enable the Use MX record option. Because gateway mode requires that public DNS servers have an MX record that routes mail to the FortiMail unit, but Use MX record requires an MX record that references the protected SMTP server, if you enable that option, you must configure the records of the private DNS server and public DNS server differently.
For example, if both a FortiMail unit (fortimail.example.com) operating in gateway mode and the SMTP server reside on your private network behind a router or firewall as illustrated in Public and private DNS servers (gateway mode), and the Use MX Record option is enabled, the following table shows differences between the public and private DNS servers for the authoritative DNS records of example.com.
Public versus private DNS records when “Use MX record” is enabled
|
Private DNS server |
Public DNS server |
|---|---|
example.com IN MX 10
mail.example.com
|
example.com IN MX 10
fortimail.example.com
|
mail IN A 172.16.1.10
|
fortimail IN A 10.10.10.1
|
1 IN PTR fortimail.example.com
|
If you choose to add a private DNS server, to configure the FortiMail unit to use it, go to System > Network > DNS in the advanced mode of the web UI.
Example 1: FortiMail unit behind a firewall
In this example, a FortiMail unit operating in gateway mode, a protected email server, a private DNS server, and email users’ computers are all positioned within a private network, behind a firewall. Remote email users’ computers and external email servers are located on the Internet, outside of the network protected by the firewall. The FortiMail unit protects accounts for email addresses ending in “@example.com”, which are hosted on the local email server.
FortiMail unit behind a NAT device
The private DNS server is configured to locally replicate records from public DNS servers for most domains, with the exception of records for protected domains, which instead have been configured differently locally in order to support the Use MX record option.
To deploy the FortiMail unit behind a NAT device such as a firewall or router, you must complete the following:
|
|
This example assumes you have already completed the Quick Start Wizard and configured records on the DNS server for each protected domain. For details, see Running the Quick Start Wizard and Configuring DNS records. |
Configuring the firewall
In order to create the outgoing firewall policy that governs the IP address of the FortiMail unit, you must first define the IP address of the FortiMail unit by creating a firewall address entry.
In order to create the firewall policy that forwards email-related traffic to the FortiMail unit, you must define a static NAT mapping from a public IP address on the FortiGate unit to the private IP address of the FortiMail unit by creating a virtual IP (VIP) entry. Similarly, in order to create the firewall policy that forwards POP3/IMAP-related traffic to the protected email server, you must first define a static NAT mapping from a public IP address on the FortiGate unit to the private IP address of the protected email server by creating a virtual IP entry.
Once the firewall address and VIPs are configured, you must create firewall policies that:
- allow incoming FortiMail services that are received at the virtual IP address, then applies a static NAT when forwarding the traffic to the private network IP address of the FortiMail unit.
- allow outgoing email and other FortiMail connections from the FortiMail unit to the Internet.
- allow incoming POP3 and IMAP traffic that is received at the virtual IP address, then applies a static NAT when forwarding the traffic to the private network IP address of the protected email server.
For more information about how to configure the firewall address, virtual IPs, and firewall policies, see the FortiGate documentation.
Configuring the MUAs
Configure the email clients of local and remote email users to use the FortiMail unit as their outgoing mail (SMTP) server/MTA. For local email users, this is the private network IP address of the FortiMail unit, 172.16.1.5; for remote email users, this is the virtual IP on the FortiGate unit that maps to the FortiMail unit, 10.10.10.1 or fortimail.example.com.
If you do not configure the email clients to send email through the FortiMail unit, incoming email delivered to your protected email server can be scanned, but email outgoing from your email users cannot.
Also configure email clients to authenticate with the email user’s user name and password for outgoing mail. The user name is the email user’s entire email address, including the domain name portion, such as user1@example.com.
If you do not configure the email clients to authenticate, email destined for other email users in the protected domain may be accepted, but email outgoing to unprotected domains will be denied by the access control rule.
Testing the installation
Basic configuration is now complete, and the installation may be tested. For testing instructions, see Testing the installation.
Example 2: FortiMail unit in front of a firewall
In this example, a FortiMail unit operates in gateway mode within a private network, but is separated from the protected email server and local email users’ computers by a firewall. The protected email server is located on the demilitarized zone (DMZ) of the firewall. The local email users are located on the internal network of the firewall. Remote email users’ computers and external email servers are located on the Internet, outside of the private network. The FortiMail unit protects accounts for email addresses ending in “@example.com,” which are hosted on the local email server.
FortiMail unit in front of a NAT device
To deploy the FortiMail unit in front of a NAT device such as a firewall or router, you must complete the following:
|
|
This example assumes you have already completed the Quick Start Wizard and configured records on the DNS server for each protected domain. For details, see Running the Quick Start Wizard and Configuring DNS records. |
Configuring the firewall
In order to create the firewall policies that governs traffic from the IP addresses of local email users, the protected email server, and the IP address of the FortiMail unit, you must first define the IP addresses of those hosts by creating firewall address entries.
In order to create the firewall policies that forward from the FortiMail unit and local and remote email users to the protected email server, you must first define static NAT mappings from a public IP address on the FortiGate unit to the IP address of the protected email server, and from an internal IP address on the FortiGate unit to the IP address of the protected email server, by creating virtual IP entries.
With the FortiMail unit in front of a FortiGate unit, the internal network located behind the FortiGate unit, and the protected email server located on the DMZ, you must configure firewall policies to allow:
- between the internal network and the FortiMail unit
- between the internal network and protected email server
- between the protected email server and the FortiMail unit
- between the protected email server and the Internet
For more information about how to configure the firewall address, virtual IPs, and firewall policies, see the FortiGate documentation.
Configuring the MUAs
Configure the email clients of local and remote email users to use the FortiMail unit as their outgoing mail (SMTP) server/MTA. For both local and remote email users, this is 10.10.10.5 or fortimail.example.com.
If you do not configure the email clients to send email through the FortiMail unit, incoming email delivered to your protected email server can be scanned, but email outgoing from your email users cannot.
Also configure email clients to authenticate with the email user’s user name and password for outgoing mail. The user name is the email user’s entire email address, including the domain name portion, such as user1@example.com.
If you do not configure the email clients to authenticate, email destined for other email users in the protected domain may be accepted, but email outgoing to unprotected domains will be denied by the access control rule.
Testing the installation
Basic configuration is now complete, and the installation may be tested. For testing instructions, see Testing the installation.
Example 3: FortiMail unit in DMZ
In this example, a FortiMail unit operating in gateway mode, a protected email server, and email users’ computers are all positioned within a private network, behind a firewall. However, the FortiMail unit is located in the demilitarized zone (DMZ) of the firewall, separated from the local email users and the protected email server, which are located on the internal network of the firewall. Remote email users’ computers and external email servers are located on the Internet, outside of the network protected by the firewall. The FortiMail unit protects accounts for email addresses ending in “@example.com”, which are hosted on the local email server.
FortiMail unit in DMZ
To deploy the FortiMail unit in the DMZ of a firewall, you must complete the following:
|
|
This example assumes you have already completed the Quick Start Wizard and configured records on the DNS server for each protected domain. For details, see Running the Quick Start Wizard and Configuring DNS records. |
Configuring the firewall
In order to create the firewall policies that governs traffic from the IP addresses of local email users and the protected email server, and the IP address of the FortiMail unit, you must first define the IP addresses of those hosts by creating firewall address entries.
In order to create the firewall policy that forwards email-related traffic to the FortiMail unit, you must first define a static NAT mapping from a public IP address on the FortiGate unit to the IP address of the FortiMail unit by creating a virtual IP entry. You must also create virtual IPs to define static NAT mappings:
- from a public IP address on the FortiGate unit to the IP address of the protected email server
- from an IP address on the internal network of the FortiGate unit to the IP address of the FortiMail unit
- from an IP address on the DMZ of the FortiGate unit to the IP address of the protected email server
With the FortiMail unit in front of a FortiGate unit, and local email users and protected email server located behind the FortiGate unit on its internal network, you must configure firewall policies to allow traffic:
- between the internal network and the FortiMail unit
- between the protected email server and the Internet
- between the FortiMail unit and the Internet
For more information about how to create firewall policies, see the FortiGate documentation.
Configuring the MUAs
Configure the email clients of local and remote email users to use the FortiMail unit as their outgoing mail (SMTP) server/MTA. For local email users, this is 172.16.1.2, the virtual IP on the internal network interface of the FortiGate unit that is mapped to the IP address of the FortiMail unit; for remote email users, this is 10.10.10.1 or fortimail.example.com, the virtual IP on the wan1 network interface of the FortiGate unit that is mapped to the FortiMail unit.
If you do not configure the email clients to send email through the FortiMail unit, incoming email delivered to your protected email server can be scanned, but email outgoing from your email users cannot.
Also configure email clients to authenticate with the email user’s user name and password for outgoing mail. The user name is the email user’s entire email address, including the domain name portion, such as user1@example.com.
If you do not configure the email clients to authenticate, email destined for other email users in the protected domain may be accepted, but email outgoing to unprotected domains will be denied by the access control rule.
Testing the installation
Basic configuration is now complete, and the installation may be tested. For testing instructions, see Testing the installation.