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.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

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.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

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

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

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.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

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

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

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.

 

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

NAT Rules

As the previous description, FortiWAN provides typical NAT for out-going session (established from internal host to external host). Here we describe the NAT rules which specified how to translate source IP address of a outgoing packet into specified IP address of the WAN link. Incoming packets from a external host can be accepted and forwarded to the correct internal host only if a out-going packet has already be translated and transferred to the same external host. NAT rules are separated into IPv4 NAT rules and IPv6 NAT rules, which are used to translate a IPv4 address to another IPv4 address and translate a IPv6 address to another IPv6 address respectively. You will see the default rules at the bottom of the two rule tables, if IPv4 and/or IPv6 addresses are deployed on localhost of the WAN link.

IPv4 NAT Rules

Customized rules for IPv4-to-IPv4 NAT on a specified WAN link (select from the drop-down menu WAN above).

E	Enable the NAT rule or not.
When	The predefined time periods during which the rules will apply. Options are Busy, Idle, All-Times (See “Busyhour Settings”).
Source	The packets sent from the source will be matched. Note: The source IPv4 to be translated must be the IPv4 address assigned to the LAN or DMZ (See “Using the web UI”).
Destination	The packets sent to the destination will be matched (See “Using the web UI”).
Service	The packets with the service port number to which users would like NAT to apply. It can be the TCP/UDP port, or Predefined service groups from [System]->[Service Grouping] (See “Using the web UI”).
Translated	Specify manually the IPv4 address or a range of IPv4 addresses that is assigned to the localhost of the specified WAN link. Source IP address of the packets that match the rule would be translated to the IP address specified here. The first IPv4 address assigned to the localhost of the WAN link automatically displays in the drop-down menu for options. If multiple IPv4 addresses are assigned to the WAN link’s localhost, you can set any of them manually by selecting the options “IPv4 Address” and “IPv4 Range”. Select No NAT if no translation is needed. The option [Dynamic IP] will be available while a Dynamic WAN link (Bridge Mode: PPPoE and Bridge Mode: DHCP) is applied.
L	Check to enable logging. Whenever the rule is matched, the system will record the event to the log file.

IPv6 NAT Rules

Customized rules for IPv6-to-IPv6 NAT on a specified WAN link (select from the drop-down menu WAN above).

E	Enable the NAT rule or not.
When	The predefined time periods during which the rules will apply. Options are Busy, Idle, All-Times (See “Busyhour Settings”).
Source	The packets sent from the source will be matched (See “Using the web UI”). Note: The source IPv6 to be translated must be the IPv6 address assigned to the LAN or DMZ.
Destination	The packets sent to the destination will be matched (See “Using the web UI”).
Service		The packets with the service port number to which users would like NAT to apply. It can be the TCP/UDP port, or Predefined service groups from [System]->[Service Grouping] (See “Using the web UI”).
Translated		Specify manually the IPv6 address or a range of IPv6 addresses that is assigned to the localhost of the specified WAN link. Source IP address of the packets that match the rule would be translated to the IP address specified here. The first IPv6 address assigned to the localhost of the WAN link automatically displays in the drop-down menu for options. If multiple IPv6 addresses are assigned to the WAN link’s localhost, you can set any of them manually by selecting the options “IPv6 Address” and “IPv6 Range”. Select No NAT if no translation is needed. The option [Dynamic IP] will be available while a Dynamic WAN link (Bridge Mode: PPPoE) is applied. Bridge Mode: DHCP does not support IPv6/IPv4 dual stack. Note that this field must be an IPv6 address obtained upon public DMZ subnet and with 64-bit or lower prefix length.
L		Check to enable logging. Whenever the rule is matched, the system will record the event to the log file.

1-to-1 NAT Rules

1-to-1 NAT maintains a fixed 1-to-1 mapping (binding) between internal IP addresses and the IP addresses of a WAN link’s localhost (also called external addresses here), which requires the same amount of IP addresses on both sides. Therefore, both a internal host and external host can launch sessions to each other. 1-to-1 NAT supports translation for IPv4 only.

