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

Enable DNS Proxy	Enable/disable DNS Proxy.
Algorithm	Select an algorithm (See Load Balancing Algorithms) for selecting one of the participating WAN links:
l	By Weight: select a WAN link from the participants in weighted round-robin.
l	By Down Stream: always select the WAN link that has the lightest downstream traffic.
l	By Up Stream: always select the WAN link that has the lightest upstream traffic.
l	By Total Traffic: always select the WAN link that has the lightest total traffic. The algorithm specified here determines a WAN link only for getting the associated DNS server to replace destination of the DNS packets. The selected WAN link is not for routing the packets. Auto Routing determines the WAN link to transfer the packets outward according to the policies.

 

WAN	Select the participating WAN links by specifying the DNS servers and weight. From the drop-down menu, select a WAN link and configure the following fields Weight and Server 1 – 3. Then the WAN link becomes one of the participating WAN links for DNS Proxy selects according to the specified algorithm. After DNS Proxy selects a WAN link for a DNS request according to the specified algorithm, the destination of the DSN packet will be replaced with the DNS server associated to the WAN link. You can associate maximum of three DNS server IP addresses to a WAN link. DNS Proxy detects availability of the specified DNS servers and chooses the first available server for every replacement. A replacement will not take place if no specified server is available. IP addresses of DNS servers specified here can be internal or external IP addresses. DNS packets processed by DNS Proxy will be transferred toward the internal or external IP address according routing rule set in Network Setting (see Configuring your WAN and LAN Private Subnet) and Auto Routing (see Auto Routing). No matter which algorithm is specified, if only one WAN link is configured here, DNS packets will be always processed with the DNS server associated with the WAN link. In other words, DNS Proxy redirects DNS requests to a fixed DNS server regardless of traffic loading on WAN links.
	Weight	Give a weight to the WAN link. This field is visible when By Weight is selected in Algorithm.
	Server 1	Specify IP address of the first DNS server to the WAN link. This IP address will be used to replace the destination of a DNS packet if the associated WAN link is selected. Getting this field configured is necessary to have a WAN link participated in DNS Proxy. A WAN link without configuring this field will not participate in DNS Proxy.
	Server 2	Specify IP address of the second DNS server to the WAN link. This IP address will be used for the replacement if Server 1 is not available. This is optional.
	Server 3	Specify IP address of the third DNS server on the WAN link. This IP address will be used for the replacement if Server 1 and Server 2 are not available. This is optional.
Source	DNS request packets coming from the specified source will be matched. Enter a single IPv4 address, IPv4 range (in format xxx.xxx.xxx.xxx-xxx.xxx.xxx.xxx) or a IPv4 subnet (in format xxx.xxx.xxx.xxx/netmask).Keep it blank for matching any source.
Domain Name	DNS requests for the specified domain name will be matched. A wildcard character is accepted for the left-most label of a domain name, e.g. *.fortinet.com or *fortinet.com. Note that other formats such as www.*.com, www.fortinet.* or *.fortinet.* are not supported. Keep it blank for any domain name.

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.

Algorithm
By Weight
	DNS Server
WAN	1               2
Weight	2               1
Server 1	211.136.28.237          202.106.0.20
Server 2	–                –
Server 3	–                –

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

Packet	Source	Request A record for	Original destination	Hit WAN link	Replaced destination
Packet 1	192.168.0.10	www.abc.com	8.8.8.8	WAN1	211.136.28.237
Packet 2	192.168.0.101	www.def.com	202.96.209.5	WAN1	211.136.28.237
Packet 3	192.168..0.66	www.ijk.com	202.96.209.133	WAN2	202.106.0.20
Packet 4	192.168.0.23	www.opq.com	211.136.150.66	WAN1	211.136.28.237
Packet 5	192.168.0.7	www.rst.com	223.5.5.5	WAN1	211.136.28.237
Packet 6	192.168.0.211	www.xyz.com	211.136.112.50	WAN2	202.106.0.20

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:

	ISP-1 Network	ISP-2 Network
Table Name	ISP1	ISP2
Setting	Upload the IP file of ISP 1. The IP subnet 10.10.10.0/24 is maintained in the file.	Upload the IP file of ISP 2. The IP subnet 20.20.20.0/24 is maintained in the file.
Parameter	Check WAN1	Check WAN2

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):

Label	Algorithm					Parameter
OR_W1_W2	By Optimum Route					Check WAN1 and WAN2
When		Input Port	Source		Destination		Service	Routing Policy
All-Time		Any Port	Any Address		WAN		Any	OR_W1_W2

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

Algorithm
By Total Traffic
	DNS Server
