-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to proxy traffic from the local host via TPROXY? #1473
Comments
Ah, it seems that you have found this example script. I don't know what was really happening with your provided detail. My suggestion is to make a very simple rules that could match and bypass all traffics to |
I'm not sure how I can tell if traffic actually arrives sslocal. It's possible the problem is with sslocal, or with iptables, but how do I tell? After reading more about redirection in iptables though, I suspect the problem lies with it. From what I've read, to transparently proxy UDP, you need to have the rules in the mangle table of the PREROUTING chain. However, this only works for incoming traffic (e.g. on a router), and can't be used for hosts. It looks like the script somehow tries to work around this limitation, but I don't see how? I'm no expert in iptables, though. |
Just run sslocal with -vvv, it will log out the packet when it receives from iptables. |
So when using Everything I've read makes it sound like such local redirection isn't possible with iptables, and so far that has been my experience as well. Does anyone have a working set of rules that proves otherwise? |
I can confirm https://github.com/shadowsocks/shadowsocks-rust/blob/master/configs/iptables_tproxy.sh works in my environment. Tested on Ubuntu, Debian, OpenWRT. |
OpenWRT? Are you running the transparent redirection on your router? |
Yes, indeed. |
That makes sense then, as that isn't local redirection. I don't think local redirection via tproxy is possible with iptables. |
Process on OpenWRT, like dnsmasq, their requests also processed by |
The script worked for me, in both TCP and UDP. I'm using only one machine and local packets can be processed with TPROXY. |
|
Ah sorry I was running ssserver in the same machine. You don't need it otherwise, and your script seems perfect. |
What would tcpdump show me that I don't already know? iptables simply isn't redirecting traffic from localhost to sslocal. Why? I don't know. In any case, I've given up on trying to use iptables to get this working. |
FYI, this is a packet capture of typical working TPROXY in iptables (not shadowsocks but normal SOCKS5).
The important thing is that transparent proxy port (in your setting, |
I know what it should look like, but that doesn't change that iptables isn't redirecting it. I'm now just trying to get this to work on FreeBSD with pf instead, but it doesn't look like there is any documentation on what the firewall's rules should look like. I assume a simple |
My recommendation is creating another IP address for TPROXY.
|
I'm trying to proxy all traffic (other than that destined for a private IP) from the local machine through shadowsocks. That is to say,
sslocal
is running on the system that I want outgoing traffic to be proxied on, and not a separate system/router. Initially I was using shadowsocks like this:sslocal -b "127.0.0.1:1080" --protocol redir -s "192.168.x.y:8388" -m none --tcp-redir "redirect"
, with iptables rules taken from redsocks (and only slightly modified), i.e.:This works, but obviously only proxies TCP traffic. As I'd like to also proxy UDP, I went looking first for what iptables rules should look like, and found this script, which I modified slightly as I'm not trying to bypass the GFW:
As this uses TPROXY, I changed my shadowsocks command a bit too:
sslocal -b "127.0.0.1:1080" --protocol redir -s "192.168.x.y:8388" -m none -U --tcp-redir "tproxy" --udp-redir "tproxy" --outbound-fwmark 255
(and yes, I remembered to add-U
to the system runningssserver
as well). I cleared the redsocks rules out of iptables, ran the script for the new rules, and restartedsslocal
with the new command.However, this does not work for proxying, either TCP or UDP. I also tried uncommenting those last two rules that are commented out (as I'm not sure if they need to be there or not), and rerunning the script, but it didn't seem to make any difference. So, does anyone know what I'm doing wrong?
The text was updated successfully, but these errors were encountered: