Tor

just for fun, let's see if we can get an WLAN set up that tunnels through tor.
opkg install tor (duh!)
first create a new wlan for tor in network>wifi
add, and create a new network interface 'tor'.
go to network>interfaces and configure our new interface with static ip and and a dhcp.
assign a firewall zone 'tor'. and if you're truly paranoid you can override the mac with 00:88:88:88:00:2A.


head over to network>interfaces>firewall>
select 'tor' and under advanced and ensure 'force connection tracking' is checked 
(this connection tracking isn't required, when you don't use the --syn flag or use luci rules, see below)

traffic rules to setup are faily standard
accept from wan  tcp  443 (torbridge)
acccept from tor upd 67-68 (dhcp)
accept from tor tcp 9040 (torproxy,  set port in /etc/tor/torrc)
accept from tor udp 9053 (tordns, set port in /etc/tor/torrc)
accept from tor tcp 9050 (tor socks, set ip/port /etc/tor/torcc) 
 !me thinks firewall rules block SOCKS not clear yet.
socks no t in screenshot!
now, most recipes want you to add two magical rules in firewall.user

iptables -t nat -A PREROUTING -i wlan1 -p udp --dport 53 -j REDIRECT --to-ports 9053
iptables -t nat -A PREROUTING -i wlan1 -p tcp --syn -j REDIRECT --to-ports 9040
which look pretty much like a any-tcp to port 9040 and udp:53 to 9053 port forward.
so that's what I did (stilll need to check on the forum wether i broke something now :)

now we still need to set up tor, no luci yet.
edit /etc/tor/torrc

          SOCKSPort 10.1.0.1:9050
          SOCKSPolicy accept 10.1.0.0/16
User tor
RunAsDaemon 1
PidFile /var/run/tor.pid
DataDirectory /var/lib/tor
# This is for our transparent network
VirtualAddrNetwork 10.1.0.0/16
AutomapHostsOnResolve 1
TransPort 10.1.0.1:9040
DNSPort 10.1.0.1:9053
obviously the bits in red need to match with your port redirct, interface settings etc.
hit run: /etc/init.d/tor start

point wifi to your torrified ssid and go to: https://check.torproject.org/.

everything 'looks' okay, even though i think the socks proxy wont't be reachable because the redirect taking precedence... but hey. it works, don't fix it. :)

Comments

Post a Comment

Popular posts from this blog

Traffic accounting

Got this from here: http://www.catonmat.net/blog/traffic-accounting-with-iptables/ All i'm interested in is my monthly bandwidth consumption, not the individual devices, there are plenty of forum threads/tools to do that. But why bring in additional tools when iptables has it all? iptables -N TRAFFIC_ACCT iptables -I FORWARD -j TRAFFIC_ACCT iptables -A TRAFFIC_ACCT and to just get the number: iptables -L TRAFFIC_ACCT -v | sed -n 3p | cut -d' ' -f2 to reset the counters /usr/sbin/iptables -L TRAFFIC_ACCT -Z the cron job to reset at the begining of the month, and a daily telegram msg 1 0 1 * * /usr/sbin/iptables -L TRAFFIC_ACCT -Z  0 8 * * * /usr/bin/curl -s -X POST https://api.telegram.org/<BOTID>/sendMessage -d chat_id=<CHATID> -d text="$(/usr/sbin/iptables -L TRAFFIC_ACCT -v | /bin/sed -n 3p | /usr/bin/cut -d' ' -f3)" >/dev/null 2>&1 (you'll need to opkg install ca-bundle for the https to work)
Read more

QoS with SQM (and something about bufferbloat)

another feature that came with stock zyxel fw is their 'optimized' (the one with the 400mbps nag) QoS packages. As far as i can tell the standard SQM package should come pretty close. install uci-app-sqm a Network>SQM QoS menu item will appear check enable, double check your interface name is really your wan port(eth1), and set your down/up speeds to what you measured with e.g. dslreports . under linklayer adaptation set to Ethernet (for VDSL) with 8 bytes overhead. i reran the test, and it seems my up/down throughput dropped about 10%,  but my bufferbloat report went from D to B.... whatever that means in reality I'll have to find out :)
Read more

Ath10k alternative driver firmware - CC15.05.1 wireless unstable

I'm still experiencing trouble with the 5Ghz, maybe even WRT in general, up to the point I'm considering going back to the original Zyzel AA release. One last effort to see if this helps: I'm currently running an alternative driver firmware for the  QCA988X get it from github i'm running the last of the 4 series 10.2.4.48 (not sure if running the 5 series is possible, something for later) rename the file to firmware-4.bin and replace the one that's already there in /lib/firmware/ath10k/QCA988X/hw2.0 There's probably a way to force WRT to reload the driver, but hey I rebooted. First look seems fine, let's see if it's more stable. -- update -- leaving channel selection on 'auto' didn't work - 5G did not come up. (no mesgs as to why) manually selecting a channel did seem to work, at least when also selecting a 20Mhz bandwidth, 40Mhz seemed to work but I had some devices not connecting properly. -- update2 -- 5G was mostly s...
Read more