Technical Support Organization Overview

Leave a reply

Technical Support Organization Overview

This section explains how Fortinet’s technical support works, as well as how you can easily create an account to get technical support for when issues arise that you cannot solve yourself.

 

This section contains the following topics:

  • Fortinet Global Customer Services Organization
  • Creating an account
  • Registering a device
  • Reporting problems
  • Assisting technical support
  • Support priority levels
  • Return material authorization process

 

Fortinet Global Customer Services Organization

The Fortinet Global Customer Services Organization is composed of three regional Technical Assistance Centers (TAC):

  • The Americas (AMER)
  • Europe, Middle East, and Africa (EMEA)
  • Asia Pacific (APAC)

The regional TACs are contacted through a global call center. Incoming service requests are then routed to the appropriate TAC. Each regional TAC delivers technical support to the customers in its regions during its hours of operation. These TACs also combine to provide seamless, around-the-clock support for all customers.

 

Fortinet regions and TAC

 

Creating an account

To receive technical support and service updates, Fortinet products in the organization must be registered. The Product Registration Form on the support website will allow the registration to be completed online. Creating an account on the support website is the first step in registering products.

Go to the Fortinet support site shown below:

https://support.fortinet.com/

 

Customer service and support home page

Once the support account has been created, product details can be provided by going to the Product Register/Renew and Manage Product buttons displayed on the home page. Alternately, the product registration can be completed at a later time.

 

Registering a device

Complete the following steps when registering a device for support purposes:

1. Log in using the Username and Password defined when the account was created

2. Under the Asset section, select Register/Renew to go to the Registration Wizard. Alternatively, use the Asset menu at the top of the page.

 

Register/Renew and Manage Products menu

3. Get a serial number from the back of the FortiGate unit or from the exterior of the FortiGate shipping box.

4. Enter the serial number, service contract registration code or license certificate number to start the product registration.

 

Adding a product to a support account

5. Enter your registration information.

6. Read and accept the license agreement.

7. Complete the verification process.

8. Select Finish to complete the registration process.

9. Registration wizard

 

Reporting problems

Problems can be reported to a Fortinet Technical Assistance Center in the following ways:

  • By logging an online ticket
  • By phoning a technical support center

 

Logging online tickets

Problem reporting methods differ depending on the type of customer.

 

Fortinet partners

Fortinet Partners are entitled to priority web-based technical support. This service is designed for partners who provide initial support to their customers and who need to open a support ticket with Fortinet on their behalf. We strongly encourage submission and follow up of support tickets using this service.

The support ticket can be submitted after logging into the partner website using one of the following links using FortiPartner account details:

http://partners.fortinet.com

This link will redirect to the general Fortinet Partner Portal extranet website. Click Support > Online Support Ticket.

https://forticare.fortinet.com/customersupport/Login/CommonLogin.aspx

 

Fortinet customers

There are two methods to report a technical issue on the Fortinet Support website: creating a technical support ticket by product or creating any type of ticket with the Ticket Wizard for more options.

Fortinet customers should complete the following steps to create a support ticket by product:

1. Log in to the support website at the following address with the account credentials used when the account was created: https://supporfortinet.com

2. Navigate to the top menu, click Asset and select Manage/View Products.

3. In the product list, select the product that is causing the problem.

4. On the left side bar, go to the Assistance category, and select Technical Request to create a TA Ticket.

5. Complete the Create TA Ticket fields.

6. Click View Products.

7. In the Products List, select the product that is causing the problem.

8. Complete the Create Support Ticket fields.

9. Select Finish to complete the support ticket.

Fortinet customers who would like to submit a customer service ticket, DOA ticket, RMA ticket, or FortiGuard service ticket should use the Ticket Wizard and complete the following steps:

1. Log in to the support website at the following address with the account credentials used when the account was created: https://supporfortinet.com

2. Navigate to the top menu, click Assistance and select Create a Ticket from the drop down menu.

3. Select a ticket type and complete the remaining steps in the Ticket Wizard.

4. Select Finish to complete the ticket.

 

Following up on online tickets

Perform the following steps to follow up on an existing issue. Partners should log into the following web site: http://partners.fortinet.com

Customers should log into the following site:

http://support.fortinet.com

 

1. Log in with the account credentials used when the account was created.

2. Navigate to the top menu, click Assistance, and select Manage Tickets.

3. Use the search field on the View Tickets page to locate the tickets assigned to the account.

