Cisco Ace 4710 - Strange tcp mss problem

[vladimirsaltao]

I am seeing a strange behaviour in a ACE 4710 (A5(2.1)).

I have ssl proxy configured and it mostly works. The only problem is in one provider that  is changing the mss to 536, for this https connection the ACE begins sending data and then just stops. Nothing appears at the ACE logs...

After some tests, a workaround has been found, if i configure a minimum mss with: set tcp mss min 600 max 1380 then it works.

Does anyone had this type of behaviour? Is there another better fix/workaround?

[Kanwaljeet Singh]

Hi,

If this is reproducible then i would suggest opening a case with TAC to investigate further. 536 is minimum value and ACE ideally should not stop forwarding it it is getting response from server and client. How do you know it was ACE which stopped passing traffic? Do we have a pcap showing that server replied with packet which ACE received and didn't forward to the client and vice-versa?

If you have all this information and show tech during the issue i would suggest opening a case with TAC for further investigation into the matter.

Regards,

Kanwal

[pierre.morency]

I have the same problem. The problem only occurs when incoming HTTPS is converted to HTTP on the ACE using NAT configuration. In one scenario the browser (10.170.44.71) send no MSS option when the connexion with the ACE (10.170.72.23) is initiated as in A) so default value of 536 is assumed

A) Trace from Client establishing a HTTPS connection

297         5.750800000       10.170.44.71      10.170.72.23      TCP        62           61266→443 [SYN] Seq=0 Win=8192 Len=0 WS=4 SACK_PERM=1

298         5.751020000       10.170.72.23      10.170.44.71      TCP        60           443→61266 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1460

On the backend in HTTP, the ACE established a connection with a MSS of only 503, which is lower than the minimum TCP/IP value of 536.

B) Trace From IIS server

26863    41.563459000    10.170.132.211  10.170.73.23      TCP        58           80→11649 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460

26862    41.563362000    10.170.73.23      10.170.132.211  TCP        60           11649→80 [SYN] Seq=0 Win=32768 Len=0 MSS=503

(see attached image for complete capture)

So when the IIS HTTP server replies, the packet gets dropped by the ACE, the client never receives it. I also notice the no fragmentation flag being set by IIS.

In traces C) and D) we tried with a HTTPS browser that is sending a MSS of 1427, this works, the answer from the HTTP server get back from the ACE

C) Trace from Client HTTPS Browser

1             0.000000000       10.170.90.47      10.170.72.23      TCP        66           53956→443 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1

D) Trace from  IIS Web Server

5798      15.019072000    10.170.73.27      10.170.132.36    TCP        60           8096→80 [SYN] Seq=0 Win=32768 Len=0 MSS=1427

5799      15.019196000    10.170.132.36    10.170.73.27      TCP        58           80→8096 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460

What seems to be a bug is that the MSS of the HTTP connexion established by the ACE with IIS server seems to compute its MSS by substracting 33 from the MSS received by the HTTPS incoming connexion.

No MSS scenario: 536 – 33 = 503

Large MSS scenario: 1460 – 33 = 1427

I would expect the MSS to be always higher than 536 given the minimum MTU of a IP Network being 576. Why is 33 bytes always substracted the client MSS to set the MSS from outgoing connexions ?