DNS Proxy

Conceptually, FortiWAN’s DNS Proxy is a function to dynamically redirect outgoing DNS requests (UDP 53) to an appropriate DNS server according to FortiWAN’s WAN link loading. It is implemented by dynamically replacing the original destination IP address of outgoing DNS requests with another DNS server IP address. No matter what the DNS server that an internal host is configured with, for any outgoing DNS request passing through FortiWAN, DNS Proxy replaces the original destination IP address of the DNS requests with the DNS server IP address determined by a load balancing algorithm. Basically, FortiWAN’s DNS Proxy selects a WAN link with lighter traffic loading and replace original destination of the DNS query packet with another DNS server that is associated with the WAN link.

How the DNS Proxy works and its configurations

Once DNS Proxy is enabled, any DNS request (UDP 53) received on FortiWAN’s LAN and DMZports will be evaluated. DNS Proxy contains two phases; selecting a WAN link with lighter traffic loading (depends on the specified algorithm) and replacing the destination of DNS queries. Configuration of DNS Proxy contains three basic elements:

• An algorithm used to select a WAN link l Participating WAN links
• The DNS servers used to replace the original destination of packets

DNS Proxy determines the DNS server for replacement by selecting one of the participating WAN links.

DNS Proxy Setting Fields

What DNS Proxy performs to DNS packets is only replace the destination of DNS packets; it does not involve routing for the packets. DNS Proxy select a WAN link only for the destination replacement, not for routing the packets. Auto Routing determines the route for the outgoing DNS packets (actually, Auto Routing is the only function routing for all outbound traffic, see Auto Routing). For example, although DNS Proxy selects WAN 1 for replacing destination of a DNS packet with IP of the DNS server associated with WAN 1, FortiWAN routing function might transfer it through other WAN links (WAN 2 or WAN 3) or a LAN port.

Scenario

Here is an example using algorithm By Weight to select the DNS server for the destination replacement in the weight WAN1:WAN2 = 2:1.

According to the configuration, all the DNS requests received on FortiWAN’s LAN ports and DNS ports will be reworked as followings:

DNS Proxy for peering issue

Actually, DNS Proxy is mainly used to resolve potential traffic congestion on single WAN link due to the usage of Optimum Route for resolving ISP peering issue (certainly, it can also be used for just redirecting DNS requests to another DNS server, which is unrelated to peering issue). As mentioned in Optimum Route Detection, Optimum Route does resolve the inefficient transmission resulted by bad peering between ISPs. No matter which detection mode is used for Optimum Route, traffic to a particular destination will be almost fixed by Optimum Route on particular WAN links (which the WAN links connect to the same ISP subnet that the particular destination is located in) if this ISP has bad peering with other ISPs (other WAN links). In real practice, most of service providers or internet content providers will not deploy their servers in only one ISP network if peering issue exists between ISPs. To provide service to users located in different ISP networks, they will logically deploy servers in several ISP networks, and maintain DNS servers (or appropriate settings on ISP’s DNS) for a common domain in each of the ISP networks. Each of the DNS servers will answer the IP address of corresponding application server that is located in the same ISP network together with the DNS server to any DNS query for the server name. In other words, asking different DNS servers (located in different ISP networks) for the same server name will be responded with different IP addresses, which belong to different ISP networks. Users in an ISP network can access the server located in the same ISP network without passing across others ISPs if they ask an appropriate DNS.

Even if FortiWAN connects to multiple ISP networks, the problem is that users behind FortiWAN are usually configured with a fixed DNS server (that is probably located in one of the connected ISP networks), which means they always ask the same DNS server for a server name and are responded with the same IP address of the server. A user will not know other IP addresses of the same server name in other ISP networks unless they change DNS configuration to others.