WAN	1                 2
Server 1	10.10.10.100          20.20.20.100
Server 2	–                  –
Server 3	–                  –
Proxy Domains
www.abc.com

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.

Community	Enter the community which the SNMP belongs to.
System Name	Enter a string to represent this system.

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.

Internal DNS

Internal DNS is the DNS server built in FortiWAN used to manage your domain for internal users. Internal DNS resolve domain name for DNS requests coming from LAN or DMZ subnets. FortiWAN’s Internal DNS is recursive DNS, which allows users to resolve other people’s domains. The DNS servers set in System > Network Setting > DNS Server will be asked by Internal DNS while it recursively resolve an unknown domain (See “Set DNS server to FortiWAN”). In case that all the set DNS servers are not available or the DNS server is not configured, Internal DNS will ask the root domain name server for resolving the domain. Allocate the Internal DNS to users in LAN and DMZ subnets by manually set the DNS server on their computers to the gateways, which are LAN ports or DMZ ports. It is unable to automatically allocate FortiWAN’s internal DNS to users by FortiWAN’s DHCP. An user in LAN or DMZ subnet need to manually configure the DNS server on its computer to the gateway it connects to for using FortiWAN’s Internal DNS. Activate DNS function by configuring fields below:

Global Settings: IPv4 / IPv6 PTR Record

Enable Internal DNS

Turn on/off internal DNS server.

Internal DNS

IPv4 PTR Record	l	TTL: Specifies the amount of time other DNS servers and applications are allowed to cache the record.
	l	IPv4 Address: Enter the reverse lookup IPv4 address.
	l	Host Name: Enter the corresponding FQDN for the reverse IP.
IPv6 PTR Record	l	TTL: Specifies the amount of time other DNS servers and applications are allowed to cache the record.
	l	IPv6 Address: Enter the reverse lookup IPv6 address.
	l	Host Name: Enter the corresponding FQDN for the reverse IP.

Domain Settings

Domain Name		Enter domain names for the internal DNS. Press “+” to add more domains.
TTL		Assign DNS query response time.
Responsible Mail		Enter domain administrator’s email.
Primary Name Server		Enter primary server’s name.
IPv4 Address		Query IPv4 address. It can be: IPv4 single address, range, subnet, or predefined IPv4 group.
IPv6 Address		Query IPv6 address. It can be: IPv6 single address, range, subnet, or predefined IPv6 group.

NS Record

Name Server		Enter server name’s prefix. For example: if a server’s FQDN is “nsl.abc.com”, enter “nsl”.
IPv4 Address		Enter the IPv4 address corresponding to the name server.
IPv6 Address		Enter the IPv6 address corresponding to the name server.

A/AAAA Record

Host Name		Enter the prefix name of the primary workstation. For example: if the name is “www.abc.com”, enter “www”.
IP Address		Enter the IPv4/IPv6 address of the primary workstation.

Internal DNS

CName Record

Alias	Enter the alias of the domain name. For example, if “www1.abc.com” is the alias of “www.abc.com”, (domain name), enter “www1” in this field.
Target	Enter the real domain name. For example, if “www1.abc.com” is the alias of “www.abc.com”, enter “www”.

SRV Record

Service	Specify the symbolic name prepended with an underscore. (e.g. _http, _ftp or _imap)
Protocol	Specify the protocol name prepended with an underscore. (e.g. _tcp or _udp)
Priority	Specify the relative priority of this service (0 – 65535). Lowest is highest priority.
Weight	Specify the weight of this service. Weight is used when more than one service has the same priority. The highest is most frequently delivered. Leave is blank or zero if no weight should be applied.
Port	Specify the port number of the service.
Target	The hostname of the machine providing this service.
TTL	TTL (Time To Live) specifies the amount of time that SRV Record is allowed to be cached.

MX Record

Host Name	Enter the prefix of the mail server’s domain name. For example, if domain name is “mail.abc.com”, enter “mail”.
Priority	Enter the priority of the mail servers. The higher the priority is, the lower the number is.
Mail Server	Enter the IP address of the mail server.

External Subdomain Record

Subdomain Name

Enter the name of an external subdomain. To add an additional subdomain, press +.

 

NS Record	l	Name server – Enter the prefix of domain name (e.g. if the FQDN of the host is “ns1.abc.com”, enter “ns1”)
	l	IPv4 address – Enter the corresponding IPv4 address of the domain name.
	l	IPv6 address – Enter the corresponding IPv6 address of the domain name.

Cache Redirect

FortiWAN is capable of working with external cache servers. When a user requests a page from a web server on the internet, FortiWAN will redirect the request to the cache server. If the requested web page is already on the cache server, it will return the page to the user, thus saving time on data retrieval. Cache servers are configured here. However, cache servers have to support caching in transparent mode. Note: Cache Server can be in DMZ.

