killall tcpdump; \
reset; \
tcpdump -i any port 80 or port 443 or port 9040 & \
curl --insecure --verbose https://www.youtube.com/ 1>/dev/null 2>curl.log; \
sleep 5; \
killall tcpdump; \
cat curl.log
I use ipset with dnsmasq so youtube ips are always there in the myfilterset ipset.
google gets there too sometimes unfortunately but that is something I have to live with for now.
my issue is what I described about connections originating from router itself. any idea about that?
again before the discussion gets sidetracked, right now I just wanna know how to redirect say one domain on port 443 for processes running on router itself to tor running on router.
for example maybe i gave a constant ip to www.youtube.com in dnsmasq and then I want the redirect to happen with iptable.
using tcpdump doesnt help me because I have configured my router to bridge to modem.
so a command such as "curl http://www.yahoo.com" run on router or or on a lan client is shown the same on tcpdump log with src ip on my public ip which is assigned to pppoe-wan interface.
so I cant trace the packet internally with tcpdump.
if I run this command on router
tcpdump -nn -i any "port 9040" then tcpdump doesnt show anything.
so I can test from my lan client to connect to youtube (with permanent ip of 216.58.207.206) then tcpdump doesnt see tor interfering with packets .
it just sees my lan client connecting to youtube on port 80.
so if I use iptables command (even for my lan that works correctly and transparently) tcpdump doesnt see the difference at all against when I dont use iptables commands.
so tcpdump is useless for debugging this.
sorry
I like this magic Tor program that can receive a packet addressed to your router on some port and magically know that it was originally for YouTube or Facebook or Twitter or openwrt.org based on what exactly? Some kind of packet address homeopathy?
again for the 100 time, I am not a network pro.
I just know that using those commands works transparently.
I have no idea what happens to the packet internally but I guess(again guess , not know ,but guess) that iptable just reflects that packet somehow to tor. and tor sees this " a packet for 216.58.207.206:443" and does it works itself.
btw, i tested with and without iptable and tor and both see the same info with tcpdump for that ip
and cheking for the tor listening port doesnt show anything in tcpdump even with iptables rules set for prerouting, but shows for output. as this:
IP 91.99.201.26.56222 > 127.0.0.1.9040: Flags [S], seq 3296548543, win 27800, options [mss 1390,sackOK,TS val 3927599707 ecr 0,nop,wscale 6], length 0
the first ip is my public ip.
so this "tcpdump -nn -i any "port 9040""
doesnt show anything even though iptable rule redirects with PREROUTING chain internally to tor port and tor works and transparently proxy the connection and I can open youtube on my laptop.
again for th 101 time,I dont know how this works, I am not here to argue about internal iptable working or its source code or anything. so If you want to argue the inner working of tor ,kernel or iptable for f.. sake go someplace else.
if you have any idea for making the issue I asked about in the start of topic ,please put your answer here.
if not dont pollute the topic and change the subject. you just make anyone else coming here to help distracted.
thanks
I think the output chain can work with transparent mode with tor because it actually changed the ip destination before giving it to tor , so tor see a packet coming that has destination of 127.0.0.1 and rejects it because tor doesnt proxy local connections(just public one liek youtube).
but with using prerouting tor sees a packet coming to its socket (internally so tcpdump doesnt see it )with complete ip of youtube.
that's my guess.
You have been told several times how to make the packet mangling work, and been shown a tcpdump that it does work here
And yet you insist that magic is possible and it isn't working and we should show you how to make it work...
Well your guess is wrong, the redirect target alters the packet destination to be one of the IP addresses of the router itself.
In fact it is sort of magic, the Tor proxy asks the kernel for this homeopathy.. see here
Does anyone know if this original address socket option perhaps doesn't apply to OUTPUT?
again this works as in it just changed the destination ip and port to 127.0.0.1:9040(my tor port)
but this isnt accepted by tor.
even though using prerouting works.
I dont know why, but as I said a 100 times , I dont think when I use prerouting the packet get out of iptable and is refrected(for a lack of better word) to tor, with correct ip and port of youtube. so if I use prerouting then the packet will not change its destination and is just forwarded to tor.
but using output (which I think in that svg picture linked here it outside link layer and is in network layer) creates a different packet with chenged destination ip of 127.0.0.1 and tor sees that and rejects it.
I dont knwo how to say this more clear.
so I try here with simple words again:
if I use prerouting with those command at the start of post, then tcpdump doesnt see any traffic on port 9040 and tor proxyies the packet and eveythink works for lan clients.
but when I use output chain then tcpdump sees a packet going for 127.0.0.1:9040 (which you said also in you post) but this doesnt work for transparent proxy because now tor process sees and incoming packet(different from the former one) on port 9040 and destination 127.0.0.1 and rejects it.
again: this is how it is literally working right now on my setup.
anyone else that want to answer , maybe first test on your own device.
and by test I dont mean a tcpdump output which I myself have done too.
I mean see in tor transparently proxies the connections when you use output chain in iptable.
for example when you use "curl -v https://openwrt.org" on your router then you cant connect to it with iptable output chain.
test it for yourself and see if curl give you a correct output.
that's all.
if I see one more tcpdump log i delete the shitpost/
I am literally running "tcpdump -nn -i any "port 9040"" on my router and dont see anything logged even though tor with the help of prerouting chain is working and prxoying my youtube traffic and I can open it on my laptop.
so whats up?
again I am not here to read your insult and change my mind about magic or anything.
if you can see "tcpdump -nn -i any "port 9040"" trafiic with prerouting chain then comeback here.
if not just let it go
also the link you provided also agrees with me about the packet flow.
" Take a look at this answer: How does a transparent SOCKS proxy know which destination IP to use?
Quotation:
iptables overrites the original destination address but it remembers the old one. The application code can then fetch it by asking for a special socket option, SO_ORIGINAL_DST ."
but when I use output chain the mechanism fails
Apparently that's correct, my comment about homeopathy was literally correct, it has a memory of what it's old address used to be. Apparently this hack doesn't work for you on OUTPUT. Knowing why requires deep source level kernel knowledge of the differences in the two packet processing paths... 
thank you for being humble and accepting my superiority 
sorry couldnt help myslef.
now you know what is my issue.
packets created by processes running on router dont go through nat-prerouting but the one from my lan clients do.
and tor works with prerouting (even though on all the guides on internet they all incorrectly say use OUTOUT chain https://wiki.dd-wrt.com/wiki/index.php/Privoxy_Custom_Config#Configure_transparent_forwarding_to_Tor)
Well it appears this hack is very much a hack and expected to break under various circumstances. For example https://stackoverflow.com/questions/5615579/how-to-get-original-destination-port-of-redirected-udp-message/5814636#5814636
I don't know why it doesn't work for you, but in many ways it's more surprising that it works at all. You may look for if the Tor proxy can be made to use the TPROXY mechanism
sorry to disapoint you.
I made it work for me 
it was my own stupidity and tor config vagueness that stopped the OUTPUT chain to work.
in tor config it say I need to use this
TransPort 9040 IsolateClientAddr IsolateClientProtocol IsolateDestAddr IsolateDestPort
I has to change it to
TransPort 192.168.1.1:9040 IsolateClientAddr IsolateClientProtocol IsolateDestAddr IsolateDestPort
TransPort 127.0.0.1:9040 IsolateClientAddr IsolateClientProtocol IsolateDestAddr IsolateDestPort
both are needed.
the 192 one is for prerouting one (lan clients0
and the 127 is needed for outout chain (router local connections)
did that and did this:
ipset create myfilterset iphash
iptables -t nat -A PREROUTING -p tcp -d 10.192.0.0/11 -j REDIRECT --to-port 9040;
#this is for onion addresses.
iptables -t nat -A OUTPUT -p tcp -m tcp -m set --match-set myfilterset dst -m multiport --dports 80,443 -j REDIRECT --to-ports 9040;
iptables -t nat -A PREROUTING -p tcp -m tcp -m set --match-set myfilterset dst -m multiport --dports 80,443 -j REDIRECT --to-ports 9040 ;
so now all seems to for lan AND for router connections.
hope it helps anyone else with this issue.
UPDATE:
now just my onion sites fail 
too tired to investigate that right now.
2nd UPDATE:
just needed to remove this from 192 line
"IsolateClientAddr"
or better yet use one for onion and another for proxy
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.