Solutions

SGOS 5.5.1.1 TCPIP splits standard size packet to smaller data length (mss) to 512 bytes or smaller, for outbound traffic to upstream device, breaks connection.

Solutions ID:    KB3746
Version:    1.0
Status:    Published
Published date:    03/23/2010
 

Problem Description

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.
PCAP

client to proxy: get request 968 bytes
71    0.000999    12:31:25.903999    10.10.113.90    209.191.122.70    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    209.191.122.70    19347    80    HTTP    566    GET / HTTP/1.1

follow by another packet:
73    0.000000    12:31:25.903999    10.10.113.90    209.191.122.70    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    209.191.122.70    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    209.191.122.70    2010    80    HTTP    960    [TCP Out-Of-Order] GET / HTTP/1.1

Upstream return data:
902    0.232000    12:41:36.129000    209.191.122.70    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 5.4.3.3, with same box same setting, no problem found. so that proved this issue is introduced at 5.5.1.1.

Resolution

Apply SGOS 5.5.2.0 or later.

 


Rate this Page

Please take a moment to complete this form to help us better serve you.

Did this document help answer your question?
 
 
If you are finished providing feedback, please click the RATE CONTENT button. Otherwise, please add more detail in the following text box and then click RATE CONTENT.
 
 

Your response will be used to improve our document content.

Ask a Question