FortiWAN provides log mechanisms on events refer to the Connection Limit service, see “Log”.

Cache Group

The first table configures cache server groups. Multiple groups can have different sets of rules which are then created on the second table. In addition, the number of cache servers is not limited to one. Therefore it is possible to have multiple cache servers with different weights in the cache server group.

Group Name	Assign a name for this cache server group.
IP	The IPv4 address of the cache server.
Port	The port number of the cache server.
Weight	The weight for redirecting the requests to this cache server. A higher value means a greater the chance.

Cache Redirect

Associated WAN

Select WAN link associated with the cache server. Cache redirect works only when both the selected WAN link and the cache server are available. Selecting “NO” means cache redirect is not associated with WAN links. No matter a WAN link is available or not, cache redirect can work if the cache server is available.

Redirect Rule

Source	The source where the request originates and it will be redirected to the cache server. Specify the IP(s) when selecting “IPv4 Address”, “IPv4 Range” and/or IPv4 subnet (See “Using the web UI”).
Destination	The destination where the request will be sent and it will be redirect to the cache server. Specify the IP(s) when selecting “IPv4 Address”, “IPv4 Range” and/or IPv4 subnet (See “Using the web UI”).
Port	The service port number and it will be redirected to the cache server.
Group	Select “NO REDIRECT” for requests not to be directed. Or assign pre-existing group to redirect the requests.
L	Enable logging or not: If the box is checked, the logging will be enabled. Whenever the rule is matched, the system will write the event to the log file.

Redirect rules can be established to match requests that will be redirected to the specific cache server group.

Cache Redirect

Example 1 The Requested Web Page is NOT on the Cache Server

When FortiWAN receives a request from a client, the request will be redirected to the cache server. The cache server will determine if the data requested already exists or not. If not, then the request will be performed on behalf of the client with the data returned from the web server to the client.

Internal DNS

Example 2 The Requested Web Page is on the Cache Server

When FortiWAN receives a request from a client, the request will be redirected to the cache server. In this case, the data requested already exists on the cache server. Therefore it will return the data requested to the client without passing the actual request to the internet.

Connection Limit

Connection Limit is a feature that restricts the number of connections to remain below a certain specified limit. When the number of connections exceeds that limit, the system will automatically log the event (if logging is enabled). Connection limit can detect exceptionally high volumes of traffic caused by malicious attacks. FortiWAN protects the network by rejecting connections above the threshold.

Configurations of Connection Limit are divided into 2 sections: Count Limit and Rate Limit. Configuration of Count Limit is aimed to limit the number of total connections biult by one IP address simultaneously; that is to say the request of new connection via this IP address will be denied, once the count of connections reaches the connection number specified in this section. On the other hand, configuration of Rate Limit is aimed to restrict the number of connections built by one IP address every second. The source of connection can be from any of the following options: IP address, IP Range, Subnet, WAN, LAN, DMZ, Localhost, and any specific IP address.

FortiWAN provides mechanisms to record, notify and analysis on events refer to the Connection Limit service, see “Log”, “Statistics: Connection Limit” and “Report: Connection Limit”.

Log Interval

Log Interval         :     The log interval determines how often the system records when the number of the connections exceeds the limit defined in the rules table.

Rules – Count Limit

Source    :   Match connections from a specified source (See “Using the web UI”).

Count    :    Set the limit for maximum number of the connections.

Cache Redirect

L         :     Check to enable logging. If the box is checked, logging will be enabled. Whenever the rule is matched, the system will record the event to the log file.

Rules – Rate Limit

E	:	Enable: This rule can be matched. Disable: This rule does not need to be matched.
When	:	All of these three options are applicable 24 hours a day (See “Busyhour Settings”).
Source	:	Match connections from a specified source (See “Using the web UI”).
Destination	:	Match connections to specified Destination: This field is the same as the “Source” field, except that connections are matched with specified destination (See “Using the web UI”).
Service	:	The TCP/UDP service type to be matched. Select the matching criteria from publicly known service types (e.g. FTP), or enter the port number in TCP/UDP packets and specify the range. Type the starting port number plus hyphen “-“ and then the ending port number. e.g. “TCP@123-234” (See “Using the web UI”).
Conn/Sec	:	Specify the number of connection allowed per second, under the conditions of [When], [Source], [Destination], and [Service] defined.
L	:	Check to enable logging. If the box is checked, logging will be enabled. Whenever the rule is matched, the system will record the event to the log file.

Managing Bandwidth for Tunnel Routing and IPsec

