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.

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.

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.

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.

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.

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”.

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

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.