For example a FortiWAN transfers outbound traffic by Auto Routing with Optimum Route (see Auto Routing and Optimum Route). In the above diagram, the DNS 1 (10.10.10.100) in ISP-1 network answers 10.10.10.10 to query for server name www.abc.com, while the DNS 2 (20.20.20.100) in ISP-2 network answers 20.20.20.20 to the query for the same server name. In other words, traffic to www.abc.com will be routed to WAN 1 by Optimum Route if a client asks DNS 1 for www.abc.com, or traffic will be routed to WAN 2 by Optimum Route if the client asks DNS 2 for www.abc.com. However, the clients in LAN are configured with a static DNS address no matter manually or by DHCP. If all the clients in LAN are configured with DNS Server = 10.10.10.100, all the traffic to www.abc.com will fixedly be destined to 10.10.10.10 through WAN 1. This is what we mentioned traffic congestion on single WAN link resulted by usage of Optimum Route for resolving ISP peering issue.

For this reason, FortiWAN’s DNS Proxy is a mechanism used to detect a WAN link with lighter traffic loading and redirect a DNS query to the DNS server located in the ISP network connected by the WAN link. For example, if DNS Proxy detects WAN 2 has lighter traffic loading than WAN 1, DNS queries for www.abc.com will be redirected to DNS 2 (20.20.20.100) and the response for www.abc.com will be 20.20.20.20. With appropriate configuration on Optimum Route, traffic to www.abc.com can be routed to WAN 2. No matter what the original DNS server (destination IP) of the query is, DNS Proxy replace it with another DNS according to current WAN link loading. Therefore, accessing to the same service can to distributed into multiple WAN links with Auto Routing by Optimum Route for this case.

To use DNS Proxy with Optimum Route to improve the bad transmission efficiency resulted by bad peering between ISPs, here is the basic premise for using DNS Proxy:

• FortiWAN connects to the bad-peering ISP networks through different WAN links.
• Optimum Route Detection is appropriately configured, and corresponding Auto Routing policy and filters are created for routing traffic by the algorithm: By Optimum Route. Without these configurations, the basic peering issue does not get resolved, and DNS Proxy becomes meaningless for this.
• Make sure that a service provider deploys different servers in the bad-peering ISP networks, and maintains DNS servers to answer corresponding IP address of the server that is located in the same ISP network with the DNS server. DNS Proxy will become helpless for this case if the service is only deployed in a ISP network.
• List these particular DNS servers located in each of the ISP networks. A DNS server must be associated with a WAN link connected to the ISP network that the DNS server is located in.

Scenario

Base on the above example, make sure Optimum Route Detection and Auto Routing are configured before going on DNS Proxy. We assume that the Optimum Route Policy (see Optimum Route Detection) is configured as Static IP Table as followings:

You can also set the Optimum Route Policy as Dynamic Detect, Static & Dynamic or Dynamic & Static, see Optimum Route Detection for the details.

The Auto Routing policy and filter rule are correspondingly configured as followings (see Auto Routing for details):

The above settings provides the basic solution of bad peering between ISP 1 and ISP 2. In this example, servers of www.abc.com are deployed in both ISP 1 and ISP 2 networks, and the DNS server in each ISP network answers corresponding IP to requests for www.abc.com. To introduce DNS Proxy to the case to dynamically distribute sessions to www.abc.com through the two WAN links, it requires the following settings of DNS Proxy configured:

We use algorithm By Total Traffic to select the DNS server associated with the lightest-loaded WAN link for the destination replacement (you can try other algorithms).

The configurations guarantees that destinations of DNS packets querying for www.abc.com will be replaced with

DNS servers 10.10.10.100 or 20.20.20.100 in circular order according to weight 2:1. DNS packets processed by DNS Proxy will be transferred outward according the Auto Routing policies. In this case (bad peering exists between the two ISPs), it is better to let DNS packets destined to 10.10.10.100 be routed to WAN 1 and DNS packets destined to 20.20.20.100 be routed to WAN 2. Packets might be stuck by the bad peering if packets destined to 10.10.10.100 be routed to WAN 2. Here, with Optimum Route being used in the Auto Routing policy, DNS packets processed by DNS Proxy will be routed to appropriate WAN link to avoid the bad peering. Possible query loop

Since DNS Proxy forwards queries, you should be careful with the deployments to avoided possible query loop. Here are the two cases that DNS Proxy might cause query loops.

Case 1

If DNS Proxy is configured to forward DNS queries to a DNS server located in FortiWAN’s LAN or DMZ subnets, and this DNS server resolves queries by interacting with other DNS servers in the Internet through FortiWAN, a

SNMP

