Re: [squid-users] Re: transparent proxy on remote box issue

On 24/10/2013 3:45 p.m., WorkingMan wrote:
>>> 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 ...
> "redirection" is done from VPN server to SQUID server. I don't have special
> routing on SQUID's server the reason is that from VPN server I can query
> external web site if I use non-intercept port (I have one that has
> "intercept" and one without). So I assume routing is working fine.

That means routing of packets out of Squid to Internet is fine.

Routing of packets between the client and Squid on port 80 is a
completely different story. You *need* to know what is going on there to
be sure that Squid is even receiving the right packet details.

> The
> command I used is
>
> curl -x http://<SQUID IP>:PORT www.cnn.com

What you need is this command to work and the packets to reach Squid
with destination IP:port of www.cnn.com:

   curl www.cnn.com

> Let me know if I need to add additional iptables rule for this to work. If I
> enter the proxy info wrong curl just waits there (probably till timeout). If
> address/port are correct but SQUID was not running I will get connection
> refused. So it tells me routing from VPN to SQUID for port 80 seems to work
> but "intercept" is the reason I get access denied (I can't figure out why
> yet even with full log). Where in the full log can I know why I get access
> denied?

The curl parameters "-x http://<SQUID IP>:PORT" tells curl to format an
**HTTP proxy syntax request** and send it to that IP:port. Routing
non-Squid IPs and interception are never involved.
  Sending such a request to an intercept port *will* always fail because
the destination IP:port at the TCP level are "<SQUID IP>:PORT"... it
will infinitely loop back to <SQUID IP>:PORT when leaving the proxy.

Port 80 uses different syntax for requests and the IP:port delivered are
the remote origin server 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 ?
> When I say hostname is missing. It means I get (see my first post)
>
> NONE/400 3544 GET / instead of TCP_MISS/403 3544 GET www.cnn.com/

Ah.
This is a port 80 syntax request:

  GET / HTTP/1.1
  Host: www.cnn.com
  User-Agent: curl ....
  Accept: */*

As you can see the "http://www.cnn.com" part does not exist and must be
figured out by the proxy from other data sources.
  Squid uses TCP packet destination IP:port details, or Host header but
only if Host DNS records match the TCP packet IP:port.

When the above request is delivered to Squid in packets with TCP
destination IP of <SQUID IP>:PORT you get a loop, from client to Squid
to Squid where its rejected the response goes back to Squid then client.

> I also use "cache deny all" (and http_access allow all, I assume that allows
> access to everything, see my first post for full config I have except these
> two) to use no cache not sure if that affect the out come?

Not for these routing and TCP problems. This is about what data is given
to Squid to figure out the real URL for outbound relaying. That is done
very first thing on request arrival.

I think you need to take a step back from both Squid and the intercept part.
1) Ensure that the Squid box is setup with *ony* the packet routing port
80 packets from the VPN to Internet and Internet responses back down VPN
tunnel.
2) Ensure that a client request for any web URL gets routed down the VPN
to the Squid box AND successfully connects directly to that domains servers.

Note that Squid and NAT/TPROXY interception should both be turned off
while all that is being setup and tested. I cannot stress enough that it
MUST work without the proxy if the proxy is going to have any chance of
working reliably when it is used.

Only when both of the above are checked and found working can you start
configuring interception and proxy on the Squid machine.

Amos
Received on Thu Oct 24 2013 - 08:00:14 MDT