Bandwidth Management is capable to control the original traffic that is encapsulated by Tunnel Routing or IPSec

VPN. Traffic that is going to be transferred outward through Tunnel Routing or IPSec VPN will be processed by

Bandwidth Management before encapsulating, and traffic that is transferred inward through Tunnel Routing or IPSec VPN is controlled by Bandwidth Management after decapsulating. In other words, FortiWAN’s Tunnel Routing and IPSec are transparent to Bandwidth Management (and the corresponding BM log and statistics). Bandwidth Management can only recognize the original applications (by matching a filter on the Service) that is going to be encapsulated or has been decapsulated by Tunnel Routing or IPSec. The GRE and ESP packets generated by FortiWAN are invisible to Bandwidth Management.

To control Tunnel Routing or IPSec transmission by Bandwidth Management, please make sure a Bandwidth Management filter is defined correctly (on the source, destination and service) to match its original packets. If you would like to control the overall Tunnel Routing or IPSec transmission no matter what the original services it is, try to classify the traffic by its Source and Destination; the Source and Destination of the Routing Rules of Tunnel Routing, or the Source and Destination of the Quick Mode selectors of IPSec Tunnel mode (See “How to set up routing rules for Tunnel Routing” and “IPSec VPN in the Web UI”).

Traffic shaping by Bandwidth Manage takes place before Tunnel Routing and IPSec encapsulations. Traffic of an application is counted together in BM logs no matter whether it is transferred through Tunnel Routing and IPSec, thus you cannot recognize the traffic statistics as a Tunnel Routing (includes Tunnel Routing over IPSec Transport mode), IPSec (Tunnel mode) or general transmission from the BM logs by the PROTO field (See “Log > View”). As for FortiWAN Reports, statistics of the traffic that is transferred through Tunnel Routing is indicated as GRE in the reports but it is unable to drill down to the individual services. On the other hand, you cannot recognize a traffic as FortiWAN’s IPSec in the service report pages, traffic that is transferred through FortiWAN

IPSec is separated into individual services. See “Traffic Statistics for Tunnel Routing and IPSec” for the details.

Note that during the period system applying the configurations of Bandwidth Management (click the Apply button on Web UI), traffic passing through FortiWAN will be blocked for a while.

Scenarios

Example 1 Inbound BM

The maximum bandwidth limited for internet users to transfer emails to mail server 211.21.48.197 in DMZ during both busy and idle periods is 128K on WAN1, 64K on WAN2, and 128K on WAN3. The guaranteed bandwidth on WAN1, WAN2 and WAN3 is zero.

The maximum bandwidth limited for hosts in LAN zone to download data from internet web servers during both busy and idle periods is 128K on WAN1, 64K on WAN2, and 64K on WAN3. The guaranteed bandwidth on WAN1, WAN2 and WAN3 is zero.

During the busy period, the maximum bandwidth limited for 192.168.0.100 to download data from internet FTP servers is 50K on WAN1, 30K on WAN2 and WAN3. The guaranteed bandwidth on WAN1 is 20K, and zero on WAN2 and WAN3. During the idle period, the maximum bandwidth limited for 192.168.0.100 to download data from internet FTP servers is 50K on WAN1, 200K on WAN2 and WAN3. The guaranteed bandwidth is 20K on WAN1, 100K on WAN2 and WAN3. The bandwidth is prioritized as “High” during both busy and idle periods.

During the busy period, the maximum bandwidth limited for internet users to upload data to FTP server

211.21.48.198 in DMZ is 500K on WAN1, 256K on WAN2 and WAN3. The guaranteed bandwidth on WAN1 is

200K, and zero on WAN2 and WAN3. During the idle period, the maximum bandwidth limited for internet users to upload data to FTP server 211.21.48.198 in DMZ is 500K on WAN1, 300K on WAN2 and WAN3. The guaranteed bandwidth is 200K on WAN1, WAN2 and WAN3. The bandwidth is prioritized as “Low” during both busy and idle periods.

Name	Link	Busy Hour Settings			Idle Hour Settings
		Guaranteed Max Kbps Kbps		Priority	Guaranteed Max Kbps Kbps		Priority
Mail Server	WAN1	0	128	Normal	0	128	Normal
	WAN2	0	64	Normal	0	64	Normal
	WAN3	0	128	Normal	0	128	Normal
For LAN Zone	WAN1	0	128	Normal	0	128	Normal
	WAN2	0	64	Normal	0	64	Normal
	WAN3	0	64	Normal	0	64	Normal
For 192.168.0.100	WAN1	20	50	High	20	50	High
	WAN2	0	30	High	100	200	High
	WAN3	0	30	High	100	200	High
