Feature req: Spoof original source IP on internal connection

[Steltek]

Rather than try to pass the source IP via a header (which isn't possible without decrypting and mangling the HTTPS traffic), would it be possible to add an option to have sniproxy spoof the original source IP on the internal requests? That way, the target server could see the source IP.

(Of course, the user installing sniproxy would have to ensure it is 'in-path', i.e. all return traffic from the internal server gets funneled back to sniproxy for processing, and the OS allows for such spoofing.)

Example:
Client IP: 8.8.8.8
Gateway external IP: 80.80.80.80 (internalserver.domain.com)
Gateway internal IP: 10.0.0.1
Internal webserver IP: 10.0.0.2

• sniproxy installed on gateway.

1. TCP packet from client IP to 'internalserver.domain.com': src IP 8.8.8.8, dst IP 80.80.80.80 port 443
2. sniproxy opens an internal connection (on internal interface): src IP 8.8.8.8, dst IP 10.0.0.2 port 8443
3. Internal webserver responds: src IP 10.0.0.2, port 8443, dst IP 8.8.8.8
4. Packet arrives on GW which uses rule to redirect traffic from internal port 8443 to sniproxy
5. sniproxy sends response to Client via external interface: src IP 80.80.80.80 port 443, dst IP 8.8.8.8

-> The server thinks it is talking to 8.8.8.8 but in reality has all its return traffic intercepted by the gateway and sent to sniproxy instead.

References: haproxy's transparent mode:
http://blog.haproxy.com/2011/08/03/layer-7-load-balancing-transparent-proxy-mode
http://blog.haproxy.com/2012/06/05/preserve-source-ip-address-despite-reverse-proxies/

[akarl10]

Since I needed the same I implemented a proof of concept. If no source address is given in the configuration sniproxy tries IP_TRANSPARENT (in this quick and dirty try I always set this option on the listening socket, but this shoud no do any harm)

note that setting the flag requires root privileges, so if you like to test you must run it with "user root"

if needed I can also do a pull request with a cleaner method, but for now the patch as txt attachment.
tproxy.txt

the usual iptables TPROXY setups should work.

[dlundquist]

@akarl10 You've convinced me this is a significantly invasive change. I've pushed a new branch containing this change enabled in the configuration by listener "source client". Would you mind testing this?

[akarl10]

looks good.

There is one thing that maybe should be documented as well:
looking around there is currently no way to set the resolv_mode on a single resolv_query call. That would be needed to enforce the same address family would be used on the outgoing socket (a minor problem easily resolved by using a instance for sniproxy for every address family).

according to man 7 ip IP_TRANSPARENT should also work with cap_net_admin, but I had no success setting this capability using setcap on the binary. Maybe this has to be set with cap_set_proc() call before changing to user. I will look into that next week

[akarl10]

I made some experiments running IP_TRANSPARENT without root.
Doing so requires a new depenency (libcap)
I discovered that the man page is wrong about the needed capability: CAP_NET_RAW is the required capability, not CAP_NET_ADMIN

capabilities.txt

[dlundquist]

@akarl10 Thank you for the follow on patch. I would like to include a test script and autoconf feature switches so we can easily setup a test environment for this and so this doesn't break newer versions for non Linux users before merging this into master. Since there is a source address conflict when using IP_TRANSPARENT on local connections I was thinking of a test script (maybe modification of functional_test) which utilizes network namespaces and veth interface pairs to mock out a three host test setup. Thanks for including the autoconf config for libcap, that is a significant portion of the way there for not breaking non-Linux users. I haven't had much time to dedicate to sniproxy lately, but would like to see this one merged.

[fiforms]

Just want to say I'm very please with this new feature. I have a build from the "tproxy" branch running in production as we speak. I'm using "source client," and it does what I expected, allowing separate servers on a private LAN to share a single public IP, while not losing the ability to read REMOTE_ADDR from scripts on the internal servers. This is very useful. Thanks!

[dlundquist]

@fiforms Thank you for the positive report.

[dlundquist]

@akarl10 I've put together a functional test for transparent proxy operation using network namespaces, and found the setsockopt(..., IP_TRANSPARENT, ...) call was not needed on the listening socket. There is still some work in aligning capabilities and the binder process.

[akarl10]

@dlundquist I've made some comments on a commit but I cannot find the comments anymore (I never commented commits on github, maybe I made something wrong)

Yes, the listening socket does not need IP_TRANSPARENT,
the other thing I commented was that the only reason bind fails after setting IP_TRANSPARENT that succeeds is when running on the same host. That means that in connection.c you should ignore the case if bind fails when IP_TRANSPARENT succeeds. This would have the advantage that connections from the same host are possible with the loose of the "transparent" functionality, but the src address will be right since its local :)