FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
mbanica
Staff
Staff
Description
This article describes how anti-replay works, when it is good to enable, set to loose, or disable this mechanism.  It also explains how to configure sniffer correctly.

Solution
FortiGate units use TCP sequence checking to make sure that a segment is part of a TCP session. By default, if a packet is received with sequence numbers that fall out of the expected range, the FortiGate unit drops the packet. This is normally a desired behavior, since it means that the packet is invalid or duplicated.

The default is strict.

The anti-replay protection can be set to any of the following values:
  • disable — No anti-replay protection. Susceptible to SYN floods.
  • loose — Perform packet sequence checking and ICMP anti-replay checking with the following criteria:
    • the SYN, FIN, and RST bit can not appear in the same packet.
    • the FortiGate unit does not allow more than one ICMP error packet through before it receives a normal TCP or UDP packet.
    • if the FortiGate unit receives a RST packet, and check-reset-range is set to strict, the FortiGate unit checks to determine if its sequence number in the RST is within the un-ACKed data and drops the packet if the sequence number is incorrect.
  • strict — Performs all of the loose checking but for each new session also checks to determine of the TCP sequence number in a SYN packet has been calculated correctly and started from the correct value for each new session. Strict anti-replay checking can also help prevent SYN flooding. If any packet fails a check it is dropped.

Packets can be replayed due to a network congestion.

Configuration CLI

FGT # config system global

FGT (global) # set anti-replay ?
disable    Disable anti-replay check.
loose      Loose anti-replay check.
strict     Strict anti-replay check.
FGT (global) # end


Before running a sniffer to capture packets and check for replayed packets, if the unit supports offloading to hardware, make sure that offloading is disabled before testing. Offloaded packets to NP(Network Processor) or SP are not visible in the sniffer or debug.

How to check if a device has NP:

FGT  # get hardware nic *port name*

Example:

# get hardware nic wan1

How to disable offloading for testing purposes:

FGT # config  firewall policy
FGT (policy) # edit *ID number*  (not Sequence)
FGT (1) # set auto-asic-offload disable
FGT (1) # next
FGT (policy) # end


Sniffer with verbose 6 can be converted into PCAP file and analyzed in Wireshark:

FGT # diagnose sniffer packet any "host x.x.x.x" 6 0 a

"any" can be replaced with any port in order to observe traffic on a particular interface.  It is possible to filter by host (192.168.1.1), port number (port 21), protocol (icmp, tcp, udp, esp, arp etc.) or network (net 192.168.0/24).

Sniffer with verbose 4 shows only Data link, Network and Transport layer:

FGT # diag sniffer packet any "arp" 4 0 a
interfaces=[any]
filters=[arp]
2015-02-18 09:33:55.487775 wan1 in arp who-has 10.108.17.23 tell 10.108.16.103
2015-02-18 09:33:56.469167 wan1 in arp who-has 10.108.17.23 tell 10.108.16.147
2015-02-18 09:33:57.363082 wan1 in arp who-has 10.108.17.33 tell 10.108.16.133
2015-02-18 09:33:57.449085 wan1 in arp who-has 10.108.17.73 tell 10.108.16.75
2015-02-18 09:33:58.197367 wan1 in arp who-has 10.108.18.78 tell 10.108.16.52
2015-02-18 09:33:58.328193 wan1 in arp who-has 10.108.19.254 tell 10.108.18.31


Contributors