The Juniper Protect-RE Filter Generator on the Network Tools page picked up a round of additions. The trigger was simple: we compared it against the protect_re filter a Mist-managed EX4400 actually carries, and found a handful of things a real-world filter needs that the generator didn’t cover yet.

What’s new

• Mist-Managed Device. A Mist switch opens its connections outward, so the filter only has to accept the return traffic. Three optional terms cover it: outbound SSH (TCP source-port 2200), the Mist cloud over HTTPS (443), and NAC RadSec (2083). Each is TCP with tcp-established, so a fresh inbound SYN doesn’t match.
• TACACS+. Return traffic from your TACACS+ servers (TCP source-port 49, tcp-established), with the server list pulled live from system tacplus-server using the same apply-path trick the BGP, NTP and RADIUS terms use. It’s TCP-only on purpose: TACACS+ doesn’t run over UDP, and tcp-established can’t match UDP anyway, so a combined TCP/UDP term can only ever match TCP.
• DHCP and DHCPv6. A client option for routers that get their management address by DHCP, and a server/relay option for routers that hand them out. The server/relay term is placed ahead of anti-spoof, because a client’s first packet comes from 0.0.0.0, which anti-spoof would otherwise discard.
• SNMP port 10161. An optional checkbox for the alternate SNMP port that shows up in Mist-managed switch filters.
• Custom rules. Add your own one-off terms for things the checkboxes don’t cover: a CDN host, a monitoring probe, a vendor’s update server. Each rule has a source, protocol, ports and an action. Discard rules land right after the fragment check, ahead of every accept; accept rules land after management access. A rule with an IPv6 source goes into the IPv6 filter, and one with no source goes into both. Rules with no match conditions are skipped with a warning rather than quietly becoming “accept everything”.
• More warnings. The generator now flags any /0 source, a custom accept with no source address, and the Mist terms’ lack of source restriction.

Why the Mist terms aren’t limited to Mist’s IPs

We wanted to pin those return-traffic terms to the Mist cloud addresses. It turns out Juniper doesn’t publish an address list for them. The firewall-ports page gives hostnames per region (the outbound-SSH terminator is oc-term.<region>.mist.com, for example) and says the terminator IPs change, so use FQDN-based firewall rules. A Junos firewall filter matches addresses, not hostnames, so any list we generated would quietly go stale.

New on the Network Tools page: the OS Upgrade Path Finder. You tell it what you’re running and where you want to land, and it figures out the hops.

Why does this exist? Because we got tired of checking all the vendor sites every time we had to plan an upgrade, just to find out what can go to what. We wanted to save ourselves some time, and figured why not share!

New on the Network Tools page: a Traceroute / Ping Visualizer. Paste raw output from traceroute, Windows tracert, or ping and it turns the wall of text into something you can actually read at a glance — a per-hop latency chain or a per-packet chart, with timeouts, latency jumps, and dropped packets flagged automatically.

What It Does

It auto-detects which of the four formats you pasted — Linux/Mac traceroute, Windows tracert, Linux ping, or Windows ping — and renders the right visualization:

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.