Hello Checkmates,
Am I the only one that has noticed that with HTTPS-inspected traffic, Checkpoint gateways always initiate an outbound tcp connection with TCP receive window scale factor of 8, and that the gateway's receive window never scales beyond 262144 bytes (32,768*8) in either direction (facing the client or facing the internet server)? This limits the throughput of a single tcp connection and is a problem if either bandwidth or latency is high.
For example, bandwidthplace.com test uses a single TCP connection. On our 500 Mbps link, with HTTPS inspection we get around 90 Mbps down. With HTTPS client bypass, we get 350 Mbps down (since windows controlled by client instead of gateway). This is on an otherwise idle gateway with no CPU usage. It's also not a matter of other active blades, it still happens with HTTPS-inspected traffic even if I turn off everything else. Of course, most web browsers use a single tcp connection for web downloads so we also see the same thing on https downloads. It is very clearly a problem of the gateways limiting the tcp receive window.
We have 6500 Gateways on R80.40 take 83. I only noticed since we have a higher bandwidth link now and also some remote users tunneling through high latency paths. I realize on the aggregate of many connections we still get the throughput, but it's odd to artificially limit HTTPS throughput of a single connection and make the gateway the bottleneck. Maybe they have to make some arbitrary choice for scalability of number of TCP connections or something, but it would sure be better to simply follow what the client presents in the TCP Syn packet so the gateway doesn't throttle the throughput.
I have an SR open and we're running this up the tree, but I would be interested to know if anyone else has noticed this limitation or could confirm their gateways do the same thing. I did it by using cppcap to a file then looking at the connection that the gateway makes to the internet server after the client does, then looking at the maximum receive window it gets. In all cases HTTPS inspection makes the connections as described above, and gateway's receive windows never scales past 262144 bytes, whereas the client on its own without inspection would go up to tcp receive windows like 8 MB and thus get much better throughput.
Also, this has nothing to do with the OS settings such as rmem tcp_rmem and so on. If from the gateway you initiate a connection directly (telnet to some port), it honors the rmem settings and in my case puts window scaling factor of 1024 which matches the OS rmem setting. No change in OS tcp settings affects what the HTTPS-inspected connections initiated from the gateway do.
Thanks for any confirmation. I'm just curious if checkpoint is really artificially limiting single-connection TCP throughput for all their customers in similar latency/bandwidth scenarios that use HTTPS inspection and didn't bother to tell us.
