The Fix That Didn't Migrate: The SSH Drops Came Back After Windows → Fedora

Eight months after W03, sessions to every routed segment started dying again. The fix was the same one-line route. It had lived only on the old Windows install and never made the move to Fedora.

2026-09-13#CyberDen

work: Sep 2026 · Resolved · Series Epilogue to W03 · CyberDen, Networking, pfSense, VyOS, Linux

TL;DR

In January (W03) I fixed dropping SSH sessions with one persistent route on the admin workstation: lab supernet via VyOS, default via pfSense. In September I moved that workstation from Windows to Fedora, and sessions to anything off the management segment started dying again, roughly three minutes in. I spent a week suspecting the terminal app, keepalives, the VM, and the Proxmox firewall before noticing the pattern: only routed segments dropped. The route had been a route -p on Windows. It wasn't in any config I'd carried over. One NetworkManager route brought it back, and it now comes back every time the connection does.

Symptoms

New SSH sessions to vuln-apps-01 connected and authenticated fine, then froze and closed after a few minutes.
Ping to the same VM stayed perfect the whole time: 0% loss, about 1 ms.
It happened in Tabby, in plain OpenSSH, and inside tmux, so the terminal app was not the problem.
The VM's sshd log eventually said Timeout, client not responding: the server's keepalive probes were no longer getting answers back through the path.
MobaXterm on the old Windows install had never shown this on the same lab.

The leads, in order

Date	Lead	How it ended
Sep 6	Tabby session reuse, keepalives, a frozen TTY	Ruled out: the same drop in plain OpenSSH (and later in tmux)
Sep 6	Asymmetric path: traceroute showed pfSense → transit → VyOS going out	Spotted, then dismissed, because I believed other VMs were stable
Sep 6	Proxmox VM firewall on this one NIC	Became the main suspect
Sep 13	The workstation had come up on `.51` instead of its static `.50`	Real, and fixed, but not the cause
Sep 13	`qm config` showed no `firewall=1` on the NIC	Firewall lead disproved
Sep 13	Same drop on VMs on two other hosts and two other segments	The pattern: management segment fine, every routed segment drops

The right answer was in the Sep 6 traceroute. I talked myself out of it on a single unverified claim ("the others are fine") and chased the one config difference I could see.

pfSense TRANSIT interface — Sep 6: the pfSense side of the /30 transit link to VyOS. Forward traffic to every routed segment crosses it.

route get through the transit link — pfSense routes the vulnerable-targets segment via VyOS's transit address, and the link itself is healthy. The forward path was never broken.

What was actually happening

The same failure as W03, step for step:

request:  workstation → pfSense → transit /30 → VyOS → VM
reply:    VM → VyOS → workstation          (VyOS has a leg on management)

pfSense saw only one direction of each TCP session, marked the state invalid and stopped passing it after a while. ICMP doesn't care, so ping looked perfect. Sessions to hosts on the management segment never cross pfSense, so they never dropped. That's why it looked like "some VMs are fine".

traceroute back from the VM — The return path from the VM: two hops, VyOS and then the workstation. pfSense isn't on it.

Why it came back

On Windows the fix had been a single persistent route:

route -p add <lab supernet> mask <supernet mask> <VyOS management address>

-p writes it to the registry. That's why it survived every reboot, and why I forgot it existed. Moving to Fedora, I rebuilt the network profile (static address, Pi-hole DNS) from what I could see. The route wasn't visible anywhere I looked, so it didn't come with me.

The fix

I tested it as a temporary route first:

sudo ip route add <lab supernet> via <VyOS management address> dev <lab NIC> metric 20
ip route get <routed VM>      # → via VyOS, not pfSense
traceroute -n <routed VM>     # → 1 VyOS, 2 VM

After the sessions held, I made it part of the NetworkManager profile, so it comes back with the connection:

sudo nmcli connection modify "<lab profile>" +ipv4.routes "<lab supernet> <VyOS management address> 20"
sudo nmcli connection down "<lab profile>" && sudo nmcli connection up "<lab profile>"
ip route | grep <lab supernet>    # proto static metric 20

No firewall rule changed, and pfSense still owns the default route and the internet edge. The only change is that the admin workstation reaches internal segments through the core router that serves them.

Verification

Sessions to the vulnerable-targets VM, the k3s node and the AI node all stayed up through normal work.
I bounced the connection with down/up and the route came back, so it persists.
Traceroute from the workstation is now two hops (VyOS, then target) in both directions.

Lessons

A fix that lives on one machine is tribal knowledge. Host-level network config (routes, DNS, static addresses) belongs in the lab notes, next to the switch and router config.
Before migrating, export what the old OS knew. route print, netsh profiles, the hosts file. Rebuild from that export, not from memory.
Don't let an unverified "the others are fine" close a lead. The asymmetric path was on screen on Sep 6. Testing one VM on a second segment would have saved a week.
This also corrects the record. An earlier note put this incident down to a host firewall on the VM. The firewall was never involved.

Sources: Product Security Career Advice (6 Sep 2026), Fix Tabby SSH Connection (13 Sep 2026)