FTP Server	WAN1	200	5000	Low	200	500	Low
	WAN2	0	256	Low	200	300	Low
	WAN3	0	256	Low	200	300	Low

Filter Settings

Source	Destination	Service		Classes
WAN	211.21.48.197	SMTP(25)		Mail Server
WAN	LAN	HTTP(80)		For LAN Zone
WAN	192.168.0.100	FTP(21)		For 192.168.0.100
WAN	211.21.48.198	FTP(21)		FTP Server

There are two possible scenarios for inbound data. One is local host downloading data from a remote FTP server in WAN, the other is a remote user in WAN uploading data to FTP in LAN. In both two scenarios data are sent from WAN to LAN. Thus it is necessary to configure BM rules for the scenarios on the Inbound BM page.

Example 2 Inbound BM

During the busy period, the maximum bandwidth limited for hosts in LAN zone to download data from FTP server 192.192.10.10 is 128K on WAN1, 128K on WAN2, and 64K on WAN3. During the idle period, the maximum bandwidth limited for hosts in LAN zone to download data from FTP server 192.192.10.10 is 512K on WAN1, WAN2 and WAN3. The guaranteed bandwidth on WAN1, WAN2 and WAN3 is zero during both busy and idle periods.

During the busy period, the maximum bandwidth limited for hosts 192.168.0.10 ~ 192.168.0.50 in LAN zone to download data from internet web servers is 128K on WAN1, 256K on WAN2 and WAN3. The gauranteed bandwidth is zero on WAN1, 128K on WAN2 and 64K on WAN3. During the idle period, the maximum bandwidth limited for hosts 192.168.0.10 ~ 192.168.0.50 in LAN zone to download data from internet web servers is 128K on WAN1, 512K on WAN2 and WAN3. The guaranteed bandwidth is zero on WAN1, WAN2 and WAN3. The bandwidth is prioritized as “Low” on WAN2 and WAN3 during both busy and idle periods.

During the busy period, the maximum bandwidth limited for hosts in a subnet 192.168.100.0/24 in LAN to download data from internet FTP servers is 50K on WAN1, 64K on WAN2 and WAN3. The guaranteed bandwidth on WAN1 is 20K, and zero on WAN2 and WAN3. During the idle period, the maximum bandwidth limited for hosts in a subnet 192.168.100.0/24 in LAN to download data from internet FTP servers is 20K on WAN1, 128K on WAN2 and WAN3. The guaranteed bandwidth is 20K on WAN1, 32K on WAN2 and WAN3. The bandwidth is prioritized as “High” during both busy and idle periods.

Configuring inbound BM class table

Name	Link	Busy Hour Settings			Idle Hour Settings
		Guaranteed Max Kbps Kbps		Priority	Guaranteed Max Kbps Kbps		Priority
For LAN Zone	WAN1	0	128	Normal	0	512	Normal
	WAN2	0	128	Normal	0	512	Normal
	WAN3	0	64	Normal	0	512	Normal
For 192.168.0.10-50	WAN1	0	128	Normal	0	128	Normal
	WAN2	128	256	Low	0	512	Low
	WAN3	64	256	Low	0	512	Low
For 192.168.100.0/24	WAN1	20	50	High	20	50	High
	WAN2	0	64	High	32	128	High
	WAN3	0	64	High	32	128	High

Filter Settings

Source	Destination	Service	Classes
192.192.10.10	LAN	SMTP(25)	For LAN Zone
WAN	192.168.0.10-192.168.0.50	HTTP(80)	For 192.168.0.10-50
WAN	192.168.100.0/255.255.255.0	FTP(21)	For 192.168.100.0/24

Example 3 Outbound BM

During the busy period, the maximum bandwidth limited for internet users to download data from FTP server 211.21.48.198 in DMZ is 128K on WAN1 and WAN2, and 64K on WAN3. During the idle period, the maximum bandwidth limited for internet users to download data from FTP server 211.21.48.198 in DMZ is 512K on WAN1, WAN2 and WAN3. The guaranteed bandwidth on WAN1, WAN2 and WAN3 is zero during both busy and idle period.

During the busy period, the maximum bandwidth limited for internet users to receive emails from mail server 211.21.48.197 in DMZ is 128K on WAN1 and WAN2, and 256K on WAN3. During the idle period, the maximum bandwidth limited for internet users to receive emails from mail server 211.21.48.197 in DMZ is 128K on WAN1 and WAN2, and 512K on WAN3. The guaranteed bandwidth on WAN1, WAN2 and WAN3 is zero. The bandwidth is prioritized as “Low” during both busy and idle periods.

