What Happened
Out of no where, my home network would randomly start grinding to a halt. It would slow down just enough to be annoying; streaming would buffer, services like Xbox multiplayer would randomly fail to connect. Try again and it would work and sometimes there wouldn’t be an issue at all.
I thought it might be the ISP issue and decided waiting it out. After a day or so of this issue, I started to think maybe it was my DNS settings which I had changed a few weeks earlier (Claude helped me find an issue with my upstream resolver not caching properly).
This time, the culprit was something I would have struggled to find without AI digging through my firewall logs.
My Setup
I run OPNSense as my home router and firewall. It’s powerful, open source and runs on a dell workstation with an i7, 8GB of memory, an SSD and some intel 10g NICs (or you can virtualize it, but just know your network will be down when this goes down).
My manual AI workflow of choice currently is Claude Code/Desktop and MCP servers to connect all over the place. opnsense-mcp-server gives Claude read access to firewall logs, interface stats, DHCP leases, and other network state. This has quickly become my go-to tool for diagnosing any network issues.
For example, I had Claude create a mermaid topology graph (in svg format) of my home network:
What Claude Found
I opened Claude Desktop and in my own words, described the symptoms. I told it how my internet was randomly being slow as if my ISP was having connection issues. I asked it to look for anything out of the ordinary, and even to double check the DNS settings we set a few weeks earlier.
Within a few minutes it flagged something interesting.
A single device on my LAN was hammering UDP port 54444 with an enormous volume of outbound packets. We’re talking thousands of packets per second, sustained — enough to saturate the network and cause the kind of degraded performance I was seeing. The traffic wasn’t leaving my network, it was just flooding it internally.
The only identifier was a MAC address. No hostname. No helpful IP context. Just XX:XX:XX:XX:XX:XX sending a storm of UDP traffic to the broadcast address.
Claude explained what UDP port 54444 is used for: it’s part of Amazon’s Alexa inter-device communication protocol. Alexa devices use it to coordinate the “announcement” feature — when you ask one Echo to broadcast a message through the house, they all receive it over this port. Under normal conditions, traffic is brief and lightweight. But if a device gets stuck mid-announcement, it can loop indefinitely.
That was the hypothesis: an Alexa device frozen in a failed announcement, retrying forever.
The Investigation
Armed with a MAC address and a theory, I went device hunting.
I checked my DHCP leases to cross-reference the MAC — no luck, it wasn’t resolving to a hostname. So I did it the old fashioned way: walked through the house looking at every Alexa device.
We have a few Echo tablets mounted on the walls in different rooms. My kids use them constantly — playing music, setting timers, making announcements that echo through the whole house (often at the worst possible time). When I got to the hallway, I found it.
Two Fire tablets, wall-mounted, screens frozen. Both were stuck on the announcement UI — mid-broadcast, not progressing, not timing out. Just sitting there, hammering my network in the background while the rest of us wondered why everything felt sluggish.
I rebooted both tablets.
The Fix
Network performance recovered immediately. The buffering stopped. Video calls were crisp again.
I asked Claude to re-check the logs. The MAC addresses that had been generating the traffic storm were now silent — no more UDP 54444 flood. It confirmed what I suspected: those two devices were the entire problem.
What I appreciate about this workflow is the feedback loop. It’s not just “here’s a theory” — it’s “here’s what I saw, here’s what changed, here’s confirmation that the fix worked.” That’s the difference between guessing and knowing.
What I Learned
IoT devices are a wild card on your home network. I’ve always known this in the abstract, but watching Claude pull up a traffic graph and go “yeah, that device is flooding your LAN” made it concrete. Consumer devices don’t fail gracefully. They can get into weird states and stay there indefinitely.
AI + firewall logs is a genuinely powerful combination. I’m comfortable with networking concepts but I’m not a dedicated network engineer. I wouldn’t have thought to look at per-device UDP traffic volume. Claude did, because it was looking at the data without assumptions.
You don’t need to be an expert to get expert-level diagnostics. The OPNSense logs had the answer the whole time. The hard part was knowing what question to ask — and that’s exactly where AI earns its keep.
Repeatable process. Now when my network slows down, I have a workflow: open Claude Desktop, describe the symptoms, ask it to scan for anomalous traffic patterns. Five minutes versus hours of manual log spelunking.
Going Further
If you’re running OPNSense and want to set up a similar diagnostic workflow, search for OPNSense MCP server implementations — a few exist in the community. The setup is straightforward if you’re comfortable with MCP in Claude Desktop.
If you’re not ready to go full AI-assisted diagnostics, at minimum I’d recommend:
- Segmenting your IoT devices onto a separate VLAN. Keeps them from affecting your main LAN traffic even when they misbehave.
- Setting up traffic logging on your firewall. You can’t diagnose what you can’t see.
- Watching per-device bandwidth in your router’s dashboard when something feels off. Most modern firmware surfaces this somewhere.
My kids still use the Alexa tablets. They still make house-wide announcements at inconvenient hours. But now when the network slows down, I know how to find out why — and it takes five minutes instead of an afternoon.
That’s the core of it. If you’ve set up something similar with OPNSense and Claude, I’d love to hear how you’re using it.