This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

tcpdump captures see packets before processing?

I'm trying to figure out a problem I'm having using my company's online document control system from home through Astaro.  It's a web interface.  Documents are pulled from a behind-the-scenes document server, and downloaded through the main web site via HTTP or HTTPS (not FTP).  Viewing these documents works fine, but when I try to edit them (which results in downloading the file to my PC, which opens it using the default application, in this case, MS Word), I get "Error on page."

I've run tcpdump packet captures on our firewall at work (I'm the admin), and at home on both sides of my Astaro firewall (7.006, but it happened on 7.005 as well).  What I see is disturbing.  It does not depend on whether I'm using the web proxy or a packet filter rule for HTTP traffic.  All my testing has been performed using HTTP so I can see everything in the packets.  The document download works fine until I get to this packet, which I believe is at the end of the document download:

HTTP/1.1 200 OK (application/octet-stream)

This packet seems to contain the information for reassembling previous TCP segments to put the document back together again.  Although the packet size in this case is only 126 bytes, the total size listed in Wireshark for the reassembled data is 148212 bytes, which is the size of the document being downloaded.

This crucial packet shows up on the packet capture on the external side of the server-side firewall (which is AFTER all firewall processing, a fact I am 100% positive of based a great deal of experience with it), but it does not show up in the packet capture I perform on the external interface on my Astaro firewall.

I have a coworker who is also running this firewall at home, and he experiences the same problem (although he has not run packet captures, I'm sure the same thing is the cause).  He has a different type of ISP than I have (I have business grade DSL, he has cable modem, from different providers).  These facts lead me to believe that the packet capture on the Astaro firewall is actually seeing data AFTER at least some processing has occurred on the Astaro firewall.  SOMETHING is causing that HTTP/1.1 packet to disappear.

I've tried tweaking or disabling just about every setting in the Astaro firewall I can think of to get this to work with no luck.  One of the reasons I'm using this firewall at home is because a coworker in our IT Services department is thinking of recommending Astaro for our customers on the Internet around the world.  It would become our new standard for installing at customer sites.  However, this is absolutely out of the question if I can't get our document control system to work through Astaro.

Any help anyone could provide would be greatly appreciated.


This thread was automatically locked due to age.
Parents
  • Is it possible there is an IPS or http proxy in between the servers that could be altering the traffic?
    Does your ISP run a transparent proxy?

    Could your antivirus software on the client PC be interfering with opening a MS document from the Web?
    Can you try a different client PC?
    Have you tried without the firewall on the client side?

    FWIW, this

    This packet seems to contain the information for reassembling previous TCP segments to put the document back together again.

    does not make sense, especially for an HTTP packet.

    Barry
  • This worked just fine when I was running m0n0wall, and then pfSense, just prior to switching to Astaro.  The fact that my coworker also experiences the same thing, and he's on a different ISP (and cable vs. DSL), tells me it's definitely an Astaro thing.
  • Try disabling the http proxy and http antivirus, and the IPS, if you haven't already.

    Barry
Reply Children