query loop will happen. DNS Proxy forwards the queries that the DNS server in LAN or DMZ sends to the DNS servers outside FortiWAN back to the DNS server in LAN or DMZ.

Case 2

FortiWAN’s Internal DNS (see Internal DNS) provides service on IP address 223.255.255.2 that FortiWAN uses it for internal operations. However, if the DNS server in Network Setting (System > Network Setting > DNS Server, see Set DNS server to FortiWAN) is configured, Internal DNS will forward queries to the configured DNS servers rather that resolving them itself. Now, if you configure System > Network Setting > DNS Server with DNS servers located in FortiWAN’s LAN or DMZ subnets, enable the Internal DNS, and configure Proxy DNS to forward queries to 223.255.255.2, a query loop will happen.

All the DNS queries are forwarded by DNS Proxy to 223.255.255.2 which is the Internal DNS, then these queries are forwarded again by Internal DNS to the DNS servers in LAN or DMZ which are configured in System > Network Setting > DNS Server. The DNS servers might resolve queries by interacting with other DNS servers in the Internet through FortiWAN. DNS Proxy forwards the queries that the DNS server in LAN or DMZ sends to the DNS servers outside FortiWAN back to Internal DNS on 223.255.255.2, and the queries are eventually forwarded back to the DNS servers in LAN or DMZ.

SNMP

SNMP (Simple Network Management Protocol) is often used in managing TCP/IP networks by providing system information and sending event notifications to a SNMP manager. A SNMP manager is typically a host running the SNMP manager application. The SNMP manager communicates with the SNMP agent running on a FortiWAN unit; sends out SNMP requests and receives incoming event notification (SNMP trap) from the SNMP agent. The agent responds FortiWAN’s system information for SNMP requests and sends SNMP traps to the SNMP manager.

To monitor your FortiWAN system via SNMP, you must:

• Compile the FortiWAN MIB file to your SNMP manager.
• Make sure at least one network interface is well-configured to send out SNMP traps and receive SNMP requests. The SNMP manager can communicate with a FortiWAN unit via the IP addresses configured on the localhost of a WAN port, DMZ port or LAN port (See “Network Settings”).
• Make sure SNMP is acceptable to FortiWAN’s firewall (See “Firewall”). l Configure SNMP settings and Event Notification to FortiWAN unit.

SNMP agent configuration

To configure SNMP settings, go to Service > SNMP. Check the box Enable SNMP to enable SNMP agent on FortiWAN and select the SNMP version. FortiWAN supports SNMP v1, v2 and v3 protocols.

SNMP v1/2

SNMP

SNMP v3

SNMP trap for even notification

FortiWAN (SNMP agent) sends traps to a SNMP manager for notification when significant events occur. Enable the function by configuring the settings of Log Notification to FortiWAN (See “Notification”).

FortiWAN MIB

The FortiWAN MIB defines the structure of the management data maintained on FortiWAN. It contains the fields, information and traps that are specific to a FortiWAN units. The FortiWAN MIB file is available on the Fortinet Customer Service & Support website, https://support.fortinet.com/.

IP MAC Mapping

IP MAC Mapping

Users can specify the IP-MAC table by classifying periods like peak hours and idle hours. Once the IP-MAC table is set up, a packet from a certain IP address can pass through FortiWAN only when its MAC address matches the table list and time period.

FortiWAN provides log mechanism to the IP MAC Mapping service, see “Log”.

Statistics

This topic deals with FortiWAN network surveillance system. Comprehensive statistics are collected to monitor networking status, bandwidth usage of traffic class, and dynamic IP WAN link. These data offer deep insight into the network, and help detect unexpected network failures, boosting network reliability and efficiency.

Traffic

It sorts and displays real-time traffic of traffic class over WAN link. Select traffic direction (inbound/outbound) in Traffic Type to view statistics.

The table below shows 3 sorts of statistics:

• Maximum/Minimum bandwidth allocation and priority
• Traffic for the last 3 seconds
• Traffic for the last minute

The statistics are analyzed based on individual WAN connection and traffic direction. To view statistics, select from Traffic Type (Inbound/Outbound), traffic direction and WAN Link number.

Bandwidth

