tcpsocks icon indicating copy to clipboard operation
tcpsocks copied to clipboard

Pretty much all sites have problems

Open Fale opened this issue 9 years ago • 8 comments

Hi,

I'm trying to make this work, but I'm having big problems with this: all attempts to load web pages endup with

tcpsocks: Not SOCKS5 reply from SOCKS5 server

some exception are present. For instance gmail works properly as well as other google pages. I'm not sure where the problem is, because I've the sock5 working (if I set an app to use it, it works perfectly) the firewall has all rules that it needs and I have tcpsocks correctly setup and since google traffic works, I think the tunnel is somehow working properly

Fale avatar Feb 17 '15 23:02 Fale

  • How do you start tcpsocks? Can you provide the command line?
  • What SOCKS server are you using? The first byte in the reply should be 5, otherwise it is not actually a SOCKS version 5 server.
  • Can you start tcpsocks with DEBUG=1 environment variable set to show more messages to console?
  • Can you provide a tcpdump's or strace's log?

vi avatar Feb 18 '15 11:02 vi

Maybe the problem is that I could not have a socks server. I'm using an ssh tunnel as a socks server. I can try the DEBUG thing tuesday morning, but maybe the real problem is that the ssh tunnel does not reply wiith the first byte to "5"

Fale avatar Feb 22 '15 12:02 Fale

I use tcpsocks myself primarily with ssh -D tunnel. It's a primary purpose of tcpsocks to be able to tunnel traffic though ssh -D or through Tor.

vi avatar Feb 22 '15 22:02 vi

Are there any more information? What SOCKS server do you use?

Does redsocks work for you?

vi avatar Mar 04 '15 21:03 vi

I was having the same issue and redsocks worked for me. I found out the reason was because redsocks provided more complete instructions in their README about iptables rules:

iptables -t nat -A REDSOCKS -d 0.0.0.0/8 -j RETURN
iptables -t nat -A REDSOCKS -d 10.0.0.0/8 -j RETURN
iptables -t nat -A REDSOCKS -d 127.0.0.0/8 -j RETURN
iptables -t nat -A REDSOCKS -d 169.254.0.0/16 -j RETURN
iptables -t nat -A REDSOCKS -d 172.16.0.0/12 -j RETURN
iptables -t nat -A REDSOCKS -d 192.168.0.0/16 -j RETURN
iptables -t nat -A REDSOCKS -d 224.0.0.0/4 -j RETURN
iptables -t nat -A REDSOCKS -d 240.0.0.0/4 -j RETURN

Adding those rules first should solve your problem. Specifically, I narrowed it down to iptables -t nat -A REDSOCKS -d 127.0.0.0/8 -j RETURN which solved the problem for me.

gsingh93 avatar May 06 '17 20:05 gsingh93

Maybe tcpsocks's own connections were also redirected by iptables?

One solution was to run tcpsocks as a separate user and to something like iptables -t nat -m owner --uid-owner tcpsocks -j RETURN. In the example in README the SSH connection itself was specifically excluded. Noticed that localhost was not exlucded, added one more rule: iptables -t nat -A QQQ -d 80.83.124.150 -p tcp --dport 22 -j RETURN.

To debug tcptables configuration, one needs output of iptables -t nat -S.

vi avatar May 06 '17 22:05 vi

Note: redsocks may be more maintained solution. If it works for you, you may want to stay with redsocks. I developed tcpsocks because of I was not aware of redsocks.

Reasons to use tcpsocks:

  • You don't want to deal with configuration files and want to specify everything on command line
  • You like debugging output of tcpsocks
  • You want interactive command-line control of connections
  • You don't want libevent-based things for some reason

vi avatar May 06 '17 22:05 vi

Maybe tcpsocks's own connections were also redirected by iptables?

Yes, that's exactly what happened.

One solution was to run tcpsocks as a separate user

Makes sense, but most people do a quick test of the software first before setting something like that up. In this case, the localhost rule is necessary.

Thanks for the software :)

gsingh93 avatar May 07 '17 05:05 gsingh93