Raspberry Pi Wireless Wi-Fi TOR Anonymizer Gateway (Yet Another Post)

Many tutorials are floating around with instructions to make a raspberry pi into a wifi wireless access point that will direct all client traffic through the onion ring anonymizer network, for example here and here. They all seem to be various versions of some initial document somewhere, and none actually clearly call out everything that is needed.

The pi this runs on has an internet connection via copper from physical LAN port to ISP router. Also, I use ufw as the pi's firewall and so ufw rules are included below.

So here are my working configuration files, including those for the tor, hostapd, dnsmasq and ufw daemons. This pi reports kernel 4.19.60 and /etc/issue says "Raspbian GNU/Linux 10".

/etc/network/interfaces.d/wlan0

I prefer to keep /etc/network/interfaces empty and have individual files for network adapters in /etc/network/interfaces.d. Here is /etc/network/interfaces.d/wlan0:

allow-hotplug wlan0

iface wlan0 inet static

    address 192.168.5.1

    netmask 255.255.255.0

    network 192.168.5.0

    broadcast 192.168.5.255

Note: a couple of online tutorials I saw forgot to mention that the wlan0 IP network has to match the IPs that dnsmasq DHCP server and tor transport and DNS server addresses bind to, as you will see below in torrc.

/etc/hostapd/hostapd.conf

Adjust ssid and password to your preference.

interface=wlan0

ssid=ONION

hw_mode=g

channel=11

macaddr_acl=0

auth_algs=1

ignore_broadcast_ssid=0

wpa=2

wpa_passphrase=SOMEPASSWORDHERE

wpa_key_mgmt=WPA-PSK

wpa_pairwise=TKIP

rsn_pairwise=CCMP

/etc/dnsmasq.conf

no-resolv

interface=wlan0

dhcp-range=192.168.5.100,192.168.5.199,255.255.255.0,6h

# Cloudflare free dns

server=1.1.1.1

/etc/tor/torrc

Log notice syslog

VirtualAddrNetwork 10.192.0.0/10

AutomapHostsSuffixes .onion,.exit

AutomapHostsOnResolve 1

TransPort 192.168.5.1:59040

DNSPort 192.168.5.1:53

/etc/ufw/before.rules

You need to already have IP forwarding enabled in the kernel (check /etc/sysctl.conf and set net.ipv4.ip_forward=1), and add the following nat rules for all DNS and TCP traffic on wlan0 to be passed through tor. This makes any wireless clients connecting to your wifi access point use tor for traffic.

This is my entire before.rules file, including other unrelated stuff. You only need the tor-related nat table rules at the top to drop into the existing before.rules installed with ufw. (Unrelated, but this specific pi also happens to host a simh VAX that acts as the DECnet router for my real MicroVAX 3100-80, nodename MARIAH.)

#

# rules.before

#

# Rules that should be run before the ufw command line added rules. Custom

# rules should be added to one of these chains:

#   ufw-before-input

#   ufw-before-output

#   ufw-before-forward

#

# **********

# NAT table rules

# **********

*nat

:PREROUTING ACCEPT [0:0]

:POSTROUTING ACCEPT [0:0]

# ---

# Flush the table first, otherwise UFW keeps adding the rules if reloaded

# ---

-F

# ---

# Incoming connections port forwardings

# ---

# TELNET to MARIAH with rate limiting

-A PREROUTING -i br-ip -p tcp --dport 23 -j DNAT --to-destination 10.3.100.80 -m limit --limit 1/minute --limit-burst 1

# TOR | All DNS traffic from wlan0 to TOR (see /etc/tor/torrc)

-A PREROUTING -i wlan0 -p udp --dport 53 -j REDIRECT --to-ports 53

# TOR | All TCP traffic from wlan0 to TOR (see /etc/tor/torrc)

-A PREROUTING -i wlan0 -p tcp --syn -j REDIRECT --to-ports 59040

# ---

# Forward outgoing traffic from MARIAH through br-ip to the internet

# ---

-A POSTROUTING -o br-ip -j MASQUERADE

# don't delete the 'COMMIT' line or these nat table rules won't

# be processed

COMMIT

# **********

# End NAT table rules

# **********

# Don't delete these required lines, otherwise there will be errors

*filter

:ufw-before-input - [0:0]

:ufw-before-output - [0:0]

:ufw-before-forward - [0:0]

:ufw-not-local - [0:0]

# End required lines

# allow all on loopback

-A ufw-before-input -i lo -j ACCEPT

-A ufw-before-output -o lo -j ACCEPT

# quickly process packets for which we already have a connection

-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# drop INVALID packets (logs these in loglevel medium and higher)

-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny

-A ufw-before-input -m conntrack --ctstate INVALID -j DROP

# ok icmp codes for INPUT

-A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT

-A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT

-A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT

-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT

# ok icmp code for FORWARD

-A ufw-before-forward -p icmp --icmp-type destination-unreachable -j ACCEPT

-A ufw-before-forward -p icmp --icmp-type time-exceeded -j ACCEPT

-A ufw-before-forward -p icmp --icmp-type parameter-problem -j ACCEPT

-A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT

# allow dhcp client to work

-A ufw-before-input -p udp --sport 67 --dport 68 -j ACCEPT

#

# ufw-not-local

#

-A ufw-before-input -j ufw-not-local

# if LOCAL, RETURN

-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN

# if MULTICAST, RETURN

-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN

# if BROADCAST, RETURN

-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN

# all other non-local packets are dropped

-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny

-A ufw-not-local -j DROP

# allow MULTICAST mDNS for service discovery (be sure the MULTICAST line above

# is uncommented)

-A ufw-before-input -p udp -d 224.0.0.251 --dport 5353 -j ACCEPT

# allow MULTICAST UPnP for service discovery (be sure the MULTICAST line above