During the busy period, the maximum bandwidth limited for internet users to download data from a virture FTP server 192.168.0.100 in LAN is 200K on WAN1, 100K on WAN2 and WAN3. The guaranteed bandwidth on WAN1 is 100K, and 50K on WAN2 and WAN3. During the idle period, the maximum bandwidth limited for internet users to download data from a virture FTP server 192.168.0.100 in LAN is 512K on WAN1, WAN2 and WAN3. The guaranteed bandwidth is on WAN1, WAN2 and WAN3 is zero. Note: When configuring filters on virtual servers, specify the private IP assigned to the virtual server and not the translated public IP.

During the busy period, the maximum bandwidth limited for hosts in a remote subnet 10.10.10.0/24 to download data from FTP server 211.21.48.198 in DMZ is 128K on WAN1 and WAN2 and 256K on WAN3. During the idle period, the maximum bandwidth limited for hosts in a remote subnet 10.10.10.0/24 to download data from FTP server 211.21.48.198 in DMZ is 256K on WAN1 and WAN2, and 512K on WAN3. The guaranteed bandwidth is zero on WAN1, WAN2 and WAN3, and the bandwidth is prioritized as “Low” during both busy and idle periods.

Settings for BM classes above

Name	Link	Busy Hour Settings			Idle Hour Settings
		Guaranteed Max Kbps Kbps		Priority	Guaranteed Max Kbps Kbps		Priority
Mail Server	WAN1	0	128	Normal	0	512	Normal
	WAN2	0	128	Normal	0	512	Normal
	WAN3	0	64	Normal	0	512	Normal
For LAN Zone	WAN1	0	128	Low	0	128	Low
	WAN2	0	128	Low	0	128	Low
	WAN3	0	256	Low	0	512	Low
For 192.168.0.100	WAN1	100	200	Normal	0	512	Normal
	WAN2	50	100	Normal	0	512	Normal
	WAN3	50	100	Normal	0	512	Normal
FTP Server	WAN1	0	128	Low	0	256	Low
	WAN2	0	128	Low	0	256	Low
	WAN3	0	256	Low	0	512	Low

Filter Settings

