Reports

Reports is the built-in monitoring and traffic pattern analysis tool for instant status of WAN connections and traffic statistics analysis. MIS personnel can perform offline and more detailed analysis of the data to gain insight into user traffic patterns for better network design and management policy definition. However, FortiWAN generates large volumes of raw activity logs during the process of monitoring its functions. For long-term or trend analysis, Reports is an online companion tool that greatly simplifies the analysis of the data. Reports Features l Provides historical detail and reporting over longer periods of time (See “Create a Report”).

l Provides more fine-grained subcategories of analysis and reports (See “Advanced Functions of Reports: Drill in”). l Provides customized filters on reports (See “Advanced Functions of Reports: Custom Filter”). l Provides instant email of reports in PDF formats (See “Advanced Functions of Reports: Report Email”). l Reports can be saved in PDF format (See “Advanced Functions of Reports: Export”). l Supports user-select report date range (See “Create a Report”). l Supports user-specified backup of original log and database data (See “Reports Database Tool”).

Reports provides analysis and reporting capabilities on device status, top bandwidth utilization and function status. MIS personnel can gain complete understanding of the detailed network statistics via the various reports. Such statistics include, for example, the exact time of failure of every WAN link, the peak rate and amount of bandwidth of every WAN link, the minimum and maximum traffic volume for a given specified day range, the traffic volume and service conditions of a certain server during a specified day range. Bandwidth Usage presents the analysis of how the bandwidth of every WAN link is used: what connections are constructed between which internal IP and external IP hosts, what services operate on the connections, and what and how much traffic is transferred through which WAN link? For example, you can obtain, from Reports analysis, the external traffic destinations from any or all devices inside the LAN or look at what internet servers attracted the most traffic from your enterprise.

It is important to have a solid grasp of the functionality and operational theory of Reports in order to effectively analyze network traffic patterns and various statistics of FortiWAN for optimal management policy definition.

Reports reporting function is calendar-based (in the upper right portion of the UI screen). Reporting can be done for a specific day, by highlighting that date in the calendar. Reporting can be done over a range of dates by specifying the start date and the end date on the Calendar.

Reports reporting function is divided into three categories and eighteen subcategories:

• Device Status: Dashboard, Bandwidth, CPU, Session, WAN Traffic, WAN Reliability, WAN Status, TR Reliability and TR Status (See “Device Status”).
• Bandwidth Usage: In Class, Out Class, WAN, Service, Internal IP and Traffic Rate (See “Bandwidth Usage”). l Function Status: Connection Limit, Firewall, Virtual Server and Multihoming (See “Function Status”).

To make those data and analysis available, please enable Reports via Log > Reports (See “Enable Reports“) or Reports > Settings > Reports (See “Settings > Reports“).

Create a Report

Enable Reports

FortiWAN’s Reports provides long-term and advanced data analysis by processing system logs to database. The original logs FortiWAN generates contains raw data which is yet to be processed, and Reports can organize and analyze these data into readable statistics.

Every FortiWAN unit embeds the Reports system (See “Reports”), or the Reports could be also a stand-alone system running on a computer. Here is the settings to specify the ways of log push for Reports servers.

Embedded Reports

Enable Reports DB         :      Enable the embedded Reports (See “Reports”). Logs will be processed directly to the database stored in the built-in hard disk. Analysis and statistics are displayed via Web UI.

The Reports displays no data without enabling this.

Stand-alone Reports

Enable Reports UDP    :   Enable it to push logs to specified stand-alone Reports server.

Recipient IP Address : Specify location of the stand-alone Reports server that logs are pushed to. This field is available only if Enable Reports UDP is checked.

The stand-alone Reports displays no data without enabling this.

A stand-alone Reports and the embedded Reports can run at the same time, but both servers use the same logs.

Events

Select the log type for FortiWAN to send to Reports.

l Firewall l Virtual Server l Bandwidth Usage l Connection Limit l Multihoming l Tunnel Routing

Selected logs here will be pushed to embedded Reports and stand-alone Reports, if any or both of them are enabled.

 

Enable Reports

Notification

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

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

Notification

E-Mail Settings

The table below summarizes the event notification mail setup:

SMTP Server	SMTP Server
SMTP Port	Specify the port (465 by default) that the SSL encrypted SMTP is using if the SSL check box is checked. FortiWAN uses fixed port:25 for non-encrypted SMTP. This field becomes ineffective if the SSL is unchecked.
SSL	Check to enable SMTP transfers over SSL.
Account	Authenticated account for the mail server
Password	Authenticated password for the mail server
Mail From	Sender
Mail To	Receiver(s). Separate receivers with “,” or “.”.
Send Test E-mail Now	Click the button to run test for the email settings above.

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

