We have sophos application which is used to encrypt user data on laptops. When user connects to network, sophos software installed on laptop communicates with Sophos server on port 443 and syncs database with server.
Users have issues with this appliation whose VIP is hosted on ACE. Existing setup is on CSS and users have no issues with it. While migrating , we keep the VIP same on ACE as that of CSS.
We have configured end to end SSL where ACE works as SSL server for users and SSL client for sophos servers.
Client IP: 10.58.148.73 VIP IP: 22.214.171.124
CSS has arrowpoint cookie. cookie based stickiness didnt work with ACE so I tried IP based cookiness but still it didnt help.
I have attached configuration of both ACE and CSS and logs. Can anyone help urgently?
What do you mean by dropping packets? The capture doesn't tell much as it seems it was taken from the client side. Is the status of both servers operational?
I've come up with a config sample that you could try, I made some modifications to the original just to work this out from the bottom to the top; leaving the serverfarm without a probe so we can avoid rserver flaps. The VIP is now just for port 443 as there's no need on having it wide open for "any" service, and the SSL parameter map takes into consideration the use of almost any available cipher to match the one your backend servers are using.
Please give it a shot and let us know how it goes.
Thanks for your quick response.
This application is used by many countries and not all countries are facing this issue. Only users from India and UK are facing this issues. Rest of users from 6 countries dont face any issue with this setup so its not an issue with probes or status of rserver.
I have single interface on ACE and i took capture for that interface with specific source and destination address.
As nothing has been changed in the network including VIP, I dont understand why it is not working with ACE while it works perfectly fine with CSS. The only thing changed is source nat ip address.
Thats why I have attached both CSS and ACE config in my original post and capture logs.
If the issue is persistent then i would suggest to take a simultaneous pcaps on client as well as ACE for that particular client facing the issue. That should tell you if ACE is sending the packet late or server is replying late or what else is going on here. If this is working for 6 other countries i don't see why ACE would drop or delay packets for clients in a particular locations.
You are right Kanwal. When I revert to CSS, things work fine for all users.
But when I migtate to ACE, it stopped working for India and UK.
Users can connect to application but fail to sync data with application. I will try to collect pcaps on both client and ACE at same time. I need to install wireshark on client machine.
Do you see anything in CSS config which is missing in ACE config? Or anything in collected pcap file on ACE?
The queue delay time is the amount of time in milliseconds that the ACE waits before emptying the queued data for encryption.
queue-delay timeout milliseconds
The ACE queues packet data from the server before encrypting it for transmission to the client. The ACE empties the data from the queue for encryption when one of the following events occurs:
• The queue reaches 4096 bytes.
• The server sends a TCP-FIN segment.
• The queue delay time on the ACE has passed even though the queue had not reached 4096 bytes.
The queue delay time is the amount of time that the ACE waits before emptying the queued data for encryption. By default, the queue delay timer is disabled. You can set the delay time by using the queue-delay timeout command in parameter map SSL configuration mode. A value of 0 disables the delay timer, causing the ACE to encrypt data from the server as it arrives and then send the encrypted data to the client. The queue delay applies only to encrypted data that the ACE sends to the client.
I found this option is recommended only to preserve ssl resources on the ACE and its suggested to have 200 – 300 milliseconds of the timeout value so instead of encrypting and sending more smaller blocks of data, we would compact several blocks of data that we receive from the server during this delay and encrypt it to send it to the client. I could not find anything where its suggested to keep it with a very low value of 1 millisecond to improve the performance. Lets say the ACE sends data received from the server every millisecond to be encrypted to send to the client, the time taken to encrypt the data to send it to client will be more as many small packets would need to be encrypted and might cause delay.
Hence I would request you to try removing this command and see if it helps.
I see that the client(10.58.148.73) is sending FIN+ACK(frame 10) after ssl handshake is completed so does not look like ACE is dropping the packet. You could probably check what is different by comparing traffic from a different country with india and UK users and see why the client is sending FIN+ACK in this case. If you require more support on this I would kindly request you to open a TAC case.