topic Cisco Ace 4710 - Strange tcp mss problem in Application Networking

Cisco Ace 4710 - Strange tcp mss problem

vladimirsaltao — Wed, 04 Sep 2013 09:08:07 GMT

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?

Cisco Ace 4710 - Strange tcp mss problem

Kanwaljeet Singh — Sun, 20 Oct 2013 13:33:53 GMT

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

I have the same problem. The

pierre.morency — Wed, 18 Feb 2015 15:54:10 GMT

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 ?