Tor - The Onion Router @lemmy.ml Gordon_F @lemmy.ml 2mo ago

Stuck at Opened Socks listener connection (ready)

Hi,

I've just installed tor ( 0.4.5.16 )

When I launch it ( debian fork ) I'm stuck at

Opened Socks listener connection (ready) on 127.0.0.1:9050

I have a strong set of nftables maybe that what block it ?

What should open in order to have tor connect ?

Thanks.

4 comments

generally Tor will appempt to connect on 443, 9001 and possibly others for traffic, but that depends on the remote node its connecting to (nodes can specify their port). you only need to open/forward if you plan on receiving unsolicited traffic - still a good idea, but Tor should have the ability to initiate traffic to remote hosts on a few ports (e.g. 443, others) to establish a connection to the Tor network.

9050 is your socks proxy - so protect it. if your nftables is blocking localhost:9050/TCP then you need to correct that.

your applications then connect to localhost:9050 and Tor will proxy traffic for them.

edit: take a look at your Tor logs and see what its telling you. Tor usually produces reasonable quality logs for troubleshooting.

edit edit: if you are just looking to browse via Tor, an easier, more secure out of the box option is the Tor browser bundle. anonymity can be accidently broken, for anyone - even the most careful. if this is just a learning exercise, then carry on :-)
- Thank you very much @qprimed@lemmy.ml ! indeed I saw in my nftables log tentative to 443 and 9001. ( I didn't find this in the tor doc ... )
  
  9050 is your socks proxy - so protect it. if your nftables is blocking localhost:9050/TCP then you need to correct that.
  
  is this will do : ip saddr 127.0.0.1 ip daddr 127.0.0.1 accept ?
  
  that will work. always test your FW rules after a change. never just trust it.
  
  netcat is your friend for a quick test to port 9050/TCP from a different PC if you are listening on more than just the loopback. careful with the loopback source addy AFAIK there is no guarantee that local host traffic to 127.0.0.1 will be sourced from 127.0.0.1 - I may be wrong here, but be safe.
  
  regardless, depending on your rules, you will either get a timeout, instant connection reset or connect. obviously connect is bad if you think the traffic should be blocked, refusal is ok as long as the daemon is actually running (FW on a non-listening port can generate a TCP RST so its somewhat ambiguous), timeout is best as you know as long as the host is up, the FW is likely dropping traffic.
  
  a more comprehensive test against any local host would be done with nmap.
  
  sounds like you are poking things with a stick - thats awesome! happy to help :-)
  
  edit: clarify loopback.
Damn

now that I open few ports 9001

I see incoming connection that are dropped because they use totally diffrent ports

drop: IN=eth0 OUT= MAC=aMacadrs SRC=aIP DST=aMyIP LEN=64 TOS=0x00 PREC=0x00 TTL=48 ID=65508 DF PROTO=TCP SPT=443 DPT=50194 WINDOW=501 RES=0x00 ACK URGP=0

privacy

I've replaced some string with 'aSomething'

.

it's weird in my nftable config file I have

type filter hook input priority 0; policy drop; ct state established,related accept

Any ideas ?