[squid-users] Intercept mode failing

Tue Jan 3 22:36:13 UTC 2017

If you get stuck with things contact me and I will see if I can sort things out so you would be able to grasp couple basics.

Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: eliezer at ngtech.co.il

-----Original Message-----
From: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] On Behalf Of Hoggins!
Sent: Tuesday, January 3, 2017 3:13 PM
To: squid-users at lists.squid-cache.org
Subject: Re: [squid-users] Intercept mode failing

Hello Amos,

I believe my main problem is that I'm trying to apply recipes without understanding some of the internals, so it seems difficult to adapt.
I'll keep searching.

Thanks anyway !

    Hoggins!

Le 03/01/2017 à 12:39, Amos Jeffries a écrit :
> 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
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>