Unlike traffic statistics in previous section that focuses on real-time monitor of network status, statistics in BM

(Bandwidth Management) is intended for long-term analysis. For particular traffic class in a given traffic direction, Persistent Routing administrators can view bandwidth usage in bar graph during the past 60 minutes, 30 hours, 50 days, and 20 months.

Persistent Routing

It shows details with respect to persistent routing status. With persistent routing, administrators can view connections and manually reset these connections as well.

Clear All: Clear all the connections via persistent routing.

Automatic Refresh: Time interval to refresh persistent routing data.

IPv4/IPv6 IP Pair

Note that IP Pair and Web Service show at most 50 entries respectively.

WAN Link Health Detection

It shows WAN link health detection results regarding the reliability of a specific WAN connection. The data are derived based on ping results from destination IP list configurations in System > WAN Link Health Detection (See “WAN Link Health Detection”). It enables to observe the number of sent requests, number of received responses, and the success ratio for a given destination. These statistics assist administrators in further analyzing network status and user behavior.

Dynamic IP WAN Link

It shows dynamic IP WAN link details like its IP address obtained via PPPoE or DHCP. It also enables to create new IP addresses by re-establishing connections to the WAN.

DHCP Lease Information

It shows data DHCP lease assigns, i.e. lease IP and MAC address, client-hostname, and expiration time. Once option of DHCP server is selected, a list regarding all existing DHCP servers in the network will display. Option Automatic Refresh sets the time interval to regularly update DHCP servers.

RIP & OSPF Status

It shows RIP status based on RIP and OSPF settings in [System] -> [Network Settings] -> [LAN Private Subnet].

Data on this page are used to inspect private subnet’s Network IP, Netmask, and gateway list.

Connection Limit

It enables administrators to inspect the number of established connections in real-time and to justify the maximum number of connections allowed on [Service] -> [Connection Limit] page, to avoid network congestion.

Virtual Server Status

It displays status and statistics regarding virtual server defined in Service/Virtual Server.

FQDN

The IPv4 and IPv6 addresses of the FQDNs that connected via FortiWAN are shown in this page.

IPv4 FQDN

Tunnel Status

Tunnel Status displays the connectivity of every single GRE tunnel of each tunnel group defined in Service >

Tunnel Routing (see Tunnel Routing) and statistics of the corresponding data transmission

Tunnel Health Status

This table displays the connectivity and statistics of specified tunnel group in the following four fields.

Tunnel Traffic

Default Rule Subnets

This table lists the subnets (in the local and remote sites) that the default rules of the specified tunnel group consist of. See How to set up routing rules for Tunnel Routing for the details of default rule of a tunnel group.

The default rule subnets listed here and corresponding page on remote Web UI are supposed to be equal for a tunnel group, just the position is switched. Local subnets here are the opposite subnets for the remote site, and the opposite subnets here are the local subnets for the remote site.

Tunnel Traffic

It collects inbound/outbound traffic statistics regarding tunnel routing in the past 60 minutes, 24 hours, and 30 days. Statistics are displayed on chart.

IPSec

IPSec Statistics reports the usages and states of your configured IPSec Security Associations (See “IPSec”). Go to Statistics > IPSec, a select bar and two statistics tables are displayed.

Selector

Select the combination of Mode and Phase 1 here, and then the statistics of related IPSec SAs are reported.

IPSec

Statistics of the IPSec SAs associated to the ISAKMP SA you selected is displayed in two tables, Security Association Database and Security Policy Database.

Security Association Database

List information of each IPSec SA including local and remote IP addresses, negotiated encryption and authentication algorithms, timing and the states.

Traffic Statistics for Tunnel Routing and IPSec

Security Policy Database

List information of Quick Mode selector of each IPSec SA and the related time stamps.

For the details of parameters of IPSec, see “IPSec VPN in the Web UI”.

Traffic Statistics for Tunnel Routing and IPSec