E	Enable the 1-to-1 NAT rule or not.
When	Select the time when to apply the 1-to-1 NAT rule, including three options: Busy, Idle and All-Time (See “Busyhour Settings”).
Internal Address	Select the internal IPv4 address, IPv4 range or IPv4 subnet that the 1-to-1 NAT rule should be applied to (See “Using the web UI”). For a 1-to-1 NAT rule, the amount of internal IP address here must be the same as amount of external IP address below. (Note: Internal IP Address must be an IP address of the internal network or DMZ port.)
Service	Select a service port where the 1-to-1 NAT rule should be applied to, such as TCP, UDP, ICMP or any of the predefined network service groups (See “Using the web UI”).
External Address	Select the external IPv4 address, IPv4 range or IPv4 subnet that the 1-to-1 NAT rule should be applied to (See “Using the web UI”). For a 1-to-1 NAT rule, the amount of external IP address here must be the same as amount of internal IP address above. (Note: External IP Address must be an IP address obtained upon WAN link connection.)
L	Check to enable logging. Whenever the rule is matched, the system will record the event to the log file.

For any out-going packet (no matter a internal or a external host launch the session), if the packet matches a 1-to1 NAT rule on When, Internal Address (Source) and Service, source IP address of the packet will be translate to correspondent external address specified in the rule. For any in-coming packet (no matter a internal or a external host launch the session), if the packet matches a 1-to-1 NAT rule on When, External Address (Destination) and Service, destination IP address of the packet will be translate to correspondent internal address specified in the rule.

Enable NAT

Example: To translate packets from local machine 192.168.123.100 to public IP address 172.31.5.51, check “Enable NAT”, and select WAN #1, then check “Enable”. The NAT rule settings look like:

Source	Destination	Service	Translated
192.168.123.100	Any Address	Any	172.31.5.51

Disable NAT

Disable NAT sets FortiWAN to Non-NAT mode whereby all the WAN hosts can acccess DMZ hosts directly with proper routing setup. In this mode, FortiWAN acts as a router connecting multiple subnets.

Note: Once NAT is disabled, it is disabled on all the WAN Links.

Example: Non-NAT Settings

 

Persistent Routing

Non-NAT is commonly used on Private Network and MPLS network, which makes possible for the hosts of the branch office to directly access the headquarters. In case that ISP 1 is down, FortiWAN will automatically route the link to ISP 2, and, accordingly, serve as VPN load balancer based on the status of each link.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

NAT

FortiWAN is an edge server that is usually placed on the boundary between WAN and LAN. When a connection is established from a private IP address (in LAN or DMZ) to the internet (WAN), it is necessary to translate the private IP address into one of the public IP addresses assigned to the FortiWAN’s WAN link. This process is called NAT (Network Address Translation). FortiWAN provides the typical NAT (called S-NAT also) for sessions established from internal area. Once the private source IP address of outgoing packet of a session is translated to a public IP address, the mapping is kept in translation table and therefore the inbound traffic (from public area) of the session can be accepted and forwarded to the internal host who established the session.

With the typical NAT, two-way data transmission between an internal host and an external host is achieved, only if the internal host starts the sessions. An external host is unable to starts a session with an internal host via the typical NAT. FortiWAN’s 1-to-1 NAT gives the availability of two-way transmission between an internal host and an external host not only for sessions starting from the internal host but also for sessions starting from the external host.

FortiWAN provides log mechanism to the NAT service, see “Log”.

Default Rules

FortiWAN’s NAT Default Rules are the NAT rules (and IPv6 NAT rules) generated automatically by system according to the Network Setting of WAN links. Once a WAN link is sat up (See “Configuring your WAN”), the default rules are generated at the same time so that FortiWAN performs NAT automatically to packets coming from anywhere (except subnets in WAN or/and DMZ and static routing subnets of the WAN link) and going to be transferred via the WAN link. NAT default rules are varies according to how the WAN link is deployed. For example,

