🪢 Change Your Server's Network Over SSH Without Locking Yourself Out — 2-Minute Self-Undo Timer + Live Proxmox/OPNsense VLAN Migration, Zero Downtime

Tutorials & Methods
, , , ,
1

:knot: I moved a live network onto VLANs over SSH, sites up the whole time — the two tricks that made it safe work on any Linux box, not only Proxmox

Every remote network change carries the same fear: press Enter, SSH dies, and your server is now a brick in someone else’s data centre. I did a full Proxmox + OPNsense VLAN migration on a live system with real websites, and never once lost the connection. Two tricks did that.

   TRICK 1   a 2-minute timer that puts the old config back on its own
   TRICK 2   build the new network NEXT TO the old one, cut the old one last

(VLAN = one physical cable split into separate lanes: management, production, dev, DMZ, backup.)

:stopwatch: Trick 1 — the self-undo timer

Keep the last known-good config, write a 3-line restore script, arm a timer. When the change kills SSH, the machine restores itself after 120 seconds. When the change works, you disarm it. Copy-paste, any Debian-style box:

cp -p /etc/network/interfaces /root/interfaces.pre-vlan      # 1. keep the known-good copy

cat > /root/network-rollback.sh <<'EOF'                      # 2. the undo
#!/bin/sh
set -e
cp -p /root/interfaces.pre-vlan /etc/network/interfaces
ifreload -a
EOF
chmod +x /root/network-rollback.sh

nohup sh -c "sleep 120; /root/network-rollback.sh" \
    >/root/network-rollback.log 2>&1 &                       # 3. arm: 120 s to undo
echo $! >/root/network-rollback.pid

# ... apply your change, reconnect over SSH ...

kill "$(cat /root/network-rollback.pid)"                     # 4. it worked: disarm

One rule makes or breaks it: the undo path never depends on the thing you are changing. Restore through a plain file copy or the console, never through a guest agent, an API, or the interface you just edited.

Same trick for: Proxmox bridges · VLANs · routing · remote firewalls · VPN interfaces · WAN settings.

:ladder: Trick 2 — the ladder, not the jump

   old flat network stays alive
        ├─ make the bridge VLAN-aware      (old traffic untouched)
        ├─ add the VLAN interfaces on OPNsense
        ├─ test with ONE extra NIC on a test container
        ├─ move management → dev → services → production
        └─ retire the old network LAST

The old network is the safety rope. Cut it only after the new path is proven from a separate endpoint: a second NIC on the management container, VLAN 10 tagged, one ping to the new gateway, 3 of 3 back at 0.27 ms. That one ping proved the whole chain: container → Proxmox bridge → OPNsense VM → VLAN interface → gateway.

:straight_ruler: Four rules I now follow

  • Match the exact interface block. A global text replace edits every bridge that shares the same line.
  • Change OPNsense through its GUI, API or an XML parser. Broad regex over config.xml lands in the wrong section.
  • A frozen management agent is not a dead server. Check VM status, bridge state, containers and the public sites before touching reboot.
  • Read the live state after every save. A /32 typed where /24 belongs saves fine and routes nothing.
   DURING THE WHOLE MIGRATION
   every container reachable · legacy gateway reachable
   every public site HTTP 200 · LIVE, DEV and ALT online

:brick: The three lines that do it

1. Make the bridge VLAN-aware — the old network keeps riding untagged on VLAN 1, so nothing running today notices.

bridge-vlan-aware yes
bridge-vids 1 10 20 30 40 50 90

2. Hand every lane to OPNsense on one wire — the firewall VM’s internal NIC becomes a trunk.

net3: virtio=XX:XX:XX:XX:XX:XX,bridge=vmbr10,trunks=10;20;30;40;50;90

3. Six lanes, six gateways — on OPNsense, parent vtnet3, one VLAN interface each: 10 MGMT · 20 PROD · 30 DEV · 40 DMZ · 50 BACKUP · 90 WG-MGMT, each with its own .1/24 gateway. OPNsense routes between the lanes; Proxmox stays a hypervisor.

The commands are the easy part. The hard part is knowing what must keep working, what can change, how to check it, and how to get back. Verify before, verify after, and keep the old path alive until the new one is proven.

3 Likes