Hey Steve, OK so, for your internal (LAN) traffic, why put it through TPROXY at all? Why not exclude it from the redirect into the TPROXY engine and allow it to proxy through "organically"?
As well you know, if TPROXY sees the traffic in one direction, it needs to see it in the other. My suggestion: Bypass TPROXY for LAN traffic. Nick -- Nick Fennell n...@tbfh.org On 28 Nov 2012, at 16:12, Steve Hill <st...@opendium.com> wrote: > On 28.11.12 13:30, Nick Fennell wrote: > >> The route needs to be Symmetric. >> >> The way I work round this behaviour is to have the Squid box be a part of >> the route for return traffic. This completes the connection and allows >> everything to work. > > I understand the routing requirements required to support the spoofed source > address. Our servers are usually placed between the customer's LAN and the > internet, so traffic between the internet and the LAN does indeed always go > via the server. However, if the client requests an object from a webserver > located on the LAN via the proxy, this routing doesn't happen. It would be > nice for all the clients to be configured to avoid the proxy for access to > local servers, but this isn't something that can be trivially guaranteed. > Furthermore, since the clients are usually on RFC1918 networks, the traffic > will all be NATted to a single global scope IP anyway, so spoofing the source > address gains nothing. Since there is nothing to be gained from the spoofing, > and lots of routing considerations to take into account when spoofing is > used, it is desirable to disable the spoofing functionality in this case. > >> TPROXY transmits requests as the original source IP which will always create >> this problem. > > Does that mean there is no way to disable source spoofing? I require the > proxy transparent from the client's perspective, but it is undesirable to > make the proxy invisible to the server. The client<->proxy connection is > fundamentally separate from the proxy<->server connection and it seems odd > that the configuration of one side of the proxy would dictate the behaviour > of the other to such an extent. > > -- > > - Steve Hill > Technical Director > Opendium Limited http://www.opendium.com > > Direct contacts: > Instant messager: xmpp:st...@opendium.com > Email: st...@opendium.com > Phone: sip:st...@opendium.com > > Sales / enquiries contacts: > Email: sa...@opendium.com > Phone: +44-844-9791439 / sip:sa...@opendium.com > > Support contacts: > Email: supp...@opendium.com > Phone: +44-844-4844916 / sip:supp...@opendium.com