4. Select the appropriate ticket number. Closed tickets cannot be updated. A new ticket must be submitted if it concerns the same problem.

5. Add a New Comment or Attachment.

6. Click Submit when complete.

 

Every web ticket update triggers a notification to the ticket owner, or ticket queue supervisor.

 

Telephoning a technical support center

The Fortinet Technical Assistance Centers can also be contacted by phone. Call Fortinet Support Center at 1-408-486-7899 (international) or go to http://www.fortinet.com/support/contact_support.html and select your country from the drop-down list for local contact number.

 

Assisting technical support

The more information that can be provided to Fortinet technical support, the better they can assist in resolving the issue. Every new support request should contain the following information:

  • A valid contact name, phone number, and email address.
  • A clear and accurate problem description.
  • A detailed network diagram with complete IP address schema.
  • The configuration file, software version, and build number of the Fortinet device.
  • Additional log files such as Antivirus log, Attack log, Event log, Debug log or similar information to include in the ticket as an attachment. If a third-party product is involved, for example, email server, FTP server, router, or switch, please provide the information on its software revision version, configuration, and brand name.

 

Support priority levels

Fortinet technical support assigns the following priority levels to support cases:

 

Priority 1

This Critical priority is assigned to support cases in which:

  • The network or system is down causing customers to experience a total loss of service.
  • There are continuous or frequent instabilities affecting traffic-handling capability on a significant portion of the network.
  • There is a loss of connectivity or isolation to a significant portion of the network.
  • This issue has created a hazard or an emergency.

 

Priority 2

This Major priority is assigned to support cases in which:

  • The network or system event is causing intermittent impact to end customers.
  • There is a loss of redundancy.
  • There is a loss of routine administrative or diagnostic capability.
  • There is an inability to deploy a key feature or function.
  • There is a partial loss of service due to a failed hardware component.

 

Priority 3

This Medium priority is assigned to support cases in which:

  • The network event is causing only limited impact to end customers.
  • Issues seen in a test or pre-production environment exist that would normally cause adverse impact to a production network.
  • The customer is making time sensitive information requests.
  • There is a successful workaround in place for a higher priority issue.

 

Priority 4

This Minor priority is assigned to support cases in which:

  • The customer is making information requests and asking standard questions about the configuration or functionality of equipment.

 

Customers must report Priority 1 and 2 issues by phone directly to the Fortinet EMEA Support Center. For lower priority issues, you may submit an assistance request (ticket) via the web system.

The web ticket system also provides a global overview of all ongoing support requests.

 

Return material authorization process

In some cases hardware issues are experienced and a replacement unit must be sent. This is referred to as a Return Material Authorization (RMA). In these cases or RMAs, the support contract must be moved to the new device. Customers can move the support contract from the failing production unit to the new device through the support web site.

 

To move the support contract to a new device

1. Log in to the support web site with the credentials indicated when the account was created.

2. From Manage Products, locate the serial number of the defective unit from the list of devices displayed for the account. The Product Info for the selected device will be displayed.

3. In the left side bar under the Assistance section, select RMA Transfer.

4. Enter the Original Serial Number of the original device, enter the New Serial Number, and click Replace to complete the transfer.

This will transfer the support contract from the defective unit to the new unit with the serial number provided.

Troubleshooting resources

Leave a reply

Troubleshooting resources

You can always check out the Fortinet GURU Forums @ http://forums.fortinetguru.com.

Before you begin troubleshooting, you need to know Fortinet’s troubleshooting resources. Doing so will shorten the time to solve your issue. Indeed, an administrator can save time and effort during the troubleshooting process by first checking if the issue has been experienced before. Several self-help resources are available to provide valuable information about FortiOS technical issues, including:

 

Technical Documentation

Installation Guides, Administration Guides, Quick Start Guides, and other technical documents are available online at the following URL:

http://docs.fortinet.com

 

Fortinet Video Library

The Fortinet Video Library hosts a collection of video which provide valuable information about Fortinet products.

http://video.fortinet.com

 

Release Notes

Issues that are uncovered after the technical documentation has been published will often be listed in the Release Notes that accompany the device.

 

Knowledge Base

The Fortinet Knowledge Base provides access to a variety of articles, white papers, and other documentation providing technical insight into a range of Fortinet products. The Knowledge Base is available online at the following URL:

http://kb.fortinet.com

 