Compare with general IP transmission, traffic transferred through FortiWAN’s Tunnel Routing or IPSec is charged extra on GRE/ESP encapsulation and decapsulation (See “Tunnel Routing” and “IPSec VPN”). In order to individually allocate bandwidth to applications encapsulated in GRE and ESP packets, Tunnel Routing and IPSEC are designed to be transparent to Bandwidth Management (See “Bandwidth Management”). Bandwidth Management shapes the traffic before packet encapsulation or after packet decapsulation. FortiWAN’s traffic statistics is associated with the operation of Bandwidth Management, which implies traffic of Tunnel Routing and IPSec is partially transparent to the statistics function. FortiWAN gives the traffic statistics in three ways: BM log, statistics on Web UI and FortiWAN Reports. Traffic statistics for Tunnel Routing and IPSec in the three ways are discussed as follows.

Traffic Statistics for Tunnel Routing and IPSec

BM logs

A BM log is actually a traffic statistics (inbound-pkts, inbound-bytes, outbound-pkts, outbound-bytes, total-pkts and total-bytes) in a time period for a traffic (source IP, destination IP, source port and destination port) that matches the Bandwidth Management filter (See Log format in “Log View”). Bandwidth Management treats the traffic equally no matter whether it is later transferred through Tunnel Routing and IPSec. The BM log tells nothing directly (through the source port and destination port fields) that a transmission is actually done by Tunnel Routing, IPSec or normal IP routing. You might be aware of a Tunnel Routing and IPSec transmission through the source IP and destination IP in the logs, if you those IP addresses are already predefined just for the Tunnel Routing and IPSec transmission. The only situation that you see the GRE or ESP indicated by source port and destination fields in a BM log is when the traffic comes from other VPN devices.

Statistics on Web UI

Pages Statistics > Traffic and Statistics > BM(See “Statistics > Traffic” and “Statistics > BM”) the traffic statistics by WAN links and defined Bandwidth Management classes, which tells nothing directly about Tunnel Routing and IPSec traffic. The way to identify the traffic that is transferred through Tunnel Routing or IPSec is to create a BM class and BM filter to classify the traffic by the source IP and destination IP that are defined in Tunnel Routing’s routing rules or IPSec’s Quick Mode selectors.

Page Statistics > Tunnel Traffic (See “Statistics > Tunnel Traffic”) is the only page reports the traffic statistics about Tunnel Routing. Although traffic statistics is reported by the defined Tunnel Routing groups, statistics of the individual application in the tunnel traffic is unavailable here.

Page Statistics > IPSec (See “Statistics > IPSec”) tells nothing about traffic statistics of IPSec, only IPSec connectivity states are reported here.

FortiWAN Reports

Different from BM logs, service of traffic that is transferred through Tunnel Routing is indicated as GRE in Reports (See “Reports > Bandwidth Usage > Services”). Individual service type of the original packets encapsulated by Tunnel Routing becomes invisible in Reports. The GRE traffic passing through FortiWAN from other VPN devices and the GRE traffic generated by FortiWAN Tunnel Routing will be counted into service GRE in page Reports > Bandwidth Usage > Services, which might be confusing. Drilling it down by Internal IP, Inclass or Outclass could figure it out. As for traffic transferred through IPSec, Reports counts the traffic by individual application (the original packets before/after be ESP encapsulated/decapsulated) rather than counting it into service ESP. FortiWAN IPSec is transparent to Reports statistics.

Here are a summary of discussion above.

Traffic transferred through IPSec Tunnel mode

Traffic transferred through Tunnel Routing or IPSec Transport mode

Traffic Statistics for Tunnel Routing and IPSec

We have a simple example to explain the difference between the statistics ways. Consider that user A generates

60MB FTP traffic and 80MB HTTP traffic and transfer them through normal IP routing, user B generates 40MB FTP traffic and 20MB HTTP traffic and transfer them through Tunnel Routing (through one tunnel group). All the traffic is controlled by Bandwidth Management, thus there will be four BM logs indicating:

• user A (source IP) generates FTP traffic (source or destination port) in 60MB l user B (source IP) generates FTP traffic (source or destination port) in 40MB l user A (source IP) generates HTTP traffic (source or destination port) in 80MB l user B (source IP) generates HTTP traffic (source or destination port) in 20MB

From the BM logs, we have no idea which one is transferred through Tunnel Routing. The thing we know from the logs is 100MB FTP traffic and 100MB HTTP traffic passed through FortiWAN, and they are 200MB in total.

