Path MTU discovery is described in RFC1191 ftp.rfc-editor.org/in-notes/reason91.txt

Its is used to allow data to be transmitted across the network without the need for fragmentation by "discovering" the maximum size a packet can be in the network path before fragmentation is required.

PMTU discovery is done because the reassembly and fragmentation of data packets can cause delays in the network and is often inefficient.  There are also security risks associated with fragmentation.

The maximum packet allowed through a network path is "discovered" by using the don't fragment (DF) flag in the IP header.  When a packet which is too large to be forwarded is received by a device, if the DF flag is set, it cannot fragment the packet in order to forward the data , so instead it drops the packet and returns an ICMP (Internet Control Message Protocol) "Host unreachable, needs fragmentation" (ICMP type 3, subtype 4) message to the sender.  This informs the sender that this packet is too large to pass through the network without fragmentation, and so the sender will reduce the packet size and resend the data.

However,  many network devices (especially Firewalls) are configured not to forward ICMP traffic of any sort.

If the network path contains a device configured not to pass ICMP traffic and path MTU is enabled the ICMP "Fragmentation needed" message will never get back to the sending host and as a result the connection will fail.

Disabling Path MTU allows the connection to work, albeit with fragmentation taking place.  (Note also that an over taxed router may drop packets requiring fragmentation, in order to reduce its load).

The only way you can improve the situation is to either get the offending device configured to allow ICMP messages through, or to configure a (static) route with the relevant path MTU specified on the sending system, if possible.  Configuring such routes is not currently possible on a ProxySG or CacheFlow 5000.