Fortinet Technical Discussion Forums

An online technical forums allow administrators to contribute to discussions about issues related to their Fortinet products. Searching the forum can help the administrator identify if an issue has been experienced by another user. The support forums can be accessed at the following URL:

http://forum.fortinet.com

 

Fortinet Training Services Online Campus

The Fortinet Training Services Online Campus hosts a collection of tutorials and training materials which can be used to increase knowledge of the Fortinet products.

http://www.fortinet.com/training/

 

Fortinet Customer Support

You have defined your problem, researched a solution, put together a plan to find the solution, and executed that plan. At this point if the problem has not been solved, its time to contact Fortinet Customer Support for assistance.

http://support.fortinet.com

How to debug the packet flow

Leave a reply

How to debug the packet flow

Traffic should come in and leave the FortiGate unit. If you have determined that network traffic is not entering and leaving the FortiGate unit as expected, debug the packet flow.

Debugging can only be performed using CLI commands. Debugging the packet flow requires a number of debug commands to be entered as each one configures part of the debug action, with the final command starting the debug.

If your FortiGate unit has FortiASIC NP4 interface pairs that are offloading traffic, this will change the packet flow. Before performing the debug on any NP4 interfaces, you should disable offloading on those interfaces.

The following configuration assumes that PC1 is connected to the internal interface of the FortiGate unit and has an IP address of 10.11.101.200. PC1 is the host name of the computer.

 

To debug the packet flow in the CLI, enter the following commands:

FGT# diag debug disable

FGT# diag debug flow filter add <PC1> FGT# diag debug flow show console enable

FGT# diag debug flow show function-name enable

FGT# diag debug flow trace start 100

FGT# diag debug enable

 

The start 100 argument in the above list of commands will limit the output to 100 packets from the flow. This is useful for looking at the flow without flooding your log or displaying too much information.

 

To stop all other debug activities, enter the command:

FGT# diag debug flow trace stop

 

The following is an example of debug flow output for traffic that has no matching security policy, and is in turn blocked by the FortiGate unit. The denied message indicates that the traffic was blocked.

id=20085 trace_id=319 func=resolve_ip_tuple_fast line=2825 msg=”vd-root received a packet (proto=6, 192.168.129.136:2854->192.168.96.153:1863) from port3.”

id=20085 trace_id=319 func=resolve_ip_tuple line=2924 msg=”allocate a new session-013004ac”

id=20085 trace_id=319 func=vf_ip4_route_input line=1597 msg=”find a route: gw-192.168.150.129 via port1″

id=20085 trace_id=319 func=fw_forward_handler line=248 msg=” Denied by forward policy check”

How to perform a sniffer trace (CLI and Packet Capture)

8 Replies

How to perform a sniffer trace (CLI and Packet Capture)

When troubleshooting networks and routing in particular, it helps to look inside the headers of packets to determine if they are traveling along the expected route. Packet sniffing can also be called a network tap, packet capture, or logic analyzing.

If your FortiGate unit has NP2/NP4 interfaces that are offloading traffic, this will change the sniffer trace. Before performing a trace on any NP2/NP4 interfaces, you should disable offloading on those interfaces.

 

What can sniffing packets tell you

If you are running a constant traffic application such as ping, packet sniffing can tell you if the traffic is reaching the destination, what the port of entry is on the FortiGate unit, if the ARP resolution is correct, and if the traffic is being sent back to the source as expected.

Sniffing packets can also tell you if the FortiGate unit is silently dropping packets for reasons such as Reverse Path Forwarding (RPF), also called Anti Spoofing, which prevents an IP packet from being forwarded if its Source IP does not either belong to a locally attached subnet (local interface), or be part of the routing between the FortiGate unit and another source (static route, RIP, OSPF, BGP). Note that RPF can be disabled by turning on asymmetric routing in the CLI (config system setting, set asymetric enable), however this will disable stateful inspection on the FortiGate unit and cause many features to be turned off.

If you configure virtual IP addresses on your FortiGate unit, it will use those addresses in preference to the physical IP addresses. You will notice this when you are sniffing packets because all the traffic will be using the virtual IP addresses. This is due to the ARP update that is sent out when the VIP address is configured.

 

How do you sniff packets

The general form of the internal FortiOS packet sniffer command is:

diag sniffer packet <interface_name> <‘filter’> <verbose> <count>

 

To stop the sniffer, type CTRL+C.

