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
