Configurations
Auto-routing is a trunking technology that provides load balancing and fault tolerance for all outbound requests, but it does not apply to inbound requests. These are handled by a unique technology called SwiftDNS, a multihoming service which includes load balancing and fault tolerance for inbound requests. The minimum requirements for multihoming are networks must have multiple WAN links and registered domain names for publicly accessible servers. Note that a DNS request from client is delivered to FortiWAN via a fixed WAN link, whose the IP address is registered with parent domain. It would be better to have multiple IP addresses registered to avoid single WAN link failure.
When FortiWAN receives a DNS query, it replies with a public IP assigned to one of the WAN links based on the settings of the answering policies. Therefore, subsequent requests to server will be sent to a public IP of the WAN link based on FortiWAN’s previous response. The policies are based on weight for each WAN link and are definable. Multihoming is also capable of automatically detecting the best links by “Optimum Route”, and if WAN link failure occurs, the public IP assigned to that failed link will not be returned even though the servers are still reachable via other links.
FortiWAN offers two options for Multihoming: Non Relay Mode and Relay Mode. The details of will be explained in this section.
The section explains how to configure Multihoming. First, check the box to enable Multihoming in “Enable Multihoming”. Multihoming supports Backup mechanism. To enable this function, check “Enable Backup” and enter the IP addresses of the backup server.
FortiWAN provides mechanisms to record, notify and analysis on events refer to the Multihoming service, see “Log”, “Statistics: Traffic”, “Statistics: Bandwidth” and “Reports”.
Non-Relay Mode
To enable Multihoming in non-relay mode, go to Service > Multihoming on the Web UI, check the box Enable Multihoming, and uncheck the box Enable Relay. FortiWAN will performs DNS analysis on local host if the relay mode is disabled. It contains three blocks to get non-relay mode Multihoming configured: Global Settings, Policy Settings and Domain Name Settings.
Global Settings: IPv4/IPv6 PTR Record
PTR (Pointer Record) is used to resolve the IPv4/IPv6 address to a domain or hostname.
| TTL | Set the TTL for the PTR record. TTL (Time To Live) Specifies the amount of time that the record will stay in cache on systems requesting the record (other resolving nameservers, applications, browsers and etc.). |
| Reverse Lookup Zone | Set the reverse lookup zone (domain) of the hosts for the PTR record. Click the add button to create new tables for configuring other zones. |
| Zone Name | The reverse lookup zone name. For hosts in IPv4 subnet 1.2.3.0/24
(such as 1.2.3.4, 1.2.3.5 and etc.), the reverse lookup zone for its PTR records is 3.2.1.in-addr.arpa. Thus, this field should be filled in with “3.2.1”. For host with IPv6 2001:470:0:64::2 (/64), the reverse lookup zone is 4.6.0.0.0.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa and this field should be filled in with “4.6.0.0.0.0.0.0.0.7.4.0.1.0.0.2”. Click Hide Details / Show Details to collapse or expand the SOA configurations of the reverse lookup zone. |
| SOA | SOA (Start of Authority) record of the reverse lookup zone. | ||
| Primary Name
Server |
The primary name server for the reverse lookup zone or the first name server in the name server list below. | ||
| Host Email | The responsible party for the reverse lookup zone. | ||
| Serial Number | A timestamp that changes whenever you update the reverse lookup zone. | ||
| Refresh Time | The number of seconds before the reverse lookup zone should be refreshed. | ||
| Retry Time | The number of seconds before a failed refresh should be retried. | ||
| Expire Time | The upper limit in seconds before the reverse lookup zone is considered no longer authoritative. | ||
| Minimum TTL | The negative result TTL. | ||
| NS1 NS record. The primary name server for the reverse lookup zone. | |||
| NS2 NS record. The secondary name server for the reverse lookup zone. | |||
| Entries | Set the PTR entries in the reverse lookup zone. Click the add button to create multiple PTRs. | ||
| IP Number | The last octet of the host IP address for resolving in the reverse lookup zone. For a IPv4 host 1.2.3.4 in the reverse lookup zone
“3.2.1.in-addr.arpa”, this field should be filled in with “4”. For host with IPv6 2001:470:0:64::2 (/64), this field should be filled in with “2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0”. |
||
| Host Name | The FQDN of the host that that Multihoming will response to the request for resolving IPv4 address 1.2.3.4 or IPv6 address 2001:470:0:64::2, such as “www.example.com”. | ||
Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!