Source	Destination	Service	Classes
211.21.48.198	WAN	FTP(21	FTP Server
211.21.48.197	WAN	POP(110)	Mail Server (POP3)

 

Connection Limit

Source	Destination	Service	Classes
192.168.0.100	WAN	FTP(21)	For 192.168.0.100
211.21.48.198	10.10.10.0/255.255.255.0	Any	For 10.10.10.0

Two possible scenarios for upstream data: e.g. FTP (scenario 1), is that local host uploads data from a remote

FTP server in the WAN. The other scenario is a remote user in WAN downloads data from a FTP server in the LAN. Both of these scenarios are sending data from LAN to WAN. Thus configuring BM rules for these two scenarios on the inbound BM page is necessary.

See also:

• Busyhour Settings l Using the web UI l Log
• Statistics: Bandwidth l Report: Bandwidth Usage

Inbound BM and Outbound BM

Bandwidth Management is divided into inbound BM and outbound BM, which are used to control the inbound traffic and outbound traffic respectively on each WAN port. Packets (network streams) that are transferred inward (from WAN to LAN, DMZ or localhost) on a WAN port are counted to inbound traffic; packets that are transferred outward (from LAN, DMZ or localhost to WAN) on a WAN port are counted to outbound traffic. Therefor, both inbound BM and outbound BM are required if you would like to control a connection in the two ways (Bandwidth Management ignores the direction of a connection, the initiator of the connection). BM policy consists of BM classes and filters. A BM class defines the bandwidth to allocate applications on each WAN port, while a BM filter defines the associated application by source, destination and service of the packets. According to the associated inbound/outbound classes, bandwidth is allocated to the inbound/outbound traffic that is defined in an inbound/outbound filter.

Inbound & Outbound Classes

An inbound/outbound class defines how to allocate bandwidth to the specified traffic. Specified traffic associated with the class can be controlled according to the WAN link it passes through and the time it is generated, and bandwidth is allocated according to settings of Guarantee, Max and Priority.

Enable BM		Tick the check box to enable Bandwidth Management.
Name		Assign a name to bandwidth class. Better use simple names to avoid confusion, e.g. “HTTP” to manage the bandwidth of HTTP service.
Link		The WAN link number which bandwidth limitation will be applied to. Traffic of specified applications (defined in inbound and outbound filters) passing through the WAN link will be shaped according to the bandwidth limitation below.
Busy Hour Settings Idle Hour Settings			This is the bandwidth allocation on a WAN link during defined busy hour (see System > Busyhour Settings for more details, “Busyhour Settings”). Associated traffic passing through the WAN link during the time period will be shaped according to the following settings.
	Guaranteed Kbps		The guaranteed bandwidth for this class. This secures bandwidth allocated as defined for WAN link in peak hours. This is significant to guarantee the service quality especially for critical applications like VoIP.
	Max Kbps		The maximum bandwidth for WAN link. Maximum bandwidth is often allocated to services like WWW and SMTP that consume large bandwidth. Note that traffic of the WAN link would be blocked if value of the field is zero.
	Priority		The priority of the connections on the WAN link. It can be High, Normal, or Low. The connections with higher priority will first be allocated bandwidth.
			This is the bandwidth allocation on a WAN link during defined idle hour (see System > Busyhour Settings for more details, “Busyhour Settings”). Associated traffic passing through the WAN link during the time period will be shaped according to the following settings.
	Guaranteed Kbps		The guaranteed bandwidth for this class. This secures bandwidth allocated as defined for WAN link in peak hours. This is significant to guarantee the service quality especially for critical applications like VoIP.
	Max Kbps		The maximum bandwidth for WAN link. Maximum bandwidth is often allocated to services like WWW and SMTP that consume large bandwidth. Note that traffic of the WAN link would be blocked if value of the field is zero.
	Priority		The priority of the connections on the WAN link. It can be High, Normal, or Low. The connections with higher priority will first be allocated bandwidth.

Inbound & Outbound IPv4/IPv6 Filter

A filter is used to evaluate the traffic passing through FortiWAN by its source, destination and service. Traffic matches the filter will be associated to the corresponding BM class, so that the traffic is shaped according to the bandwidth allocation of the class. The source and destination here mean the actual initiator and terminator of the inbound/outbound traffic, no matter whether the traffic is processed by NAT or Virtual Server.

E	Check the box to enable the rule.
Input Port		Select a interface that packets are received on for this filter term to evaluate the outbound traffic, or leave it as Any Port. See Using the web UI for details. This field is only available for Outbound IPv4/IPv6 filters.
Source		The source used to evaluate traffic (original packets) by where it comes from (See “Using the web UI”).
Destination		The destination used to evaluate traffic (original packets) by where it goes to (See “Using the web UI”).
Service		The service used to evaluate traffic (original packets) by what the source port and destination port they are. Service matches as long as source port or destination port matches (See “Using the web UI”). The options GRE and ESP in the Service drop-down menu is for the GRE and ESP packets coming from other VPN devices. GRE and ESP packets generated by FortiWAN are invisible to Bandwidth Management filters.
Classes		The BM class that traffic matching the filter (Source, Destination and Service) is associated with.
L		Check to enable logging: Whenever the rule is matched, system will record the event to log file.

Bandwidth Management

Bandwidth Management (BM) allocates bandwidth to applications. To secure the bandwidth of critical applications, FortiWAN Bandwidth Management (BM) defines inbound and outbound bandwidth based on traffic direction, i.e. take FortiWAN as the center, traffic flows from WAN to LAN is inbound traffic, otherwise, it is outbound traffic. No matter which direction a connection is established in, a connection must contain inbound traffic and outbound traffic. The section will mainly explain how to guarantee bandwidth based on priority settings, and how to manage inbound and outbound traffic by configuring busy/idle hours, data source/destination, and service type, etc.

Bandwidth Management consists of Classes and Filters (IPv4/IPv6). Click “Expand Link Settings” or “Collapse Link Settings” to show or hide configuration details of links and bandwidth limit.

FortiWAN provides mechanisms to record, notify and analysis on events refer to the Bandwidth Management service, see “Log”, “Statistics: Bandwidth” and “Report: Bandwidth Usage”.

Persistent Routing

Persistent routing is used to secure subsequent connections of source and destination pairs that are first determined by Auto-Routing in FortiWAN. It is useful for applications require secure connection between the server and client whereby client connection will be dropped if server detects different source IP addresses for the same client during an authenticated and certified session. PR ensures that the source IP address remains unchanged in the same session.

Timeout: For every session (pair of source and destination), if there is no packets occured during the timeout period, records of persistent route of the session will be cleared. That means the next coming connection of the session will be routed by the auto-routing rules first.

FortiWAN provides mechanisms to record, notify and analysis on events refer to the Persistent Routing service, see “Log” and “Statistics: Persistent Routing”.

IPv4/IPv6 Web Service Rules

Sets persistent routing rules on Web services. Enable this function, and all the http and https connections established from source IP specified below to destination port 80 and port 443 are governed by Web Service Rules.

E	:	Check the box to enable the rule.
When	:	Options: Busy hour, Idle hour, and All-Time (See “Busyhour Settings”).
Source	:	Established connections from the specified source will be matched (See “Using the web UI”).
Action	:	Do PR: the matched connections will be routed persistently. No PR: the matched connections will NOT be routed persistently. (The Default)
L	:	Check to enable logging: Whenever the rule is matched, system will record the event to log file.

IPv4/IPv6 IP Pair Rules

Sets persistent routing rules on IPv4/IPv6 addresses. Enable this function, and all connections established from the source IPv4/IPv6 to destination IPv4/IPv6 specified below are governed by IPv4/IPv6 IP Pair Rules.

E    :   Check the box to enable the rule.

When    :   Options: Busy hour, Idle hour, and All-Time (See “Busyhour Settings”).

Source    :  Established connections from the specified source will be matched (See “Using the web UI”).

Persistent Routing

Destination	:	The connections to the specified destination will be matched. This field is the same as the “Source” field, except it matches packets with the specified destination (See “Using the web UI”).
Action	:	Do PR: the matched connections will be routed persistently. (The Default) No PR: the matched connections will NOT be routed persistently.
L	:	Check to enable logging: Whenever the rule is matched, system will record the event to log file.

Persistent routing is often used when destination servers check source IP. The function is performed on most secure connections (e.g. HTTPS and SSH). To prevent the connections from being dispatched over a diverse range of WAN links, persistent routing serves the best solution for maintaining connections over a fixed WAN link.

See below for how auto-routing is related to persistent-routing:

Once a connection is established, auto-routing rules are applied to determine the WAN link to be used.

Subsequent connections with the same destination and source pair obey the rules formulated in the persistent routing table. Note that the device will consult the rule table whenever established connections are to be sent to new destinations.

Auto-routing will be reactivated once in persistent routing the interval between two successive connections are longer than timeout period. A second connection will be considered as a “new” one. Then auto-routing will secure the connection to go through a different WAN link.

Example 1

The persistent routing policies to be established accordingly:

• In LAN, established connections from IP address 192.168.0.100 to 192.168.10.100 are NOT to be routed persistently. l Established connections from DMZ to LAN are NOT to be routed persistently.
• Established connections from LAN to the host IP ranging from 10.10.1.1 ~ 10.10.1.10 are NOT to be routed persistently. l Since the default action by IP Pair rules is Do PR, if no rule is added, all connections will use persistent routing.

Then persistent routing table will look like:

Source	Destination	Action
192.168.0.100	192.192.10.100	No PR
DMZ	WAN	No PR
LAN	10.10.1.1-10.10.1.10	No PR

Example 2

The persistent routing policies to be established accordingly:

HTTP and HTTPs connections from the subnet 192.168.0.0/24 in LAN use persistent routing.

HTTP and HTTPs connections from WAN use persistent routing.

Persistent Routing

As there is no default action set by Web Service Rules, if no rule is added, all connections will be based on IP Pair Rules to determine whether to use persistent routing.

The persistent routing table should look like:

Source	Action
192.168.0.0/255.255.255.0	Do PR
WAN	Do PR

Example 3

The persistent routing policies to be established accordingly:

HTTP and HTTPs connections from LAN hosts with IP range 192.168.0.10~192.168.0.20 use persistent routing, but this does not apply to other services except IP address 192.168.0.15.

HTTP and HTTPs connections from subnet 192.168.10.0/24 to 192.192.10.100 use persistent routing. But this does not apply to other connections.

Connections from IP address 211.21.48.196 in DMZ to the WAN subnet 10.10.1.0/24 in WAN do NOT use persistent routing.

Since the default action by IP Pair Ruels is Do PR, if no rule is added, all connections will use persistent routing.

Then persistent routing table will look like:

Source	Action
192.168.0.10-192.168.0.20	Do PR
192.168.10.0/255.255.255.0	Do PR
Source	Destination		Action
192.168.0.15	WAN		Do PR
192.168.0.10-192.168.0.20	WAN		No PR
192.168.10.0/255.255.255.0	ANY		No PR
211.21.48.196	10.10.1.0/255.255.255.0		No PR

Note: Rules are matched top down. Once one rule is matched, the rest will be ignored. In this case, the connections from 192.168.0.15 may meet the criteria of the first and second IP Pair rules, only the first rule will be applied. Hence the rules will not perform NoPR on 192.168.0.15 even though it matches the second rule.It shall be noted that Web Service Rules are prioritized over IP Pair Rules. As 192.168.10.0/255.255.255.0 is configured to be NoPR in IP Pair Rules, but DoPR in Web Service Rules, HTTP connections will still apply persistent routing.