SNMP Trap Settings

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

Destination IP	The SNMP managing device IP
Community Name	Community name

Notification

Types of Events to Notify

Event Types to Notify	Check to select the events. Enter the threshold to number of connections, rate of connections and total WAN traffic to trigger the notification.
	WAN link failure and recovery	Send notification when a WAN link fails or recovers from failure. A integer used to indicate the failed or recovered WAN link.
	Account change	Send notification when an account is added, removed or password-changed.
	HA slave failure and recovery	Send notification when the slave unit in HA deployment fails or recovers from failure. Integer 1 indicates the slave unit recovered and integer 2 indicates it failed.
	HA takeover	Send notification when the local unit in HA deployment was took over by its slave unit. Integer 1 indicates the truth of HA takeover and integer 2 indicates the falseness of HA takeover.
	VRRP takeover	Send notification when the local unit in VRRP deployment was took over by its backup unit. Integer 1 indicates the truth of VRRP takeover and integer 2 indicates the falseness of VRRP takeover.
	Number of connections reaches ___	Set the threshold and the number of connections being processed in system will be sent as an event notification when it exceeds the threshold.
	Rate of connections reaches___ / sec	Set the threshold and the number of connections established in system every second will be sent as an event notification when it exceeds the threshold.
	Total WAN traffic reaches ___ Kbps	Set the threshold and the number of current total WAN traffic (sum of inbound and outbound traffic of every WAN link) will be sent as an event notification when it exceeds the threshold.
Select All    Click to check all the event types
Clear All     Click to uncheck all the event types

Enable Reports

Log Control

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

Log Type	:	Select log type to be forwarded to servers. l  System Log l Firewall Log l NAT Log l  Auto & Persistent Routing Log l Virtual Server Log l BM Log (Bandwidth Management) l Connection Limit Log l Cache Redirect Log l Multihoming Log l Backup Line Log l Dynamic IP Log l IP-MAC Mapping Log l Tunnel Routing Log l IPSec
Copy Settings to All Other Log Types	:	Copy and apply settings of a log type to other ones.
Method	:	E-Mail, FTP and Syslog
Push Now	:	Click this button and logs are pushed immediately.
Push Log When Out of Space	:	Check Enable to avoid losing data in case of space shortage.

Notification

Enable Scheduled Push    :   Check to enable pushing schedule.

Initial Time    :   Start time for scheduled push.

Period    :    Duration for scheduled push.

Methods

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

FTP

Server	:	FTP Server’s IP or domain name
Account	:	FTP user account
Password	:	FTP user password
Path E-Mail	:	FTP server path
SMTP Server	:	SMTP server for logging
Account	:	Authenticated account for mail server
Password	:	Authenticated password for mail server
Mail From	:	Sender
Mail To Syslog	:	Receiver(s). Separate receivers with “,” or “.”.
Server	:	IP address of remote syslog server.
Facility	:	Assign a facility to the logging message to specify the program type.

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

Log format

A log listed here consists of three parts:

{TIMESTAMP} {LOG_TYPE} {LOG_CONTENT}

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

Notation Conventions

{ADDRPORT} follows TCPDUMP format, for example:

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

Firewall

FW {IP‐5‐TUPLE} ACTION=[ACCEPT|DENY] TOTLEN=<pktlen>

The first packet of session {IP‐5‐TUPLE} matching a Firewall rule triggers the log. System generates only one log for this session. This log indicates all the packets of the session {IP‐5‐TUPLE} are accepted or denied by Firewall, and the first packet size is <pktlen>. In reality, the event ACCEPT will not be logged by system.

See “Firewall” for further information.

NAT

NAT {IP‐5‐TUPLE} NEW_SRC={ADDR}

The first packet of session {IP‐5‐TUPLE} matching a NAT rule triggers the log. System generates only one log for this session. This log indicates source addresses of the packets of {IP‐5‐TUPLE} are translated to the new address {ADDR} by NAT.

See “NAT” for further information.

Auto & Persistent Routing

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

The first packet of session {IP‐5‐TUPLE} matching a Auto Routing rule triggers the log. System generates only one log for this session. This log indicates packets of the session {IP‐5‐TUPLE} are transferred outward through WAN link <widx>, or all the WAN links defined in the routing and fail-over policies fail to transfer the packets (AR=NONE). The first packet size of the session is <pktlen>. See “Auto Routing” for further information.

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

