Technical Tip: Traffic analysis/latency report on FortiWeb in true transparent proxy mode
Description
This article describes and analyzes the difference in throughput and BW utilization on ingress and egress interfaces on a FortiWeb, deployed in true transparent proxy mode.
The observation is that the throughput/utilization on the egress interface (toward the client) appears to be lower than the throughput/utilization on the ingress interface (from the server) when traffic passes through the FortiWeb.
The analysis confirms that FortiWeb acts as a Stateful Split-TCP Bridge, performing deep content inspection. The throughput delta is a result of Buffer-Gated Release, where data is intentionally held for security scanning before being paced to the client.
Scope
Network topology & traffic flow diagram:
The following diagram illustrates how FortiWeb sits inline and where the specific packet modifications occur.
In this test, the client opened a web session on the web server and downloaded a PDF file (~2MB in size).
The packet capture taken on the FortiWeb from both port1 and port2 at the same time is attached.
Solution
Section 1.
Diagram Breakdown and packet analysis.
Port 1 (Ingress): Represents the traffic coming from the server. FortiWeb advertises a very small TCP Window here to intentionally limit the server's speed while it prepares to reassemble the data.
Reassembly Buffer: This is where the massive reassembled PDUs seen in the GUI (e.g., 57KB) are created in memory.
Security Engine: Once content is scanned, it moves to the Egress Scheduler.
Port 2 (Egress): The re-originated traffic. The TTL drops to 64, and the PSH flag is set, signalling the client that the full, inspected buffer has been released.
Port 1: Ingress (Server -> FortiWeb):
This reflects the 'Raw' speed of the Windows Server pushing data into FortiWeb's memory.
Start of TCP (Frame 4, first SYN): 08:39:34.102191.
End of Data (Frame 1127, http OK): 08:39:34.282630.
Time Window: 08:39:34.282630 - 08:39:34.102191 = 0.180439.
Total Data (with headers): approximately 2,233,000 bytes.
Calculated Rate: Bandwidth: (2,233,000 bytes x 8) / 0.180439 = 99,002,987bps.
Analysis: This shows the server is utilizing nearly the full capacity to 'fill' the FortiWeb's buffer.
Port 2: Egress (FortiWeb -> Client):
This reflects the 'Processed' speed of the data being released to the client after inspection.
Start of TCP (Frame 2): 08:39:34.094079.
End of Data (Frame 384): 08:39:34.285739.
Time Window: 08:39:34.285739 - 08:39:34.094079 = 0.191660.
Total Data (with headers): approx 2,233,000 bytes.
Calculated Rate: Bandwidth: (2,233,000 bytes x 8) / 0.191660 = 93,206,720bps.
What this means:
The Ingress (99,002,987bps) proves the network and the Server are highly performant.
The Egress (93,206,720bps) is the 'Security-Gated Throughput'. The FortiWeb consumes some time of overhead to reassemble the segments, perform WAF/AV signature lookups, and re-originate the packets.
Conclusion: This is a healthy ratio for a WAF performing deep packet inspection on a PDF file. For a small-sized PDF file, this is not significant, but looking at the BW utilization graph on an NMS server, different values will be observed depending on the start/end timestamp of the average calculation.
Section 2.
Where Pacing and Buffering Occur: Based on the packet captures, the exact locations of the 'Traffic Gate' can be seen:
The ingress gate (Flow control).
In Packet No. 9 (Port 1), the FortiWeb advertises a small TCP Window (~254 bytes) to the server.
Location: The TCP Stack on Port 1.
Action: This forces the server to 'slow down' its transmission. By shrinking the window, FortiWeb ensures that its internal reassembly buffers are not overwhelmed before the CPU can scan the data.
The inspection buffer (Data holding).
Location: Internal System Memory (RAM).
Action: Unlike a standard switch that forwards packets bit-by-bit (cut-through), FortiWeb must wait for the entire 'Object' (e.g., the PDF file or a large chunk of it) to be collected in the Reassembly Buffer.
Capture Evidence: This is why massive software PDUs (e.g., 57,000 bytes) are seen in the GUI capture. FortiWeb is building a 'super-packet' in memory to run the WAF signatures against it efficiently.
The egress scheduler (Paced release).
Location: The transmit stage of Port 2.
Action: Once the security engine gives the 'OK', the data is released. The PSH (Push) flag is injected in Packet No. 10 (Port 2). This indicates that the buffer is being flushed and 'pushed' to the client. The speed here is limited by the overhead of the scanning process (Inspection Latency).
Section 3.
Comparison of the first data segment.
The following table highlights the transformation of the first data block sent by the server.
Feature | Port 1 (Ingress from Server) | Port 2 (Egress to Client) | Technical Significance |
Packet Reference | Packet No. 9 | Packet No. 10 | The transition of the same data block. |
TCP Flags | [ACK] | [PSH, ACK] | PSH Injection: FWEB flushes the buffer after inspection. |
TTL (Time to Live) | 128 | 64 | IP Re-origination: Confirms FWEB's OS re-sent the data. |
TCP Options | Timestamps Included | Timestamps Stripped | TCP Normalization: Security against OS fingerprinting. |
TCP Window | ~254 bytes | ~2082 bytes | Flow Control: FWEB paces server to prevent overflow. |
Section 4.
Conclusion:
The FortiWeb, even in 'True Transparent Mode', means that no IP addresses are exposed to endpoints, no routing or NAT, and MAC‑level forwarding. But it does not mean passthrough TCP, and FortiWeb still performs functions such as Stateful TCP inspection, TCP normalization, Segment reassembly, and Content buffering for WAF inspection. So architecturally, FortiWeb operates as a split‑TCP bridge, even in L2 mode, and the packet captures confirm this.
The throughput difference between the server-side and client-side is not indicative of a network fault. Instead, it is proof of active security and could be even larger depending on the NMS start/end time of the calculation.
The Web Server is limited only by the physical wire, while the Client is receiving data that has been fully reassembled, normalized, and scanned for threats. The 'pacing' observed is the standard operating behavior of a high-performance Web Application Firewall, ensuring the integrity of the delivered content.
Note 1: Note that since this test has been done in a shared and general lab environment, the performance data calculated in this report does not reflect real performance and capacity of the device, but is just explaining one of the reasons that the data rate might be different on the ingress and egress interfaces. The FortiWeb device used in the lab is a physical device, but server, client, and network connections are based on a virtual network infrastructure.
Note 2: Other parameters causing the difference could be:
Packet loss or dropped packets, traffic shaping or bandwidth limiting, MTU and fragmentation, network interface performance, enabling more advanced features on the device, or asymmetric traffic patterns. But this report is focused only on the standard web protection setting, with no other parameters mentioned.