[squid-users] Transparent Proxy

[John Sayce]

Yeah, that was the key.  I was expecting my firewall to be doing NAT but destination NAT rather than source NAT.  I hadn't realised this was completely wrong.  

Got it working now.

Thanks


-----Original Message-----
From: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] On Behalf Of Antony Stone
Sent: 08 September 2016 10:00
To: squid-users at lists.squid-cache.org
Subject: Re: [squid-users] Transparent Proxy

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.
_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users