[squid-users] Intercept mode failing

[Amos Jeffries]

On 2017-01-03 23:53, Hoggins! wrote:
> Hello,
> 
> (answering to both Amos and Antony here, you got the same questioning 
> ;) )
> 
> Le 03/01/2017 à 11:45, Amos Jeffries a écrit :
>> On 2017-01-03 23:13, Hoggins! wrote:
>>> Okay, I get that.
>>> 
>>> Le 03/01/2017 à 10:33, Antony Stone a écrit :
>>>> No - you must do the NAT (or REDIRECT) rule *on the Squid server*.
>>> 
>>> Well, my Squid server is not on the same network as my clients, so I
>>> need something else than just a REDIRECT on the Squid itself.
>> 
>> That does not matter when the DNAT or REDIRECT is done on the Squid
>> machine.
> 
> OK, I'll have a deeper look into that, indeed I'm not familiar with 
> what
> REDIRECT *exactly* does.
> 

It does the same as DNAT, but using the machines "primary" IP address 
instead of one you configure. Usually that means the first IP assigned 
to eth0 or equivalent first interface.

DNAT is best if you want a specific fixed IP:port for Squid to receive 
on.

REDIRECT is best if you want the proxy to be plug-n-play on any network. 
squid.conf and iptables not needing IP address, just a port number.


>> 
>>> 
>>>> 
>>>> If you need to use policy routing to get the packets to the Squid
>>>> machine in
>>>> the first place, that's okay, but this *must* be packet routing, not
>>>> address
>>>> translation
>>> 
>>> Policy routing was my first choice, but there is one important detail 
>>> in
>>> my setup : between my gateway (192.168.22.10) and my Squid
>>> (192.168.55.3), there's an IPSec tunnel. My gateway does not have a
>>> link-local route to 192.168.55.3 so I can't add the default route to 
>>> it
>>> inside a routing table (I get "Network is unreachable", which is
>>> expected).
>>> 
>>> So I guess I'm stuck.
>> 
>> 
>> So how did the packets get to the Squid machine after your DNAT ?
>> 
>> The route does not have to be link-local. Any type of route will do so
>> long as all the routers handling the packets know which way to pass
>> them, and the dst-IP address is not changed.
> 
> Well, xfrm routing is a lot different than "classic" routing, I learnt
> it the hard way. DNAT *will* work whereas policy routing won't if I
> don't explicitly declare all my subnets in my IPSec tunnel
> configuration. Got a big discussion about that on StrongSwan's
> mailing-list, and I believe this sums it up pretty nicely :
> http://xkr47.outerspace.dyndns.org/netfilter/packet_flow/packet_flow9.png

Looks like a simplified version of the netfilter devs official diagram 
to me. So all the required decision points are present and should be 
configurable.

> 
> Anyway, yes, if I try to add a route by :
>     ip route add default via <IP ADDRESS> table 123
> 
> <IP ADDRESS> *has* to be directly reachable. Or it has to be in the
> routing table somehow. But the routing table handling the tunnelled
> packets is not managed by iproute2.

It should "simply" be one of the tables with a value other than "123". 
But that should not be a consideration as editing it is not necessary. 
This "123" routing is only relevant *before* packets enter the tunnel, 
since it is what tells the OS to send packets to the tunnel.

IIRC the routing table for HTTP traffic (your '123' table) should 
indicate the tunnel as the gateway <IP ADDRESS>. I don't recall whether 
that gw was needing to be the local or the remote tunnel endpoint though 
sorry, been too long since I set one of these up.

> 
> So as I can't do otherwise, I'm going to experiment a bit more with the
> REDIRECT + DNAT between the gateway and the Squid server.
> 

I think you are misinterpreting that diagram in regards to the policy 
routing setup.

What we have on the squid wiki on "Policy Routing" makes packets follow 
this path;

  * the PREROUTING "mangle" table sets marks on packets to be delivered 
to Squid.

  * those packets go through the "FORWARD" to that gateway in 
'123'/'proxy' table.
   (in our wiki that is the "ip rule add fwmark 2 table ..." part).

  * after POSTROUTING the packets destined to a tunnel gateway are 
diverted at that last-minute decision point after "QoS egress" so they 
go back to "OUTPUT" which is where the tunnel related things are done to 
it.

Note that for the machine where the tunnel leads *from*, all that 
matters is routing the packets into the tunnel. Once packets are 
encapsulated by the tunnel they simply go through it to the other end. 
The receiving machine does whatever it needs to after the packets leave 
the tunnel.

HTH
Amos