6
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 30 Sep 2024
6 points (100.0% liked)
Tor - The Onion Router
1465 readers
1 users here now
Tips, tricks and information about the Tor network!
founded 4 years ago
MODERATORS
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 ... )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 from127.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.