-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29/08/2014 11:09 a.m., Julian wrote: > Hi Eliezer, > > I understand what you say, but we use external IPs for our network > hosts (nothing in 192.168.x.x range). How is any of the software along the HTTP traffic route supposed to know that? > What I need is to direct the traffic to our proxy using the wpad > mechanism (which works just fine for us) but to make our proxy > completely transparent to external destinations. I think TPROXY > Squid might be a way to do it, but we only use Squid 2.7 now. The IP spoofed by TPROXY is the IP received on the TCP packets, it is not necessarily the end users IP. TPROXY is also incompatible with manual and WPAD configuration. TPROXY traffic has CVE-2009-0801 security checks applied to it, which on explicitly configured proxy traffic will lead to infinite forwarding loops as the proxy transparently relays to its own IP. Going back to your original post there are two incorrect statements which may be confusing you... 1) > Proxy Auto-Discovery on our users browsers is able to get activated > by a wpad.dat file which transparently redirects our users HTTP > requests to our > Proxy Server. WPAD is sometimes called "transparent configuration". Emphasis on configuration. There is no redirect happening at all, anywhere. The client software is explicitly using "Automatic Discovery" (the __AD) to locate the proxy it is going to tranfer through without the user having to do anything. > > The way our Proxy Server works now is by hiding the IP address of > users getting directed to our machine. What the proxy does is called "Application Layer Gateway". From the outside it looks a bit like what NAT does, the TCP layer IP:port address changes to one for the gateway service (aka Squid) so that TCP reply packets are able to return to the proxy. What you want is just not possible at all with Squid-2.7 and unlikely to be possible with any newer release either. Consider what happens when the proxy generates a new connection: TCP SYN packets with the client IP on them ... the TCP SYN-ACK packets get sent straight back to that client IP ... then what? connection hangs. > > We want to keep running with our Proxy in the same deployment > scenario, except that we need external Internet destinations to see > the requests coming from our hosts IP(s) instead of our Proxy. > HTTP is designed to operate with multiple intermediaries in similar ways to how SMTP and DNS operate with proxies/relays/recursive-resolver. The X-Forwarded-For header(**) is how HTTP relays details about the *sequence* of client IPs which are used to reach the origin server. <http://tools.ietf.org/html/rfc7230#section-2.3> So, Why are you requesting this? what real problem are you trying to solve that makes you think about spoofing the client IP? Amos -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT//kKAAoJELJo5wb/XPRjYwQIALlPG52K65lcke/cjBTbcGFI BCP+dP9GT5SaI2zW+QrV9i/wmw5g9YdHGvssbMblIn2HTuYdTXdjXgUCXTc1LjsI c7KU55apgyViVqgb6XWSPixTPOeaAXJu2RoqxoOD9IWxjbr93Ut5zw1O9dTqxYNX fJbGcKDHeJ8z0QMk3IKp89+GozUc2G0K1eVk+hREQWjt2J2KZmZIY3DonMfUAmqM i3BaBtJ2PFfATbkNQ1kJ1MwGFonrafmIakfDU1wp0MvUvjV9msKwA7e+S9xAqgD+ ivW7hKGJBQi0I7VJbWhhHcENrWa6nCQHGq1HJZ6vfObHCFGQ7knW4/QB+uTn/JI= =Teo/ -----END PGP SIGNATURE-----
