2 posts tagged with "ubiquiti"

With the cold and the early darkness, it's time for more TV than less. With that in mind, I needed to fix a few things that "broke" over the last few months. This entry is more of a mental dump so that in the future I can remember what I did to fix things.

Future Idea:​

Move to an 802.11 trunked VLAN and serve DHCP/VPN tunneling from a single RPi.

NetworkManager​

I thought it was Debian Bookworm, but Trixie finally forced me into a shotgun wedding with NetworkManager (NM). I'm going to rely on Ansible wrappers for interface configuration, but I haven't yet automated this so:

Static IP Configuration with nmcli looks like this:​

           $ nmcli con add con-name my-con-em1 ifname em1 type ethernet \
             ip4 192.168.100.100/24 gw4 192.168.100.1 ip4 1.2.3.4 ip6 abbe::cafe
           $ nmcli con mod my-con-em1 ipv4.dns "8.8.8.8 8.8.4.4"

DNSMasq DHCP​

A nice feature of Ubiquiti is that it can act as a meshed AP and let one of the Raspberry Pis be the gateway for that VLAN.

Network Forwarding​

This needs to be more granular and live in the playbook for the interface.

sysctl -w net.ipv4.ip_forward=1

The Other Problem(s)​

Mixed up switch VLANs​

Upgrading to the PoE 2.5 GHz switch, I swapped wires and mixed up the DHCP-addressable VLANs, so Remote2 was booting on Remote1 and vice-versa.

Stale WireGuard Connections​

One of the endpoints changed IPs, which required a DNS update and a tunnel restart. I've been too lazy to automate the end-to-end of this workflow, so we'll just have to fix it when it breaks.

WireGuard General Config​

Entry Point​

root@local:/etc/NetworkManager/dnsmasq.d# cat /etc/wireguard/remote_gateway.conf 
[Interface]
Address = 10.253.120.7/32
ListenPort = 21001
PrivateKey = #<cat privatekey>


#local Gateway Entrance
[Peer]
Endpoint = <gateway-domain>:XXXXXXX
PublicKey = #<cat privatekey | wg pubkey>
AllowedIPs = 0.0.0.0/0,::/0

Exit Point​

root@remote:~# cat /etc/wireguard/wg0.conf 
[Interface]
#Address = 10.253.120.1/32, fd02:e6c1:d3b9:bca7:0070::1/76
Address = 10.253.120.1/32
ListenPort = 21001
PrivateKey = #<cat privatekey>
PostUp = nft add chain ip nat POSTROUTING '{ type nat hook postrouting priority 100; }'
PostUp = nft add rule ip nat POSTROUTING ip saddr 192.168.31.0/24 oif eth0 masquerade
PreDown = nft -j list ruleset ip | jq '.nftables[] | select (.rule.chain == "POSTROUTING" and (.rule.expr[2] | has("masquerade"))) | .rule.handle'  | while read handle; do nft delete rule ip nat POSTROUTING handle $handle;done


# Remote Gateway
[Peer]
PublicKey = #<cat privatekey | wg pubkey>
AllowedIPs = 10.253.120.7/32,192.168.131.0/24

#laptop
[Peer]
PublicKey = <laptop-public-key>
AllowedIPs = 10.253.120.2/32,fd02:e6c1:d3b9:bca7::2/128

For exactly zero-users,​

I've spent some time firming up the Home Network Kill Switch project due to some breaking changes in Pi-hole v6 and Ubiquiti Control 9.4.19. Its a home project that uses iOS HomeKit buttons, backed by a Ubiquiti and Pi-hole setup, to simplify parental controls. I suspect others might appreciate a one-tap solution for managing network access, especially one that's easy enough for less technical family members to use.

Why I Built This​

The UniFi app is powerful, but I found it took too many clicks to quickly block the internet or specific services like YouTube. This project creates simple "on/off" switches in Apple HomeKit, saving me from needing to open the app or connect to a VPN for simple tasks. For those using Home Assistant, integration should also be straightforward.

What It Does​

I built a small FastAPI application that works with HomeKit (via MQTT and Node-RED) to:

• Enable or disable predefined firewall rules on your Ubiquiti network.
• Block or unblock specific devices by their MAC address.
• Allow non-technical users to create schedules and automations for these actions directly in the Home app.

Where to Get It​

You can find all the specifics on the GitHub repo: https://github.com/5L-Labs/overlord-network-kill-switch

To get started quickly with Podman:

podman run -d --replace --name=overlord-dns -p 19000:19000 --env-file=./etc/envfile ghcr.io/5l-labs/overlord-network-kill-switch:2.5

What was hard about this?​

Testing, Testing, Testing. Time management - this took far longer than planned for the limited time I had.

• Not DOSing the Ubiquiti Controller while trying to validate code paths
• Ensuring Pi-hole v6 API calls were working as expected
• Adding in edge-case / race-condition checks
• Making it proper, releasable that someone else might use it

Did AI Help?​

No, not really. It did do some scaffolding and documentation, but the core logic was still human led. I do plan to use Jules to keep ripping out dead code paths.

Recent Changes​

• Pi-hole v6 API Integration: The project now uses the new pihole6api library to interact with the Pi-hole v6 API. This allows for more reliable and efficient management of blocklists.
• Ubiquiti Control 9.4.19 Support: The project has been updated to support the latest version of Ubiquiti Control.

How It Works (The "Background")​

I use the firewall rules on my Ubiquiti gear to enforce blocks on devices (like school-issued laptops) that are configured to bypass my local Pi-hole DNS. This setup allows for creating network-level blocks for common services, providing a more robust solution for locked-down devices. It was a fun project, and it gives my family an easier way to manage internet access as my kids get older.