Hello everyone, I am troubleshooting an issue with slow and sometimes no connectivity, when a end user tries to open a file (PDF) on a file server over the internet. The users has internet connection, the problem only happens when accessing a specific site to view files. I've confirmed the issue is not on the end users workstation as the issue happens from my PC as well.
Network is as shown : User-> switch -> (in)firewall(out) -> switch -> gateway router
Here are some of the packets: The packets shown are from a trace on the switchport connected to the outside port of the firewall.
Here is the location of the PCAPS and network diagram: https://drive.google.com/folderview?id=0B41R9G9kL5L-S1JWZ0Z2bTFKN3c&usp=sharing
asked 06 Jan ‘16, 09:25
edited 08 Jan ‘16, 12:53
I feel a bit weird answering a Question based on a capture file provided by a 3rd party, but the world isn't black and white.
The first question would be what kind "firewall" do you use (and @Lewis Travieso, if you are still interested, the same question applies to you)? Looking at the captures, I can see that the device is as if filtering out the turbulences happening at the WAN side so that they wouldn't affect the LAN side. But obviously the primary goal is not the filtering but either caching or, even more likely, analysing the files as they are downloaded for possible malicious contents.
If you apply a display filter
The "firewall" device at the client end is also responsible for the crash of the TCP session. The last incoming packet from WAN side to be properly retransmitted to LAN side is the one in frame 462 (WAN)/frame 464 (LAN); after that, the firewall sends (inevitably impersonating the remote server) a locally generated RST, although at the WAN side, subsequent packets (frames 463 and 464) have arrived from the remote server in the meantime. But the firewall stops talking to the server completely, so after a short while, the server starts retransmitting the last packet it didn't get acknowledged, and it sends a RST itself after still getting no acknowledge for almost 20 seconds.
So my conclusion is that the "firewall" is actually a more sophisticated security device, which analyses the HTTP responses as it forwards them, and it either does not like or merely does not understand the contents of the pdf file, so it causes the TCP session to fail as a consequence, either intentionally or due to a bug. Notably, Wireshark's
The url (
answered 07 Aug '16, 03:13
edited 07 Aug '16, 12:55