WAN link 1: Routing mode with a basic subnet (125.227.251.0/255.255.255.0) in WAN and DMZ, and the IP(s) on localhost are 128.227.251.80 and 128.227.251.81. System adds the default rules to WAN link 1 as following:

When = All-Time, Source = 125.227.251.0/255.255.255.0, Destination = Any Address, Service = Any, Translated = No NAT

When = All-Time, Source = Any Address, Destination = Any Address, Service = Any, Translated = 128.227.251.80

WAN link 2: Bridge mode: One Static IP, the IP on localhost is 125.227.250.10. System adds the default rules to WAN link 2 as following:

When = All-Time, Source = 125.227.250.10, Destination = Any Address, Service = Any, Translated = No NAT

When = All-Time, Source = Any Address, Destination = Any Address, Service = Any, Translated = 128.227.250.10

WAN link 3: Bridge mode: Multiple Static IP, 125.227.252.100-125.227.252.101 are deployed on localhost, 125.227.252.102-125.227.252.103 are deployed in WAN, 125.227.252.104-125.227.252.105 are deployed in DMZ. System adds the default rules to WAN link 3 as following:

When = All-Time, Source = 125.227.252.100-125.227.252.101, Destination = Any Address, Service = Any, Translated = No NAT

When = All-Time, Source = 125.227.252.104-125.227.252.105, Destination = Any Address, Service = Any, Translated = No NAT

When = All-Time, Source = Any Address, Destination = Any Address, Service = Any, Translated = 128.227.252.100

WAN link 4: Bridge mode: PPPoE, system adds the default rule to WAN link 4 as following:

When = All-Time, Source = Any Address, Destination = Any Address, Service =

Any, Translated = DynamicIP(DHCP/PPPoE)

The last rule translates source IP address of all packets into an IP address (localhost) of the WAN link. The second (or third) rule from the bottom ignores NAT to packets coming from subnets of the WAN link. Those default rules are added as the bottom rules to the top-down rule table. They are unable to be deleted and edited, unless the correspondent deployment of the WAN link changes. The default rules will translate source IP address of a matched packet into the first of the IP addresses that are assigned to localhost of the WAN link, which normally is a public IPv4 address or global IPv6 address. Therefore, packets with private source address (IPv4) or Link-Local source address (IPv6) are acceptable to Internet after the NAT process. However, even a packet comes with public source address (IPv4) or Global source address (IPv6), NAT is also performed if it matches the last rule. NAT default rules are based on deployment of a WAN link, deployment of LAN is regardless. Set NAT rules manually for advanced applications.

Similarly, system generates default rules for IPv6/IPv4 dual stack WAN links. Take the WAN link 1 above as example, if a IPv6 basic subnet 2001::/64 is deployed on WAN link 1 and the localhost is 2001::1, system adds the IPv6 default rules to WAN link 1 as following:

When = All-Time, Source = 2001::/64, Destination = Any Address, Service = Any, Translated = No NAT

When = All-Time, Source = Any Address, Destination = Any Address, Service = Any, Translated = 2001::1

Note that for FortiWAN V4.0.x, system does note generate IPv6 default rules for IPv6/IPv4 dual stack WAN link. It is necessary to add IPv6 default rules manually, or the IPv6 transmission might fail if its source IP address is a Link-Local address. Please refer to the examples above for this.

Non-NAT

Non-NAT is used for Private Network and MPLS Network where the host in WAN can directly access the host in DMZ, and where FortiWAN is used to balance VPN load and backup lines.

FortiWAN’s inbound and outbound load balancing (Auto Routing and Multihoming) distribute session over multiple WAN links. It’s necessary to make sure the correct NAT rules are applied to every enabled WAN link.

Enable NAT	:	Enable the function, and NAT will translate any private IP to a fixed public IP assigned to a given WAN link. Disable the function; FortiWAN will act as a general router for the host in WAN to directly access the host in DMZ.
WAN	:	Enabled WAN links are listed in the menu. Select the WAN link to set and apply NAT rules to.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!