The first packet of session {IP‐5‐TUPLE} matching a Persistent Routing rule triggers the log. System generates only one log for this session. This log indicates packets of the session {IP‐5‐TUPLE} are transferred outward through WAN link <widx> (the persistence entry of the session is not expired), or Auto Routing determines the WAN link for the session (PR=WAIT_AR, the persistence entry of the session is expired or absent), or the action to this session is No PR (PR=NONE). The first packet size of the session is <pktlen>. See “Persistent Routing” for further information. If a PR log that PR=WAIT_AR, the PR log and a correspondent AR log are generated in pairs.

Virtual Server

VS {IP‐5‐TUPLE} NEW_DST={ADDR} TOTLEN=<pktlen>

The first packet of session {IP‐5‐TUPLE} matching a Virtual Server rule triggers the log. System generates only one log for this session. This log indicates destination addresses of the packets of {IP‐5‐TUPLE} are translated to the new address {ADDR} by Virtual Server. The first packet size of the session is <pktlen>.

See “Virtual Server” for further information.

BM

BM {IP‐5‐TUPLE} INPKTS=<%lu> INBYTES=<%lu> OUTPKTS=<%lu> OUTBYTES=<%lu> TOTALPKTS=<%lu> TOTALBYTES=<%lu> DURATION=<%lu>SECS

Session {IP‐5‐TUPLE} matching a Bandwidth Management filter triggers the log when it is closed. System generates only one log for this session. This log indicates the traffic statistics (INPKTS, INBYTES, OUTPKTS, OUTBYTES, TOTALPKTS, TOTALBYTES and DURATION) of the session {IP‐5‐TUPLE}.

See “Bandwidth Management” for further information.

Connection Limit

Count Limit

CL SRC=<ip> DROP=<pkt_number>

This log is triggered every time-period if the number of connections generated by a source SRC=<ip> exceeds the limitation defined in Connection Limit > Count Limit. This log indicates connections generated by SRC=<ip> and passing through FortiWAN are more that the limitation, and there are <pkt_number> packets are dropped for the reason.

Rate Limit

RL RULE=<ridx> DROP=<pkt_number>

This log is triggered every time-period if a rule <ridx> of Connection Limit > Rate Limit is matched. This log indicates connections defined in the Rate Limit rule <ridx> are generated in a rate higher than the limitation, and there are <pkt_number> packets are dropped for the reason.

See “Connection Limit” for further information.

Cache Redirect

CR {IP‐5‐TUPLE} NEW_DST={ADDR‐PORT}

The first packet of session {IP‐5‐TUPLE} matching a Cache Redirect rule triggers the log. System generates only one log for this session. This log indicates destination addresses and ports of the packets of {IP‐5‐TUPLE} are translated to {ADDR} by Virtual Server. The first packet size of the session is <pktlen>.

See “Cache Redirect” for further information.

Multihoming

MH FROM=<ip> TYPE=<A|AAAA> WLINK=<widx> REPLY=<ip>

An DNS response (queried for A or AAAA records) by Multihoming triggers the log. System generates the log only for DNS queries for A and AAAA records. This log indicates a DNS query whose type is TYPE=<A|AAAA> and comes from FROM=<ip> is responded by Multihoming with REPLY=<ip>, which is the IP address of WAN link <widx>. System generates two logs for A and AAAA records if the DNS query type is ANY.

See “Multihoming” for further information.

Dynamic IP

DHCP

DHCP WLINK=<widx> ACTION=<init|renew|rebind|expired|failed|release|stop|bind> [IP=<ip>]

System triggers the log when a DHCP WAN link <widx> is acted for ACTION. ACTION=bind and IP=<ip> must be generated in pairs for a log.

PPPoE

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

System triggers the log when a PPPoE WAN link <widx> is acted for ACTION. ACTION=bind and IP=<ip> must be generated in pairs for a log. Three more logs are introduced when a PPPoE WAN link goes to failure: l PPPOE config‐requests timeout l PPPOE connection no response l PPPOE authentication failed

IP-MAC Mapping

MAC {IP‐5‐TUPLE} BAD_SRC_MAC=<MAC>

The first packet of session {IP‐5‐TUPLE} blocked by IP-MAC Mapping triggers the log. System generates only one log for this session. This log indicates source MAC addresses <MAC> of the packets of {IP‐5‐TUPLE} and the MAC address defined in IP-MAC table are mismatched, and so that the packets are blocked.

