[squid-users] Transparent Proxy

[Antony Stone]

On Thursday 08 September 2016 at 10:44:12, John Sayce wrote:

> After I wrote this I realised it should be changing the mac not the ip,
> which is not what’s happeneing.  I think it's my firewall configuration
> that's wrong.

In that case your firewall is doing NAT instead of policy routing.

Regards,


Antony.

> -----Original Message-----
> From: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] On
> Behalf Of Antony Stone Sent: 08 September 2016 09:36
> To: squid-users at lists.squid-cache.org
> Subject: Re: [squid-users] Transparent Proxy
> 
> On Thursday 08 September 2016 at 10:12:48, John Sayce wrote:
> > For testing purposes I've reduced it to the following:
> > 
> > http_port 3128 intercept
> > #dns_v4_first on
> > dns_nameservers 10.8.2.3 194.168.4.100 10.8.2.2 8.8.8.8 acl wifi src
> > 10.8.14.0/24 acl all src all http_access allow all maximum_object_size
> > 1 GB minimum_object_size 0 KB maximum_object_size_in_memory 4 MB
> > cache_mem 1700 MB cache_dir aufs /var/cache/squid 40000 32 512
> > coredump_dir /var/cache/squid access_log /var/log/squid/access.log
> > squid cache_log /var/log/squid/cache.log
> > refresh_pattern ^ftp:           1440    20%     10080
> > refresh_pattern ^gopher:        1440    0%      1440
> > refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
> > refresh_pattern .               0       20%     4320
> > cache_effective_user asd
> > cache_effective_group asd
> > cache_mgr jsayce at asdlighting.com
> > forwarded_for off
> > 
> > The version is 3.5.12
> > 
> > Okay.  Sorry, to clarify with a specific example.
> 
> Don't apologise - specific examples are good, because it makes sure we're
> both talking about the same thing (and sometimes, as below, reveals little
> details about the network arrangement which weren't previously clear).
> 
> > Lets say I'm contacting http://1.1.1.1/ then the ack packet starts off
> > with the client with ip address 10.8.14.9
> 
> So, source IP = 10.8.14.9 : destination IP = 1.1.11
> 
> > in subnet 10.8.14.9/24 with default gateway 10.8.14.1.
> > It's routed through my core switch to my my firewall with ip 10.8.1.1.
> 
> So that's a router, not just a switch?  It has one interface 10.8.14.1 on
> subnet 10.8.14.0/24 and another interface on (presumably) 10.8.1.0/24
> pointing at 10.8.1.1 as the next-hop route towards 1.1.1.1
> 
> > My firewall recognises that the packet has a destination port 80 and
> > is in subnet 10.8.14.0/24
> 
> The source address is in that subnet, yes.
> 
> > and changes the destination address to be that of my proxy server
> > 10.8.2.11.
> 
> No - see below.
> 
> > So now the ack packet has source 10.8.14.9 and destination 10.8.2.11.
> 
> No, it doesn't.  When a packet goes via a router, its destination IP
> address is not changed to the address of the next-hop router (otherwise
> things would never work across the Internet).
> 
> It's only the destination MAC address in the encapsulating ethernet frame
> which gets changed to that of the next-hop router.  The source and
> destination IP addresses inside are not touched.
> 
> > How does iptables know to reply to my client 10.8.14.9 with source
> > address 1.1.1.1?  Does iptables know to read the header?
> 
> TCP header, yes.
> 
> HTTP header, no.
> 
> Just think about the very first link between the client and its default
> gateway:
> 
> Packet with source address = 10.8.14.9, destinatoin address = 1.1.1.1
> 
> How does that packet get to the default router 10.8.14.1?  Its destination
> IP is 1.1.1.1, so that doesn't help.
> 
> It's because the destination MAC address in the ethernet frame containing
> that IP packet is the MAC address of 10.8.14.1.
> 
> A few minutes playing around with wireshark on your network could be quite
> enlightening :)
> 
> 
> 
> Regards,
> 
> 
> Antony.

-- 
"Reports that say that something hasn't happened are always interesting to me, 
because as we know, there are known knowns; there are things we know we know. 
We also know there are known unknowns; that is to say we know there are some 
things we do not know. But there are also unknown unknowns - the ones we don't 
know we don't know."

 - Donald Rumsfeld, US Secretary of Defence

                                                   Please reply to the list;
                                                         please *don't* CC me.