<interface_name>                      The name of the interface to sniff, such as “port1” or “internal”. This can also be “any” to sniff all interfaces.

<‘filter’>

What to look for in the information the sniffer reads. “none” indicates no fil- tering, and all packets will be displayed as the other arguments indicate.

The filter must be inside single quotes (‘).

<verbose>                                  The level of verbosity as one of:

1 – print header of packets

2 – print header and data from IP of packets

3 – print header and data from Ethernet of packets

4 – print header of packets with interface name

 

<count>                                      The number of packets the sniffer reads before stopping. If you do not put a number here, the sniffer will run forever unit you stop it with <CTRL C>.

For a simple sniffing example, enter the CLI command diag sniffer packet port1 none 1 3. This will display the next three packets on the port1 interface using no filtering, and using verbose level 1. At this verbosity level you can see the source IP and port, the destination IP and port, action (such as ack), and sequence numbers.

In the output below, port 443 indicates these are HTTPS packets, and 172.20.120.17 is both sending and receiving traffic.

Head_Office_620b # diag sniffer packet port1 none 1 3 interfaces=[port1] filters=[none]

0.545306 172.20.120.17.52989 -> 172.20.120.141.443: psh 3177924955 ack 1854307757

0.545963 172.20.120.141.443 -> 172.20.120.17.52989: psh 1854307757 ack 3177925808

0.562409 172.20.120.17.52988 -> 172.20.120.141.443: psh 4225311614 ack 3314279933

For a more advanced example of packet sniffing, the following commands will report packets on any interface travelling between a computer with the host name of “PC1” and the computer with the host name of “PC2”. With verbosity 4 and above, the sniffer trace will display the interface names where traffic enters or leaves the FortiGate unit. Remember to stop the sniffer, type CTRL+C.

FGT# diagnose sniffer packet any “host <PC1> or host <PC2>” 4

or

FGT# diagnose sniffer packet any “(host <PC1> or host <PC2>) and icmp” 4

The following sniffer CLI command includes the ARP protocol in the filter which may be useful to troubleshoot a failure in the ARP resolution (for instance PC2 may be down and not responding to the FortiGate ARP requests).

FGT# diagnose sniffer packet any “host <PC1> or host <PC2> or arp” 4

 

Packet Capture

When troubleshooting networks, it helps to look inside the header of the packets. This helps to determine if the packets, route, and destination are all what you expect. Packet capture can also be called a network tap, packet sniffing, or logic analyzing.

 

To use the packet capture:

1. Go to System > Network > Packet Capture.

2. Select the interface to monitor and select the number of packets to keep.

3. Select Enable Filters.

4. Enter the information you want to gather from the packet capture.

5. Select OK.

To run the capture, select the play button in the progress column in the packet capture list. If not active, Not Running will also appear in the column cell. The progress bar will indicate the status of the capture. You can stop and restart it at any time.

When the capture is complete, click the Download icon to save the packet capture file to your hard disk for further analysis.

 

Packet capture tells you what is happening on the network at a low level. This can be very useful for troubleshooting problems, such as:

  • Finding missing traffic.
  • Seeing if sessions are setting up properly.
  • Locating ARP problems such as broadcast storm sources and causes.
  • Confirming which address a computer is using on the network if they have multiple addresses or are on multiple networks.
  • Confirming routing is working as you expect.
  • Wireless client connection problems.
  • Intermittent missing PING packets.
  • A particular type of packet is having problems, such as UDP, which is commonly used for streaming video.

If you are running a constant traffic application such as ping, packet capture can tell you if the traffic is reaching the destination, how the port enters and exits the FortiGate unit, if the ARP resolution is correct, and if the traffic is returning to the source as expected. You can also use packet switching to verify that NAT or other configuration is translating addresses or routing traffic the way that you want it to.

Before you start capturing packets, you need to have a good idea of what you are looking for. Capture is used to confirm or deny your ideas about what is happening on the network. If you try capture without a plan to narrow your search, you could end up with too much data to effectively analyze. On the other hand, you need to capture enough packets to really understand all of the patterns and behavior that you are looking for.

How to verify FortiGuard connectivity

Leave a reply

How to verify FortiGuard connectivity

You can verify the FortiGuard connectivity in the License Information widget under System > Dashboard > Status. When FortiGate is connected to FortiGuard, a green check mark appears for available FortiGuard services.