# is uncommented)

-A ufw-before-input -p udp -d 239.255.255.250 --dport 1900 -j ACCEPT

# don't delete the 'COMMIT' line or these rules won't be processed

COMMIT

UFW Rules

And finally, add UFW firewall rules to allow DNS and tor transport traffic from the command line:

# ufw allow in on wlan0 to any port 53 proto udp comment "dns for wireless clients"

# ufw allow in on wlan0 to any port 59040 proto tcp comment "tor transport for wireless clients"

That's it. Restart all affected daemons, including ufw (disable and enable it), connect a computer to the wireless hotspot and visit a website that will report the IP address it sees the browser request coming from (e.g. https://whoer.net/). Apparently I am currently accessing the internet from a tor exit point somewhere in Austria.

PCVMS - taking the aspirational DOS based VMS inspired multitasking environment for a spin

According to a smattering of information on the internet, there was once a computer software company called Wendin based in Cheney, WA. They launched a product called PCVMS "Personal Operating System" in 1985. It was distributed on a set of three 5.25" 360KB floppy diskettes. More history and juicy bits are in Bill's 2009 post in his "Personally Interesting Stuff" blog. I also found a public profile of Steve Jones at Linkedin, "Steve launched Wendin's Computer Systems Division in 1984, developing the XTC text editor, the PCVMS operating system ("a VAX/VMS operating system clone that ran on IBM PC/ATs), the PCUNIX (later called PCNX) operating system (a Unix clone that ran on IBM PC/ATs), Operating System Toolbox (an operating system toolkit that enabled software developers to create their own operating systems), and Wendin-DOS (an MS-DOS clone with OS/2-like screen groups and multitasking), among other products." The March 1997 issue of IEEE Software "New Product Reviews" contains a quick review of PCVMS written by Randy Kaplan of Temple University:

R. Eckhouse, "New Product Reviews" in IEEE Software, vol. 4, no. 02, pp. 79-84, 1987.
doi: 10.1109/MS.1987.230374
keywords: {null}
url: https://doi.ieeecomputersociety.org/10.1109/MS.1987.230374

A trademark was apparently refused for "PCVMS" in 1986. It was described in the trademark application in 1985 as "MAIL ORDER COMPUTER PROGRAMS USED BY OWNERS OF PERSONAL COMPUTERS IN PERSONAL COMPUTERS AS OPERATING SYSTEMS PROGRAMS FOR THE GENERAL OPERATION OF SUCH PERSONAL COMPUTERS". In any case, a"VAX/VMS operating system clone that ran on IBM PC/ATs" is intriguing. Responses to my quick questions at the HECnet mailing list and comp.os.vms NNTP group indicate folks already played with PCVMS decades ago. However, the universal opinion seems to be PCVMS should be approached with tempered expectations.

I fired up a 86BOX instance running Caldera DR-DOS 7.03 on a 80486SX 25MHz PC and installed PCVMS 1.08 following the instructions in the PCVMS README file. On launching PCVMS, it asks for a username and password. Username "root" with empty password presented a welcome message and a "$" command prompt. 

There is VMS-like help, one of the installed files even being HELPLIB.HLB like in DEC VAX VMS systems. On the other hand, the PCVMS user authentication system is straight off Unix, relying on a "passwd" file under "etc" directory under the boot drive. The touch of Unix probably has something to do with "PCNX UNIX-like environment; not just UNIX-like tools, but multi-processing under MS-DOS" which provided at, cat, cmp, cp, cron, date, df, echo, false, file, find, finger, getty, grep, group, grppswd, head, kill, line, logname, lpd, lpr, ls, mail, mkdir, mkgroup, mkuser, more, mv, news, nice, nohup, od, passwd, pr, ps, rev, rm, rmdir, rmgroup, rmuser, sh, sleep, strings, stty, tail, tee, test, time, touch, true, tty, uniq, wc, who, whodo, write. 

By the way, I also briefly tried Wendin's "Wendin-DOS multitasking, multiuser MS-DOS replacement" which is publicly available, but it kept crashing with some sort of internal error in a rectangular box occupying the top third of the screen. This is another operating system that is my queue of things to explore further.

But, at this point, it appears for using "multi-user" features of PCVMS we need some sort of multiple hardware terminal connections with each then becoming a session. Something to be tried if and when I come back to this. A manual would be nice, but so far I have none.

Command Line Torrent Client and Gopher Server on Raspberry Pi

One Raspberry Pi in my home lab has a 1TB USB external hard disk drive connected to it. I wanted to share some retrocomputing hobbyist-related stuff publicly in gopherspace. I also wanted a command-line torrent client to download retro public-domain stuff from archive.org and other places.  Here are the pieces I ended up using.

GOPHER

I set up a gopher server on the Pi and opened up and forwarded TCP/IP Port 70 to it. I am able to reach the gopher server using a standard web-browser from the public internet using Floodgap Gopher-HTTP Gateway. Currently it has some ancient ZX Spectrum home microcomputer stuff. It is connection-rate limited using UFW, so slow down while visiting it to not be refused!

Floodgap also runs a great Veronica-2 Gopherspace Search engine.

Here are the steps for quickly getting into Gopherspace:

Gopher server

pygopherd: PyGopherd is a modern Internet Gopher server written in Python and is maintained by John Goerzen. In addition to support for RFC 1436 Gopher and Gopher+, PyGopherd also supports HTTP and WAP (Wikipedia).

Gopher client (browser) - Text/Terminal

Good old Lynx terminal web client continues to support Gopher. It is available from standard package repositories for virtually every operating system in use.

Gopher Client (Browser) - Windows, Mac OS X

Little Gopher Client - works great, available for MacOS X, Linux and Windows.

Command-line bittorrent client

rtorrent works fine!