Anybody has any news regarding this issue ?
Hi Shimano,
Thank you for providing the additional details. I see from your replies that you are experiencing much the same issues as me, including the variations of behaviour across multiple platforms. I see no need to further badger you with interrogatory questions about why you're using a caching proxy, just to have you answer with the overtly obvious purpose of what a caching proxy does, so I'll move on to focus on the technical aspects of TCP/IP that would exhibit this type of performance behaviour differences between a router and a proxy, based on some years of experience working in multi-platform / multi-os environments and seeing this problem crop up when mixing various network connectivity topologies.
The basic jist is that although TCP/IP is the communication protocol that is common to all devices involved, how each OS & device implements it's version of TCP/IP tends to be unique; with Windows being a common culprit to suffer the most issues when something doesn't work right.
What I'm eluding to is a quite common problem in a mixed platform environment when using a proxy vs. a pure switch / router. To be more specific about the TCP/IP protocols involved in this type of problem are things like MTU/MSS size, Path MTU discovery (PMTUD) (aka Black Hole Detection), traffic congestion controls, etc.
First, to understand the difference in behaviour between using squid and pfSense as a pure router; I'll clarify that Squid Proxy is not a router, so trying to compare pfSense acting as a pure router vs. a caching proxy is going to lead to chasing red herrings.
To explain a bit more detail; When only routing, TCP/IP protocol negotiation takes place between the client and the server, transiting the router. So things like PMTUD and congestion controls are negotiated end to end (client <-> server).
But a proxy is an intercessor in the communication links between the client and server, such that the communication links are split up into two portions; the client to the proxy, and the proxy (acting as an external client on behalf of the internal client) to the server (client <-> proxy <-> server).
So, when the client negotiates it's TCP session, when transiting through a router, there is a single TCP session between client and server, but when using a proxy you have two separate TCP session, one from the client to the proxy, the other from the proxy to the server. Both of these sessions must independently negotiate their TCP session parameters.
Thus it is in the nature of the differences of various OS TCP/IP implementations is where all the fun begins.
Squid is known for not playing well with PMTUD, especially if there is an upstream link, such as a VPN, involved that may be reducing the expected packet sizes, or interfering with PMTUD. As well, Windows is somewhat notorious for signification performance issues if PMTU / Black Hole Detection, et all, can not be negotiated correctly. Which is why Windows seems to be more impacted than 'nix clients. And on occasion, you may even need to disable PMTUD / Black Hole Detection when using a proxy, to work around packet sizing issues that may not be otherwise resolvable.
And that's the short answer.
Much more involved answer includes digging into the protocol handshake to verify if PMTU discovery, among other things, is taking place or not when squid is used. This involves doing some diagnostic testing to verify that TCP/IP packets are not being fragmented upstream, as well as packet traces of the communications from squid to the target server to see if proper packet sizing negotiations are taking place or being interfered with in some way.
Since these are pretty common problem, there's already quit a bit of info on the internet about dealing with PMTU / Black Hole Detection problems that you can search for. To get you started, here's a good article describing these type of issues with squid & windows.
https://squidproxy.wordpress.com/2007/06/05/thinsg-to-look-at-if-websites-are-hanging/
Anyway these types of problems tend to be site / link specific, so you'll have to do some digging on your end to verify if this is the problem that is occurring for you.
And if you still need help diagnosing your issue, I would suggest that you provide more detail about your use case configuration, and how you are using your VPN link, in order for others to understand where your in/out packet flows are between your internal, external & VPN networks, and better understand where protocol negotiation issues may be occurring.