From CLI, execute ping “service.fortiguard.net” and “update.fortiguard.net”.

 

Sample output:

FG100D# execute ping service.fortiguard.net

PING guard.fortinet.net (208.91.112.196): 56 data bytes

64 bytes from 208.91.112.196: icmp_seq=0 ttl=51 time=61.0 ms

64 bytes from 208.91.112.196: icmp_seq=1 ttl=51 time=60.0 ms

64 bytes from 208.91.112.196: icmp_seq=2 ttl=51 time=59.6 ms

64 bytes from 208.91.112.196: icmp_seq=3 ttl=51 time=58.9 ms

64 bytes from 208.91.112.196: icmp_seq=4 ttl=51 time=59.2 ms

— guard.fortinet.net ping statistics —

5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 58.9/59.7/61.0 ms

 

FG100D# execute ping update.fortiguard.net

PING fds1.fortinet.com (208.91.112.68): 56 data bytes

64 bytes from 208.91.112.68: icmp_seq=0 ttl=53 time=62.0 ms

64 bytes from 208.91.112.68: icmp_seq=1 ttl=53 time=61.8 ms

64 bytes from 208.91.112.68: icmp_seq=2 ttl=53 time=61.3 ms

64 bytes from 208.91.112.68: icmp_seq=3 ttl=53 time=61.9 ms

64 bytes from 208.91.112.68: icmp_seq=4 ttl=53 time=61.8 ms

How to check wireless information

Leave a reply

How to check wireless information

Wireless connections, stations, and interfaces have different issues than other physical interfaces.

 

Troubleshooting station connection issue

To check whether station entry is created on Access Control:

FG600B3909600253 # diagnose wireless-controller wlac -d sta

* vf=0 wtp=70 rId=2 wlan=open ip=0.0.0.0 mac=00:09:0f:db:c4:03 rssi=0 idle=148 bw=0 use=2 vf=0 wtp=70 rId=2 wlan=open ip=172.30.32.122 mac=00:25:9c:e0:47:88 rssi=-40 idle=0 bw=9 use=2

 

Enable diagnostic for particular station

This example uses the station MAC address to find where it is failing:

FG600B3909600253 # diagnose wireless-controller wlac sta_filter 00:25:9c:e0:47:88 1

Set filter sta 00:25:9c:e0:47:88 level 1

FG600B3909600253 # 71419.245 <ih> IEEE 802.11 mgmt::disassoc <== 00:25:9c:e0:47:88 vap open rId 1 wId 0 00:09:0f:db:c4:03

71419.246 <dc> STA del 00:25:9c:e0:47:88 vap open rId 1 wId 0

71419.246 <cc> STA_CFG_REQ(34) sta 00:25:9c:e0:47:88 del ==> ws (0-192.168.35.1:5246) rId

1 wId 0

71419.246 <cc> STA del 00:25:9c:e0:47:88 vap open ws (0-192.168.35.1:5246) rId 1 wId 0

00:09:0f:db:c4:03 sec open reason I2C_STA_DEL

71419.247 <cc> STA_CFG_RESP(34) 00:25:9c:e0:47:88 <== ws (0-192.168.35.1:5246) rc 0 (Success).

How to examine the firewall session list

2 Replies

How to examine the firewall session list

One further step is to examine the firewall session. The firewall session list displays all the sessions the FortiGate unit has open. You will be able to see if there are strange patterns such as no sessions apart from the internal network, or all sessions are only to one IP address.

When examining the firewall session list in the CLI, filters may be used to reduce the output. In the web-based manager, the filters are part of the interface.

 

To examine the firewall session list – web-based manager

  • Go to System > FortiView> All Sessions.

 

To examine the firewall session list – CLI

When examining the firewall session list, there may be too many sessions to display. In this case it will be necessary to limit or filter the sessions displayed by source or destination address, or NATed address or port. If you want to filter by more than one of these, you need to enter a separate line for each value.

 

The following example shows filtering the session list based on a source address of 10.11.101.112.

FGT# diag sys session filter src 10.11.101.112

FGT# diag sys session list

 

The following example shows filtering the session list based on a destination address of 172.20.120.222.

FGT# diag sys session filter dst 172.20.120.222

FGT# diag sys session list

 

To clear all sessions corresponding to a filter – CLI

FGT# diag sys session filter dst 172.20.120.222

FGT# diag sys session clear

 

Check source NAT information

