Captive Wireless Devices
Taking charge of a problematic wifi environment.
I have a problem with some devices that only access the internet via WiFi. I’ve built a captive AP setup with fail closed VPN in order to monitor what’s happening.
First, I physically attached a Mikrotik RB941 firewall to my workstation. This is the smallest one they make, one ethernet port for WAN, three for internal, and wifi. One USB port is providing power, then other is a USB ethernet dongle. I prefer Mikrotik because it has a proper command line interface, it’s easy to backup/restore configs, and I’m never let staring at a web page that is supposedly showing the condition of the machine.
I didn’t want this messing with my desktop, so I created a virtual machine to handle providing NAT’d service to the ethernet dongle segment as well as fail closed VPN .
This is the /etc/netplan config file. The 185 IPs are Proton’s free endpoints. #3 is the default NAT, #8 is the host-only network of VirtualBox, and #9 is the default IP prefix for the inside of a Mikrotik. This is here because I formerly daisy chained two of these devices in another project. That one is set up as a bridged interface to the USB ethernet dongle.
network:
version: 2
renderer: NetworkManager
ethernets:
enp0s3:
dhcp4: false
dhcp6: false
addresses:
- 10.0.2.15/24
routes:
- to: 185.159.156.0/23
via: 10.0.2.2
nameservers:
addresses: [10.0.2.2,9.9.9.9]
enp0s8:
dhcp4: false
dhcp6: false
addresses:
- 192.168.56.111/24
enp0s9:
dhcp4: false
dhcp6: false
addresses:
- 192.168.88.1/24
This is what the addressing looks like when the netplan config sticks and OpenVPN is running.
Notice the lack of a default route in here. Normally OpenVPN takes over by creating 0.0.0.0/1 and 128.0.0.0/1 - dividing the default route in half. That leaves an opening for traffic to get out via the default if OpenVPN stumbles, so we eliminate the default and insert a small static route to 185.159.156.0/23.
The last step in this effort is providing a DNS server that does my bidding - that’d be Pi-hole. This part works great …
And then we come to the stopping point - routes work as far as ICMP, DNS works, but will it pass traffic??? NNNNoOoOoOoOoOoOoO!!!
And then to add insult to injury, the only vaguely competent machine I have to test with is Pinky, which runs a whiny ass titty baby OS that sets up a high pitched howling in the form of a blizzard of TCP SYN packets to various nanny services at Apple. There isn’t an STFU radio button in the network config on macOS, but there really should be.
I paused for a moment, in an effort to avoid violence that would have cost me an otherwise perfectly good laptop, and I remembered I have a WiFi dongle for my desktop. Once that connection was made I started with this little shell script and modified it to get to what I wanted. The shizz you see here is the CLI equivalent of the STFU button I mentioned above. This shuts down every bit of noise on the wire including the screeching mess that is Dropbox LAN sync.
tshark -i <your interface> -f "not icmp6 and not arp and \
not stp and not igmp and not udp and not icmp and not tcp \
and (ether[0] != 0x01 or ether[1] != 0x80 or ether[2] != 0xc2 or ether[3] != 0x00 or ether[4] != 0x00 or ether[5] != 0x0e) \
and not (udp and dst host 239.192.152.143 and dst port 17500)"
And at this point … I’m perplexed.
I’m starting to suspect what Tailscale does in terms of DNS is a big part of the problem here.
So I am just going to hit send on this and come back fresh tomorrow, maybe it’ll make more sense then.