On 24/10/2013 9:45 a.m., WorkingMan wrote:
> It appears that one of the test I was doing is not correct so it can yield
> some hint to the problem. "-k reconfigure" didn't take effect when I made the
> change. So for the browser with direct proxy setting. I am able to browse
> correctly if not using "intercept" (ie: using SQUID server's public IP
> directly).
>
> Everything else is still the same as described above. So there are two issues
> that I can observe.
>
> 1) why intercept mode fails (do I need any special rule on my remote SQUID
> box?) with access denied for all requests
Where is the NAT/TPROXY interception happening for (1)?
It is required to be done directly on the Squid machine, with packets
sent to that machine by *routing* or *tunnelling* (VPN) in such as way
as the TCP packet IP:port details st by the client are completely
untouched by the network before they hit the Squid machine.
Typically in the past your type of setup has used NAT at the client end
(it was "easy"), which actually erases the destination IP details and
replaces them with the Squid machine IP:port. The problems this caused
were hidden for a long time but recent security checks are preventing
the Host header being used to determine the outbound connection when
they occur. For now Squid preserves the behaviour the client would have
seen by going to the TCP destination IP:port ...
> 2) in non-intercept mode why VPN client would have the missing hostname in the
> request.
>
(2) is not clear what you mean. What do you see that is indicating a
missing hostname ?
Amos
Received on Thu Oct 24 2013 - 00:06:13 MDT
This archive was generated by hypermail 2.2.0 : Thu Oct 24 2013 - 12:00:07 MDT