Remember NAT when troubleshooting connections. NAT is especially important if you are troubleshooting from the remote end of the connection outside the FortiGate unit firewall. On the dashboard session list, pay attention to Src address after NAT, and Src port after NAT. These columns display the IP and port values after NAT has been applied.

The NAT values can be helpful to ensure they are the values you expect, and to ensure the remote end of the sessions can see the expected IP address and port number.

When displaying the session list in the CLI, you can match the NATed source address (nsrc) and port (nport). This can be useful if multiple internal IP addresses are NATed to a common external facing source IP address.

FGT# diag sys session filter nsrc 172.20.120.122

FGT# diag sys session filter nport 8888

FGT# diag sys session list

How to check number of sessions used by UTM proxy

Leave a reply

How to check number of sessions used by UTM proxy

Each FortiGate model has a set limit of the maximum number of sessions the UTM proxy supports. The UTM proxy handles all the traffic for the following protocols: HTTP, SMTP, POP3, IMAP, FTP, and NNTP. If the proxy for a protocol fills up its session table, the FortiGate unit will enter conserve mode, where it behaves differently, until entries and memory free up again.

 

Conserve or failopen mode

Once you reach the limit, depending on your FortiGate unit’s conserve mode configuration, no new sessions are created until an old ones end. You can configure your FortiGate unit’s behavior when memory is running low or the proxy connection limit has been reached. There are two related commands for this in the CLI:

config system global

set av-failopen-session {enable | disable}

set av-failopen { idledrop | off | one-shot | pass}

end

av-failopen-session must be enabled to set the behavior for these conditions. When it is enabled, and a proxy for a protocol runs out of room in its session table that protocol goes into failopen mode and behaves as defined in the av-failopen command.

av-failopen determines the behavior of the proxy until entries are free in the session table again for that proxy.

  • idledrop — This option removes idle sessions from the session table, starting with the clients that have the most sessions currently open. This method assumes that idle sessions are not being used and it will not cause problems to close these sessions. This is usually true, but some applications may have problems with this and start complaining about either not having or being able to open a session. If this occurs, try another method to check if this is really the problem. This is a secure option as no unscanned traffic is allowed to pass.
  • off — This option turns off accepting any new AV sessions, but will continue to process any existing AV sessions that are currently active. All the protocols listed (HTTP, SMTP, POP3, IMAP, FTP, and NNTP) are scanned by FortiGate Antivirus. If AV scanning is enabled, av-failopen off is selected, and the proxy session table fills up, then no new sessions of that type will be accepted. For example, if POP3 session table is filled and email AV scanning is enabled, no more POP3 connections will be allowed until the session table gets some free space. This is a secure option because no unscanned traffic is allowed to pass.
  • one-shot — When memory is low, bypass the antivirus system. The name one-shot comes from the fact that once you are in one-shot av-failopen mode, you must set av-failopen to either pass or off to restart AV scanning. This is a very unsecure option because it allows all traffic without AV scanning, and it never reverts to normal without manual assistance.
  • pass — When memory is low, bypass the antivirus system much as one-shot. The difference is that when memory is freed up, the system will start AV scanning automatically again. This is an unsecure option because it allows

 

traffic to pass without AV scanning. However, it is better than one-shot because it automatically restarts AV scanning when possible.

If the proxy session table is full for one or more protocols and your FortiGate unit enters into conserve or failopen mode, it will appear as if you have lost connections, network services are intermittent or non-existent, and yet other services work normally for a while until their sessions end and they join the queue of session-starved applications.

 

Checking sessions in use

To make troubleshooting this type of problem easier, sessions are broken down by which protocol they use. This provides you with statistics and errors specific to one of the protocols.

Due to the amount of output from this command, you should connect to the CLI with a terminal program, such as puTTY, that logs output. Otherwise, you will likely not be able to access all the output information from the command.

In the following output, only the HTTP entries are displayed. The other protocols have been removed in an attempt to shorten the output. There will be separate entries for each supported protocol (HTTP, SMTP, POP3, IMAP, FTP, and NNTP) in each section of the output.

 

To check sessions in use and related errors – CLI

FGT# # get test proxyworker 4

Worker[0] HTTP Common

Current Connections 8/8032

Max Concurrent Connections 76

Worker Stat

Running time (HH:MM:SS:usec) 29:06:27:369365

Time in loop scanning 2:08:000198

