Dear all,
I'm having a problem with a Cisco firewall where NATed HTTP connections
to one particular host stall after the first few hundred bytes. Please
see the attached trace.
To my untrained eye it looks as if the remote host sends the beginning
of the HTTP response in frames 5-8. For frames 6-8, Wireshark shows the
TCP checksum as incorrect. Interestingly, the value is always
off-by-one. (I captured these packets from between the firewall and that
host, so checksum offloading should not be a problem here?)
If the checksum is really incorrect, the Cisco probably just throws the
packets away, which is why the frame #9 just ACKs frame #5.
After that, the remote hosts starts re-transmitting the data from that
point on with an geometrically increasing delay. I have even seen this
to be very close to 2, 4, 8, 16, 32... seconds between packets. The
checksum is wrong again so we don't get along here.
Unfortunately, I do not have control over that remote host but it is the
only one I have observed these symptoms with. When I do not have the
firewall/NAT in place, everything works fine. When the firewall is not
NATting but just forwarding for a DMZ it works as well and no checksum
mismatch is shown. All OSes I could test as clients behind the firewall
are affected.
Question:
- How can I confirm that the checksum is definitely wrong?
- Is there an simple explanation for TCP checksums always being off by
one?
- Any ideas why having the firewall in place makes a difference? I
presume that the checksum can be calculated from the single packet - so
when I receive packets with wrong checksums, the problem must be on the
remote end or the path from it to me. Who sent or what has been sent
before should not make a difference...
- Have you seen something like this before? How could I proceed?
Thanks,
Matthias
Attachment:
trace.pcap
Description: trace.pcap