In page Statistics > Tunnel Traffic, we see 60MB tunnel traffic (parts of the 200MB) belongs to the tunnel group. However, it tells nothing about the statistics for the individual services (FTP and HTTP) in the tunnel traffic.

As for Reports > Service, statistics by service is displayed as follows: l FTP = 60MB l HTTP = 80MB l GRE = 60MB

• Total = 200MB

All the tunnel traffic (FTP and HTTP generated by user B) is classified into GRE, and we have no idea about what the original services are in it. What we can do is drilling it down by Internal IP to identify the generator user B, or drilling it down by Inclass and Outclass to identify the individual service if the corresponding BM classes are welldefined.

Considering the IPSec transmission with the same example, user B generates the same traffic but transfer them through IPSec. We will have BM logs the same as what we discussed above, and have no idea which service is transferred through IPSec. In page Report > Service, the traffic is counted as follows: l FTP = 100MB l HTTP = 100MB l Total = 200MB

Drilling it down by Internal IP can identify the generators user A and user B, but it tells nothing about service ESP.

Log

This topic deals with how to configure logging and how to forward logs. Log records keep FortiWAN data and are capable of storing a wide variety of data concerning System, Firewall, Routing, and bandwidth management, etc. Log files can be forwarded to other servers for archiving or for notifying events via emails (see “Log Control” and “Log Notification”).

Additionally, FortiWAN offers a powerful reporting and analysis tool: Reports. The web-based analysis software that is embedded in FortiWAN or running on an independent machine enables administrators to gain insights into network traffic without manually filtering through large volumes of log data (See “Enable Reports”).

View

View has a sub-menu of 13 log types (see the table below). Choose the desired log type, and its corresponding events will show in display window. Click the Refresh button to get the latest log records. Please be aware that this page is only for online viewing of current events. For log data pushing and archiving, see the Control in next section.

Log format

A log listed here consists of three parts:

{TIMESTAMP} {LOG_TYPE} {LOG_CONTENT}

The {TIMESTAMP} is in the format ‘yyyy-mm-dd HH:MM:SS’ and is always an UTC time. The details of {LOG_ TYPE} and {LOG_CONTENT} are described as follows.

Notation Conventions

{ADDRPORT} follows TCPDUMP format, for example:

• IPv4: 8.8.8.80 l IPv6: 2001::8:8:8:8.80 {IP-5-TUPLE}
• ICMP:PROTO=1 SRC=<ip> DST=<ip> ID=<icmpid> TYPE=<icmptype> CODE=<icmpcode> (BM log dones’t have TYPE and CODE fields, because they are bypacket)
• TCP:PROTO=6 SRC=<{ADDRPORT}> DST=<{ADDRPORT}> l UDP:PROTO=17 SRC=<{ADDRPORT}> DST=<{ADDRPORT}> l ICMPv6:PROTO=58 SRC=<ip> DST=<ip> TYPE=<icmpv6type> CODE=<icmpv6code> l Others:PROTO=<protocol num> SRC=<ip> DST=<ip>

Firewall

See “Firewall” for further information.

NAT

See “NAT” for further information.

Auto & Persistent Routing

AR {IP‐5‐TUPLE} AR=[<widx>|NONE] TOTLEN=<pktlen>

Virtual Server

See “Virtual Server” for further information.

BM

See “Bandwidth Management” for further information.

Connection Limit

Count Limit

Rate Limit

See “Connection Limit” for further information.

Cache Redirect

See “Cache Redirect” for further information.

Multihoming

See “Multihoming” for further information.

Dynamic IP

DHCP

PPPoE

PPPOE WLINK=<widx> ACTION=<start|terminated|bind> [IP=<ip>]

IP-MAC Mapping

See “IP-MAC Mapping” for further information.

Tunnel Routing

See “Tunnel Routing” for further information.

IPSec

See “IPSec VPN” for further information.

System Admin session

• <account> logged in from <ip> l <account> logged out from <ip> Account change
• Administrator account <account> removed l Monitor account <account> removed
• Administrator account <account> password successfully changed l Administrator account <account> successfully added

Monitor account <account> password successfully changed

Monitor account <account> successfully added

Access deny