Error Count (accept) 0

Error Count (read) 0

Error Count (write) 0

Error Count (poll) 0

Error Count (alloc) 0

Last Error 0

Acceptor Read 6386

Acceptor Write 19621

Acceptor Close 0

 

HTTP Stat

Bytes sent 667012 (kb) Bytes received 680347 (kb) Error Count (alloc) 0

Error Count (accept) 0

Error Count (bind) 0

Error Count (connect) 0

Error Count (socket) 0

Error Count (read) 134

Error Count (write) 0

 

Error Count (retry) 40

Error Count (poll) 0

Error Count (scan reset) 2

Error Count (urlfilter wait) 3

Last Error 104

Web responses clean 17950

Web responses scan errors 23

Web responses detected 16

Web responses infected with worms 0

Web responses infected with viruses 0

Web responses infected with susp 0

Web responses file blocked 0

Web responses file exempt 0

Web responses bannedword detected 0

Web requests oversize pass 16

Web requests oversize block 0

Last Server Scan errors 102

URL requests exempt 0

URL requests blocked 0

URL requests passed 0

URL requests submit error 0

URL requests rating error 0

URL requests rating block 0

URL requests rating allow 10025

URL requests infected with worms 0

Web requests detected 0

Web requests file blocked 0

Web requests file exempt 0

POST requests clean 512

POST requests scan errors 0

POST requests infected with viruses 0

POST requests infected with susp 0

POST requests file blocked 0

POST requests bannedword detected 0

POST requests oversize pass 0

POST requests oversize block 0

Web request backlog drop 0

Web response backlog drop 0

 

Worker Accounting

poll=721392/649809/42 pollfail=0 cmdb=85 scan=19266 acceptor=25975

 

HTTP Accounting

setup_ok=8316 setup_fail=0 conn_ok=0 conn_inp=8316 urlfilter=16553/21491/20 uf_lookupf=0

scan=23786 clt=278876 srv=368557

 

SMTP Accounting

setup_ok=12 setup_fail=0 conn_ok=0 conn_inp=12

scan=12 suspend=0 resume=0 reject=0 spamadd=0 spamdel=0 clt=275 srv=279

 

POP3 Accounting

setup_ok=30 setup_fail=0 conn_ok=0 conn_inp=30 scan=3 clt=5690 srv=5836

 

IMAP Accounting

setup_ok=0 setup_fail=0 conn_ok=0 conn_inp=0 scan=0 clt=0 srv=0

 

FTP Accounting

setup_ok=0 setup_fail=0 conn_ok=0 conn_inp=0

scan=0 clt=0 srv=0 datalisten=0 dataclt=0 datasrv=0

 

NNTP Accounting

setup_ok=0 setup_fail=0 conn_ok=0 conn_inp=0 scan=0 clt=0 srv=0

 

The output from this command falls into the following sections:

 

  • HTTP Common current connections — There is an entry for each protocol that displays the connections currently used, and the maximum connections allowed. This maximum is for the UTM proxy, which means all the protocols connections combined cannot be larger than this number. To support this, note that the maximum

session count for each protocol is the same. You may also see a line titled Max Concurrent Connections for each protocol. This number is the maximum connections of this type allowed at one time. If VDOMs are enabled, this value is defined either on the global or per-VDOM level at VDOM > Global Resources.

  • Worker Stat — This is statistics about the UTM proxy including how long it has been running, and how many errors it has found.
  • HTTP Stat — This section includes statistics about the HTTP protocol proxy. This is a very extensive list covering errors, web responses, and any UTM positive matches. There are similar sections for each protocol, but the specific entries in each vary based on what UTM scanning is looking for in each — spam control for email, file transfer blocking for FTP, and so on.
  • Worker Accounting — Lists accounting information about the UTM proxy such as polling statistics, how many sessions were scanned, and how many were just accepted. This information can tell you if expect AV scanning is taking place or not. Under normal operation there should be no errors or fails.
  • HTTP Accounting — The accounting sections for each protocol provide information about successful session creation, failures, how many sessions are being scanned or filtered, and how many are client or server originated. If setup_fail is larger than zero, run the command again to see if it is increasing quickly. If it is, your FortiGate unit may be in conserve mode.

 

Related commands

To dump memory usage:

# get test proxyworker 1

 

To display statistics per VDOM:

# get test proxyworker 4444

 

To restart the proxy:

# get test proxyworker 99