MAC {IP‐5‐TUPLE} BAD_DST_MAC=<MAC>

The first packet of session {IP‐5‐TUPLE} blocked by IP-MAC Mapping triggers the log. System generates only one log for this session. This log indicates destination MAC addresses <MAC> of the packets of {IP‐5‐TUPLE} and the MAC address defined in IP-MAC table are mismatched, and so that the packets are blocked.

See “IP-MAC Mapping” for further information.

Tunnel Routing

TR {IP‐5‐TUPLE} GROUP=<group name> TOTLEN=<pktlen>

The first packet of session {IP‐5‐TUPLE} being transferred by Tunnel Routing triggers the log. System generates only one log for this session. This log indicates packets of {IP‐5‐TUPLE} are transferred through the Tunnel Group <group name>, and the first packet size of the session is <pktlen>.

TUN FROM=<ip> TO=<ip> ACTION=<start|stop|fail|recover>

This log is triggered when a single GRE tunnel FROM=<ip> TO=<ip> is acted for actions ACTION.

See “Tunnel Routing” for further information.

IPSec

ISAKMP-SA <established|expired|deleted> <LOCAL_IP_PORT>-<REMOTE_IP_PORT>

An ISAKMP SA between <LOCAL_IP_PORT> and <REMOTE_IP_PORT> is established, expired or deleted.

IPsec-SA <established|expired>: ESP/<Transport|Tunnel> <LOCAL_IP_PORT>-><REMOTE_ IP_PORT>

 

A Transport mode or Tunnel mode IPSec SA between <LOCAL_IP_PORT> and <REMOTE_IP_PORT> is established or expired.

<initiate|respond> new phase <1|2> negotiation: <LOCAL_IP_PORT><=><REMOTE_IP_ PORT>

After an ISAKMP SA or IPSec SA is expired, new IKE phase 1 or 2 negotiation between <LOCAL_IP_PORT> and <REMOTE_IP_PORT> is initiated or responded.

NOTIFY: the packet is retransmitted by <IP_PORT>

Packets of IKE negotiation are retransmitted due to the failure in authentication (pre-shared keys of the two entities might not be correspondent with each other).

<IP> INFO: request for establishing IPsec-SA was queued due to no phase1 found.

Request for establishing IPSec SA from <IP> was queued due to the failure in phase 1 negotiation (Phase 1 proposals of the two entities might not be correspondent with each other).

<IP> INFO: received INITIAL-CONTACT

<IP> received the request for negotiation from the peer.

ERROR: phase1 negotiation failed due to time up.

A queued or retransmitted phase 1 negotiation is declared to failure because the time is up.

<IP> ERROR: notification NO-PROPOSAL-CHOSEN received in informational exchange.

<IP> does not receive any proposal in the phase 2 negotiation messages (Phase 2 proposals of the two entities might not be correspondent with each other).

See “IPSec VPN” for further information.

System Admin session

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

Monitor account <account> password successfully changed

Monitor account <account> successfully added

Access deny

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

UI setting

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

Config

System configuration restored

Multihoming daemon file write error

Shutdown

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

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

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

No heartbeat detected. Enter the Master state.

 

Log Control

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

View

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

Log Type	:	Choose log type to view its events in display window. The log types are:
		l	System Log
		l	Firewall Log
		l	NAT Log
		l	Auto & Persistent Routing Log
		l	Virtual Server Log
		l	BM Log
		l	Connection Limit Log
		l	Cache Redirect Log
		l	Multihoming Log
		l	Backup Line Log
		l	Dynamic IP Log
		l	IP-MAC Mapping Log
		l	Tunnel Routing Log
		l	IPSec Log
Recent Event	:	Log events listed in time order.
Refresh	:	Refresh to get the latest log events.
Clear	:	Clean up log records.

Log

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

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

Traffic Statistics for Tunnel Routing and IPSec

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

Traffic Statistics for Tunnel Routing and IPSec

BM logs

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

Statistics on Web UI

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

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

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

FortiWAN Reports

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

Here are a summary of discussion above.

Traffic transferred through IPSec Tunnel mode

	Original traffic	ESP encapsulated traffic
BM Control	O	X
BM log	O	X
Reports	O	X

Traffic transferred through Tunnel Routing or IPSec Transport mode

Traffic Statistics for Tunnel Routing and IPSec

	Original traffic	GRE encapsulated traffic	ESP encapsulated traffic
BM Control	O	X	X
BM log	O	X	X
Reports	X	O	X

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

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

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

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

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

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

• Total = 200MB

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

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

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