# HTTP Body Empty When Analyzing FortiGate SSL-Inspected Mirror Traffic

**URL:** <https://community.zeek.org/t/http-body-empty-when-analyzing-fortigate-ssl-inspected-mirror-traffic/7629>\
**Category:** Zeek\
**Tags:** tls-decryption, mirroring, logging\
**Created:** [October 30, 2024, 10:55am UTC](https://community.zeek.org/t/http-body-empty-when-analyzing-fortigate-ssl-inspected-mirror-traffic/7629 "2024-10-30T10:55:32Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![kimsw](https://avatars.discourse-cdn.com/v4/letter/k/db5fbb/32.png) [@kimsw](https://community.zeek.org/u/kimsw)\
**Post date:** [October 30, 2024, 10:55am UTC](https://community.zeek.org/t/http-body-empty-when-analyzing-fortigate-ssl-inspected-mirror-traffic/7629/1 "2024-10-30T10:55:32Z")

</div>

Hi,  
I am in the process of configuring a system that FortiGate UTM performs SSL inspection on some HTTPS traffic and sends it to a mirror port, and Zeek receives and analyzes this mirrored traffic. The packet analysis stage includes checking the contents of the decrypted request body and response body.

However, the environment is fully set up, and when I check the traffic in Zeek’s http.log, either request\_body\_len or response\_body\_len is always 0, and the body data for the zero-length items is not output. For non-mirrored HTTP traffic, both request\_body and response\_body are logged correctly.

The invocation method uses HTTP POST, so it should not be the case that both are 0. Below is the test result from a curl call on a Windows desktop:

$ curl --request POST --url [https://httpbin.org/post](https://httpbin.org/post) -d {“key1”:“value12345”} --ssl-no-revoke  
{  
“args”: {},  
“data”: “”,  
“files”: {},  
“form”: {  
“{key1:value12345}”: “”  
},  
“headers”: {  
“Accept”: “_/_”,  
“Content-Length”: “17”,  
“Content-Type”: “application/x-www-form-urlencoded”,  
“Host”: “[httpbin.org](http://httpbin.org)”,  
“User-Agent”: “curl/7.83.1”,  
“X-Amzn-Trace-Id”: “Root=1-6721fceb-278f093a4beae14f54fc0d2f”  
},  
“json”: null,  
“origin”: “1.235.10.153”,  
“url”: “[https://httpbin.org/post](https://httpbin.org/post)”  
}

If this issue is caused by the limitations of mirrored traffic, is there a way to obtain the desired results even if unnecessary detection features are disabled? Since we are monitoring traffic going from internal to external, most security-related detection features can be disabled.

I am attaching a pcap file and Zeek log files.

Thank you.  
[traffic.pcap](https://community.zeek.org/uploads/short-url/kOdyHTCiFPceK1UhrmSXNdUf6rk.pcap) (3.0 KB)  
[zeek\_log.tar](https://community.zeek.org/uploads/short-url/mvHX4IFV7KbWGdP7T0z5gUF4von.tar) (10 KB)

---

<div class="post-metadata">

**Author:** ![Richard\_Bejtlich](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/richard_bejtlich/32/597_2.png) [@Richard\_Bejtlich](https://community.zeek.org/u/Richard_Bejtlich)\
**Post date:** [October 30, 2024, 12:40pm UTC](https://community.zeek.org/t/http-body-empty-when-analyzing-fortigate-ssl-inspected-mirror-traffic/7629/2 "2024-10-30T12:40:52Z")

</div>

Hello, have you looked at your pcap in Wireshark? There appears to be some traffic missing. Wireshark noticed ACKing unseen segments. This is true for both connections.

I loaded your pcap into [try.zeek.org](http://try.zeek.org)

[https://try.zeek.org/#/tryzeek/saved/e4366195d4204f689b16c42042c2833d](https://try.zeek.org/#/tryzeek/saved/e4366195d4204f689b16c42042c2833d)

and the capture\_loss log also reflects these gaps.

I wonder if this is responsible for your issues?

I would try ttroubleshooting the SSL decryption to get a “clean” pcap without these issues.

Sincerely,

Richard

---

<div class="post-metadata">

**Author:** ![kimsw](https://avatars.discourse-cdn.com/v4/letter/k/db5fbb/32.png) [@kimsw](https://community.zeek.org/u/kimsw)\
**Post date:** [October 31, 2024, 5:05am UTC](https://community.zeek.org/t/http-body-empty-when-analyzing-fortigate-ssl-inspected-mirror-traffic/7629/3 "2024-10-31T05:05:06Z")

</div>

Hi Richard,  
Thanks for your response.

I had previously checked the pcap through Wireshark and was aware that TCP unseen segments were occurring.  
I also recently learned that this phenomenon is due to the NP/SP offloading process when Fortigate handles packets.

However, I cannot change the current settings of Fortigate, and I am curious if there is a way for Zeek to log http.log correctly when receiving traffic in this form.

Looking at the actual pcap, it does contain both HTTP request and response packets. Is there a way to log both the request and response body in http.log, even if it means disabling some of Zeek’s detection features?

Regards,  
Allen

---

<div class="post-metadata">

**Author:** ![Richard\_Bejtlich](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/richard_bejtlich/32/597_2.png) [@Richard\_Bejtlich](https://community.zeek.org/u/Richard_Bejtlich)\
**Post date:** [November 1, 2024, 1:29pm UTC](https://community.zeek.org/t/http-body-empty-when-analyzing-fortigate-ssl-inspected-mirror-traffic/7629/4 "2024-11-01T13:29:02Z")

</div>

Hello,

I think whatever sorcery is affecting the stream is confusing Zeek. Until that is fixed I don’t know how to proceed.

Sincerely,

Richard

---

<div class="post-metadata">

**Author:** ![kimsw](https://avatars.discourse-cdn.com/v4/letter/k/db5fbb/32.png) [@kimsw](https://community.zeek.org/u/kimsw)\
**Post date:** [November 4, 2024, 12:16am UTC](https://community.zeek.org/t/http-body-empty-when-analyzing-fortigate-ssl-inspected-mirror-traffic/7629/5 "2024-11-04T00:16:15Z")

</div>

At first, it wasn’t working well, so I tried setting “set auto-asic-offloading disable” after finding some information, but when I checked the TCPDUMP, it was the same.

As I continued testing afterwards, I realized that previously I had been checking the TCPDUMP on the Linux server receiving mirrored traffic, but it was different from the TCPDUMP collected on the FortiGate.  
The FortiGate was sending traffic normally after setting “set auto-asic-offloading disable”.

In the end, the problem was resolved.  
The cause turned out to be that the Linux server was running on a virtual machine, so I learned that both the FortiGate’s offloading and the VM’s NIC offloading needed to be disabled together to properly receive the traffic.

Thank you for your help.

---

<div class="post-metadata">

**Author:** ![Richard\_Bejtlich](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/richard_bejtlich/32/597_2.png) [@Richard\_Bejtlich](https://community.zeek.org/u/Richard_Bejtlich)\
**Post date:** [November 4, 2024, 2:08pm UTC](https://community.zeek.org/t/http-body-empty-when-analyzing-fortigate-ssl-inspected-mirror-traffic/7629/6 "2024-11-04T14:08:53Z")

</div>

Excellent – I’m glad to hear it’s working!

Sincerely,

Richard
