Sniproxy with transparent proxy

[oakaigh]

How can I correct configure sniproxy for transparent proxy redirection support?
I added source client but it didn’t work.
In the backend I added

.* 0.0.0.0:1080
# 0.0.0.0: 1080 is my local transparent proxy address

[dlundquist]

Transparent proxy support is enabled when the "source client" directive is included in the listener stanza. It uses the socket option IP_TRANSPARENT to open the connection to the backend server sourced from the original client address. For this to work sniproxy must be running on a host in the return network path from the backend server to the client and requires the IPtables mangle table to be configured appropriately. I don't use this feature myself, but merged it because it was useful in some applications and didn't contribute significant complexity to the code base.

Your table configuration is highly unusual. When combined with the source client directive you are asking SNIproxy to receive a connection $CLIENT_IP -> $PROXY_IP and proxy that data to a new connection $CLIENT_IP -> 0.0.0.0:1080. The 0.0.0.0 address is the unspecified address and has special meaning for listening sockets of and/all the IP addresses configured on this host, but outside some boot protocols like DHCP where a host doesn't have an IP address yet the 0.0.0.0 address is not usually seen on in packets sent along the wire. In classful IP routing this represent the entire IPv4 internet (0.0.0.0/0 or 0.0.0.0-255.255.255.255). Opening a TCP connection to the this address will mostly probably fail since most network stacks do not permit the unspecified address to be configured on an interface so the source address of the SYN-ACK packet wouldn't match the destination address of the SYN packet; so the SYN-ACK will not appear to match an existing TCP session.

Writing this, I'm realizing that perhaps you obtained from another daemon configuration or netstat/ss or a similar tool where it represents a listening socket on that will accept connections on any IP address configured on the host. In this case, you should replace 0.0.0.0 with the address on that host on the nearest network segment to the host sniproxy is running on or 127.0.0.1 if they are running on the same host.

One final speculation: TCP port 1080 is usually used for a SOCKS proxy. SOCKS is a proxy protocol and requires the client payload to be encapsulated inside the SOCKS protocol. Unless you have a SOCKS protocol configured for transparent proxy, in which case it wouldn't necessarily need to run on TCP port 1080, proxying from SNIproxy to a SOCKS proxy isn't going to work. If you have a transparent SOCKS proxy server, then what is the point of using SNIproxy to proxy all traffic transparently to another transparent proxy, just divert it your SOCKS proxy.

I've made a lot of speculations on what your trying to accomplish here, I appologize if they are incorrect or I've gone into unnecessary detail in unrelated areas. Best of luck.

[oakaigh]

Thanks anyway.
I reconfigured sniproxy by adding and modifying these lines:

user root
group root
source client
# ... too many lines here
.*            *
# I configured iptables to redirect all the traffic

It’s like:
client (e.g. Want some Google!!!) -> [ sniproxy -> transparent proxy client ] -> (proxied traffic) -> proxy server (actually Shadowsocks) -> destination host (e.g. www.google.com)

[] means in-server operation.

[oakaigh]

Whatever... all problems have been resolved! Thank u. Heavy typing task... thought you scored higher in the SAT writing section than other students did at that time 🤣

[dlundquist]

Glad you got it working. It was the user root line that did it, the capabilities branch #229 is still open. Sorry I didn't think of that one sooner, but this isn't a feature I use. Fortunately there is a test for it.

[mrbluecoat]

@PantherJohn can you elaborate on I configured iptables to redirect all the traffic? What iptables rules did you use specifically?

[mrbluecoat]

In the meantime, I'll try https://github.com/dlundquist/sniproxy/blob/master/tests/transparent_proxy_test#L176-L183

[oakaigh]

@mrbluecoat Can't remember the details of the configuration. It's been a year now I don't even know why I tried tproxy in the first place.

Per source code @dlundquist is using Linux's tproxy API but the iptables rules I set last time were still using REDIRECT (although it could have worked with some minor changes: set socket option SO_ORIGINAL_DST and ditch the tproxy routine that requires you to use IP_TRANSPARENT and IP_RECVORIGDSTADDR at the same time).

@dlundquist So as we are using TCP we have two options

• SO_ORIGINAL_DST
• IP_TRANSPARENT

SO_ORIGINAL_DST saves a lot of hassle: the redirection can now be done in just one line:

     iptables -t nat -A PREROUTING -p tcp -j REDIRECT --to-ports 65535

and the code now is just three lines

     int fd = socket(AF_INET, SOCK_STREAM, 0);
     /* listen(fd, ...); accept(fd, ....); blah blah blah */ 
     getsockopt(sockfd, SOL_IP, SO_ORIGINAL_DST, destaddr, &(socklen_t){ sizeof(*destaddr) });

Examples here
https://github.com/eLitetInc/shadowsocks-libev/blob/4aa13d38f92e0d97347539271f00d12bc1246c25/src/netutils.c#L98-L172

I suggest you implement both.