When proxy TCPIP and upstream device both agreed on MTU as default
Maximum segment size: 1400 bytes
but when proxy sent out-bound packet to upstream, it only used max data length (or max segment size--mss) 512 bytes.
If the HTTP GET request data length is over 512, Proxy divided it to more then 1 packet. This caused connection break down, as some up stream device can not understand this kind of packet, and failed the communication.
This setup the Transparent proxy, port 80 as tcp-tunnel, intercept.
client to proxy: get request 968 bytes
71 0.000999 12:31:25.903999 10.10.113.90 126.96.36.199 1940 80 HTTP 968 GET / HTTP/1.1
Proxy send to up stream: see data length 566 bytes.
72 0.000000 12:31:25.903999 10.10.113.90 188.8.131.52 19347 80 HTTP 566 GET / HTTP/1.1
follow by another packet:
73 0.000000 12:31:25.903999 10.10.113.90 184.108.40.206 19347 80 HTTP 456 Continuation or non-HTTP traffic
Upstream return 2 ACK packets for these 2 header packet, but failed to return any data.
At this setup is Transparent proxy, port 80 tcp tunnel, BYPASS.
As another pcap:
client sent get to proxy:
898 6.291999 12:41:35.896999 10.10.113.90 220.127.116.11 2010 80 HTTP 960 GET / HTTP/1.1
Proxy send it whole packet out, as BYPASS. the same size 960 bytes.
899 0.000000 12:41:35.896999 10.10.113.90 18.104.22.168 2010 80 HTTP 960 [TCP Out-Of-Order] GET / HTTP/1.1
Upstream return data:
902 0.232000 12:41:36.129000 22.214.171.124 10.10.113.90 80 2010 HTTP 1418 HTTP/1.1 200 OK
So that proved the proxy tcp break up packet to multiple < 512 packets caused the problem. This may not be a issue for most modern TCPIP network, but this customer has some content filter at upstream(websense), and that can very well caused a broken, as it can not understand partial HTTP header.
We tested in lab can reproduce the issue, a simple transparent proxy, port 80 as tcp tunnel, intercept/bypass.
And if we use 126.96.36.199, with same box same setting, no problem found. so that proved this issue is introduced at 188.8.131.52.