New on the Network Tools page: a VLAN / QinQ Tag Overhead Calculator. It exists because of the same problem that led to the MTU / Encapsulation Overhead Calculator — vendors don’t agree on what a config knob actually means, and it costs you an afternoon before you find that out.

The history behind this one

The MTU tool exists because mtu isn’t the same number on every platform. Classic Cisco IOS treats it as the L3 payload size. Junos and IOS-XR fold the 14-byte Ethernet header into it. Same command, same-looking number, two different frames on the wire — and the failure mode is never an error message, it’s just silent fragmentation or a black-holed jumbo-frame flow that only shows up under load.

Also new on the Network Tools page: a Juniper Protect-RE Filter Generator — builds the lo0.0 input firewall filter every RE-bound packet passes through, regardless of which interface or destination address it actually arrived on.

Check the protocols you run, list trusted sources where it matters, and get a complete, correctly-ordered config — anti-spoofing and fragment discard first, then source-restricted NTP/RADIUS/SNMP/BGP, then OSPF/VRRP, then management access, a blanket TCP SYN/FIN/RST flood policer, type-restricted rate-limited ICMP, dual-style traceroute support (UDP and Windows’ ICMP-based tracert), optional BFD, and a logged, counted catch-all discard at the end.

Added a new one to the Network Tools page: an IPsec VPN Configuration Generator for Cisco IOS/IOS-XE, ASA, FortiGate, Palo Alto, Juniper SRX, strongSwan/VyOS, UniFi, and pfSense/OPNsense.

The reason I built this instead of just pointing at vendor docs is the case that actually breaks real deployments: pairing a policy-based peer with a route-based one. A route-based side (VTI/tunnel interface) defaults to a catch-all 0.0.0.0/0 ↔ 0.0.0.0/0 selector, since routing decides what enters the tunnel. A policy-based peer negotiates specific proxy-IDs per subnet pair, pulled straight from its ACL. Put those two together unmodified and phase 2 negotiation just fails — no useful error, just a tunnel that won’t come up.

MTU problems are some of the most annoying things to troubleshoot in networking, because they’re usually silent. Small packets sail through fine, everything looks healthy, and then someone complains that a specific app is slow or hanging — and it turns out one link in the path, three hops in, has an MTU 8 bytes smaller than everyone assumed. GRE, IPsec, PPPoE, a VPN overlay, a jumbo-frame config that only got applied to half the path, a VLAN tag quietly adding 4 bytes nobody accounted for, or just two vendors defining and displaying “MTU” differently (L2 vs. L3, tagged vs. untagged) — any of these can quietly clip your effective MTU, and standard ping/traceroute won’t tell you where.

I mentioned in the WordPress-to-Hugo migration post that this site was going to start drifting a bit toward retirement and financial planning content alongside the usual networking stuff. Here’s the first real piece of that: a new Financial Tools section, same browser-only, nothing-sent-to-a-server philosophy as the Network Tools I’ve been building for years.

Retirement & Social Security Planner

This is the one that actually matters. It’s a full retirement dashboard — portfolio projections, Social Security claiming strategy (including spousal/survivor benefits), RMDs, a Roth conversion planner, Medicare/IRMAA cost estimates, and a Monte Carlo simulation that runs a thousand random market paths against your numbers instead of just assuming a flat return every year. I’ve been building and using a private version of this for a while now; this is that tool, cleaned up for public use. Find it at fryguy.net/financial-tools/retirement-planner.

This site has run on WordPress since basically forever. As of this week, it doesn’t anymore. Everything you’re reading is now a static Hugo site, built from Markdown, served by nginx, with no PHP and no database anywhere in the stack. Here’s why I did it, what actually moved, and how I used Claude Code as a pair programmer for most of the heavy lifting.

Why bother

Let’s be honest about how it got this bad: I didn’t keep up with it. I know. Servers don’t rot on their own — you stop patching them, stop upgrading them, and a few years later you’re staring at a stack that’s aged out from under you. The old droplet had quietly rotted underneath a site that still worked fine. Ubuntu 18.04 — EOL since 2023. PHP 7.4 — EOL since 2022, with no apt-upgrade path to anything newer (the PPA I’d have needed was frozen). MySQL 5.7 — also EOL. WordPress itself was current; everything under it wasn’t, and there was no clean patching path left, just a slow accumulation of risk on a box facing the public internet.

If you’ve ever had to move a large session library from SecureCRT to SuperPutty, you know the pain — there’s no built-in migration path, and manually re-entering dozens (or hundreds) of sessions is a miserable afternoon. I wrote SCRT_2_SPUTTY to handle it automatically. Point it at your SecureCRT XML export, and it spits out a ready-to-import SuperPutty XML file. No third-party libraries, no configuration files — just Python and a single command.

If you run a self-hosted Ubiquiti UniFi network — whether it’s a home lab, small business, or multi-site setup — you know the UniFi dashboard is great for real-time monitoring but falls short when you want a clean summary you can save, share, or review later. I built UniFi Network Health Report to fill that gap: a Python tool that connects to your controller and generates a standalone HTML report covering everything that matters.

If you work with Juniper hardware and have never used the Juniper Port Checker, you are missing out on a really useful tool. It is part of the Juniper Pathfinder suite and it gives you a visual representation of the front panel of a device and lets you configure port speeds to validate that your planned configuration is actually supported by the hardware. No more digging through data sheets trying to figure out what happens to adjacent ports when you change a speed.

I have been meaning to put together some network tools for a while now, and I finally got around to it. I added a new Network Tools section to the site with eight tools that I find myself needing on a regular basis. They all run in the browser – nothing gets sent to a server, they either do the math locally or call a public API directly.