Right. For this with iptables the standard solution is to run a small proxy on the iptables box, and have iptables extended to allow this proxy to control the source address of outgoing connections.
Unfortunately this functionality isn't easily achievable in iptables at the moment. iptables can reliably intercept TCP sessions, but it cannot easily spoof outgoing connections as the original client or reliably intercept UDP sessions. This is from my understanding the main reasons to the TPROXY work. An option which is readily available and proven is to go for Linux-2.2+ipchains+transparent proxy kernel option, all part of the standard kernel distribution. This allows a proxy running as root (or with CAP_NETADMIN I think) to freely assign the source address using non-local binds. I know that people have succeeded in adopting Squid to use the client's source address in such configurations. If running this on the gateway isn't an option then you can utilize the CONNMARK functionality to divert the to be proxied traffic to another box running the intermediary transparent proxy. Another option, working entirely within iptables, is to write a custom iptables NAT helper module doing the request transformation. For the SSL redirection this is quite simple, simply insert the CONNECT HTTP request initially in the data stream, but the HTTP redirection is somewhat more complex as you then need to account for persistent connections and possibly also transfer encodings of HTTP/1.1, and this again is somewhat beyond the capabilities of netfilter.. (netfilter NAT operates per packet, not that easily on TCP streams where data may cross packet boundaries). While the method of interception and client spoofing used in Linux-2.2 transparent proxy isn't well seen by the TCP/IP stack maintainers or the Netfilter developers, it really works well for dedicated transparent proxies. Regards Henrik Nordström On Wednesdayen den 20 March 2002 10.29, Jean-Michel Hemstedt wrote: > Henrik, > just to recap the goal: > > I have: > - non-proxy aware clients (not controlable) > - non-transparent aware proxy (not controlable, > and even not on Linux, it is not in-housed) > > an in the middle: > - one (or more) default gateway, the netfilter box. > > => goal: > 1) HTTP: rewrite the HTTP requests (PDU) so that they > can be handled by the proxy. > 2) HTTPS: insert the CONNECT transactions so that the > proxy can create its https tunnel to the orig-server. > (and there is no mitma issue) > 3) for both: keep the source ip addresses of the clients > in the modified forwarded packets, so that the proxy > can do simple source based authentication (possibly > with the collaboration of exteral elements such as > radius, but athentication is out of scope here).
