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.