• Incorrect <account> password from <ip> l Maximum # of Administrator/<account> login reached l Maximum # of Monitor/<account> login reached UI command
• There is no slave l Configuration synchronization finished successfully l Configuration synchronization failed l Peer information is not available l ARP caches are updated l Neighbor Discovery caches are updated l System time synchronized l No NTP servers in system settings l License key <key> is applied successfully, system rebooting…
• License key <key> is applied successfully l Test email is sent to <receiver> l Failed to send test email to <receiver>

UI setting

• Settings are applied for page System -> <page name> l Settings are applied for page Service -> <page name> l Settings are applied for page Log -> <page name> l Unable to add account. The maximum number of Administrator accounts have been reached. l Unable to add account. The maximum number of Monitor accounts have been reached.
• Settings are applied for RADIUS Authentication l Error starting notification daemon l Error in starting daemon for page Service -> Internal DNS l Error in starting daemon for page Service -> Multihoming Info access error l Cannot save log/event settings Update l System firmware updated

Config

System configuration restored

Multihoming daemon file write error

Shutdown

• System reset to factory default settings l System reboot Instant push
• Pushing <logtype> is initiated l Failed to push <logtype>

Service error l Restarting Internal DNS Error Connection overflow l Current Connection Number(<connections>) reach <limit> Rate overflow l Current Rate Number(<connection rate>) reach <limit> Undefined code l Undefined event code <event code> VRRP

• VRRP become master l VRRP become backup l VRRP double-check failed HA
• Peer version changed from “<Model>” to “<Model>” l Peer serial number changed from “<Serial Number>” to “<Serial Number>” l Peer state changed from “<State>” to “<State>” l Responded to Slave’s Time Synchronization Request l Responded to Slave’s Configuration Synchronization Request l Stopped configuration synchronization due to errors l Finished configuration synchronization with the Slave l Won precedence over the booting peer. Enter the Master state. l Preceded by the booting peer. Enter the Slave state. l Master heartbeat detected. Enter the Slave state.
• Slave heartbeat detected. Enter the Master state. Panic heartbeat detected. Enter the Master state.

No heartbeat detected. Enter the Master state.

Log Control

• Won precedence over the incompatible peer. Enter the Master state.
• Preceded by the incompatible peer. Enter the Panic state.
• Peer heartbeat stopped. Enter the Master state to take over services. l Preceded by another Master. Reboot to enter the Slave state.
• Too Much port down. Reboot to enter the Slave state. l Preceded by the incompatible peer. Enter the Panic state. l Peer heartbeat stopped. Enter the Master state to take over services. l Two Slaves linked at the same time. Restart HA after random delay. l Master is gone. Enter the Master state to take over services.
• Peer heartbeat stopped l Time synchronization failed. l Configuration synchronization failed.

Log Control

Control sets to forward data from FortiWAN to servers via FTP, E-mail and Syslog (protocol) for archiving and analysis. Configure log push method one log type by another, or use “Copy Settings to All Other Log Types”. It copies and applies settings of one log type to others avoiding unnecessary duplicating of settings.

Notification

Enable Scheduled Push    :   Check to enable pushing schedule.

Initial Time    :   Start time for scheduled push.

Period    :    Duration for scheduled push.

Methods

FortiWAN transfer logs with FTP, Email and Syslog. It either forwards logs to external FTP server, administrator’s mail account via SMTP or a remote syslog servers.

FTP

Note: If the Server is applied with a FQDN, then the DNS Server must be set in the Web UI [System]->[Network Settings]->[DNS Server] (See “Set DNS server for FortiWAN”).

Notification

Two methods are provided to send out the notifications for important system events: E-mail and SNMP trap.

Please configure the settings for the methods and select the event type to notify.

Notification

E-Mail Settings

The table below summarizes the event notification mail setup:

Note: If the SMTP Server is applied with a FQDN, then the DNS Server must be set in the Web UI System > Network Settings > DNS Server (See “Set DNS server for FortiWAN”).

SNMP Trap Settings

Event notification can also be sent via SNMP traps. These can only be sent if there is an existing SNMP manager for receiving FortiWAN’s SNMP traps.

Notification

Types of Events to Notify

Enable Reports