# OPNsense-Fallback & CARP

## ⛔ Regeln für Agenten / KI — STRIKT

**NIEMALS** eigenmächtig VM 104 (OPNsense) auf pve1 oder pve2 **starten, stoppen, neustarten oder suspenden**.

- Kein `qm start 104`, kein `qm stop 104`, kein `qm reboot 104`, kein `qm shutdown 104`
- **Nur** der Betreiber führt Router-Start/Stop aus — explizit, manuell, bewusst
- Agenten dürfen: Doku schreiben, Config offline auf Disk bearbeiten (wenn beauftragt), beraten
- Agenten dürfen **nicht**: Router zur „Prüfung“, zum „Testen“ oder „weil es so aussieht“ anfassen

**Hintergrund:** CARP-Gateway ist `192.168.10.1`. Jeder ungeplante Start/Stop kann VIPs flappen → gesamtes Netz/internet weg. Das ist bereits passiert (2026-06-27).

---

VM **104** (`opnsense-fallback`) auf pve1 ist als **CARP-Backup** vorbereitet. Die Config wurde **offline** auf der Disk angepasst (ZFS-Pool gemountet).

## Rollen

| Rolle | Host | VM | Mgmt-IP (phys.) | CARP VIP | advskew |
|-------|------|-----|-----------------|----------|---------|
| **Master** | pve2 | 104 `opnsense` | 192.168.10.2 | 192.168.10.1 | 0 |
| **Backup** | pve1 | 104 `opnsense-fallback` | 192.168.10.3 | 192.168.10.1 | 100 |

- **advbase:** 1 (beide)
- **Regel:** niedrigerer advskew = höhere Priorität → Master (0) hält VIPs, solange erreichbar

Weitere CARP-Gateways (VIP jeweils `.1`, physische Backup-IPs `.3`):

| Netz | VLAN | CARP VIP | Backup-IP |
|------|------|----------|-----------|
| Management | 10 | 192.168.10.1 | 192.168.10.3 |
| Privat | 20 | 192.168.20.1 | 192.168.20.3 |
| Gäste | 30 | 192.168.30.1 | 192.168.30.3 |
| IoT | 40 | 192.168.40.1 | 192.168.40.3 |
| IPCAM | 50 | 192.168.50.1 | 192.168.50.3 |
| VoIP | 60 | 192.168.60.1 | 192.168.60.3 |

- **CARP-VHIDs:** 10, 20, 30, 40, 50, 60 (identisch auf beiden Nodes)
- **CARP-Passwort:** identisch auf beiden Nodes
- **pfsync/XMLRPC:** Primary-Peer `192.168.10.2`, Backup-Peer `192.168.10.3`
- **Hostname Backup:** `OPNsense-Fallback`

## Beide Router laufen parallel

Bei CARP **müssen** Master (pve2) und Backup (pve1) **gleichzeitig laufen**. CARP regelt, wer die `.1`-VIPs hält — nicht Start/Stop als Normalbetrieb.

## Warum ungeplanter Start/Stop die Verbindung killt

Das Gateway im gesamten Netz ist die **CARP-VIP** `192.168.10.1` (und analog `.1` in anderen VLANs) — keine feste physische IP.

Beim Start oder Stop eines Router-Knotens passiert:

1. **CARP-Neuverhandlung** — wer hält `.1`?
2. **VIP flapped** — kurz weg, doppelt, oder falsche MAC
3. **Clients verlieren Gateway** → Internet/Management weg

**Besonders kritisch:**

- **Start + Stop hintereinander** = zwei CARP-Transitions → doppelter Ausfall
- **Backup hört Master nicht** (kein sauberes L2 auf dem VLAN-Trunk zwischen pve1 und pve2): Backup denkt „kein Master“, übernimmt `.1` trotz advskew 100 → **Split-Brain** mit laufendem Master → ARP-Chaos

advskew 0/100 schützt **nur**, wenn beide Nodes sich gegenseitig am Trunk sehen.

## Was beim Failover zählt — und was nicht

### vmbr0 + VLAN-Trunk (relevant)

- OPNsense `vtnet0` → Proxmox `vmbr0` (VLAN-aware, alle VLANs getagged)
- CARP übernimmt die `.1`-Gateways im gesamten VLAN-Netz
- Das ist der **eigentliche Failover-Pfad**

### vmbr1 / Services (nicht Teil von CARP)

`vmbr1` ist auf **jedem Host eine lokale, isolierte Bridge** — kein vSwitch, kein geteiltes L2 zwischen pve1 und pve2.

- OPNsense **opt7 (SERVICES)** → `vtnet1` → `vmbr1`
- IP auf beiden Router-Instanzen: **`10.100.2.1/24`**
- **Kein CARP** auf `10.100.2.0/24`

## VM-Netzwerk pve1 (104)

| Proxmox | OPNsense | Bridge | MAC |
|---------|----------|--------|-----|
| net0 | vtnet0 (VLAN-Trunk) | vmbr0 | BC:24:11:A1:B2:C3 |
| net1 | vtnet1 (SERVICES) | vmbr1 | BC:24:11:D4:E5:F6 |

## Offline-Vorbereitung (bereits erledigt)

Config-Änderungen direkt auf `/dev/pve/vm-104-disk-0` (ZFS `zroot`):

1. Physische VLAN-IPs von `.2` → `.3` (Backup)
2. CARP `advskew` von `0` → `100`
3. HA-Peer auf Primary `192.168.10.2` zeigen lassen
4. **opt7 (SERVICES):** `10.100.2.1` belassen

Backup der Config vor Änderung: `/tmp/config.xml.bak-failover`

### Config erneut offline bearbeiten

```bash
modprobe nbd max_part=8
qemu-nbd --connect=/dev/nbd1 /dev/pve/vm-104-disk-0 --format=raw
zpool import -f -R /mnt/opnsense-new -d /dev/nbd1p4 15187354659129106435 new-zroot
zfs mount new-zroot/ROOT/default
# /mnt/opnsense-new/conf/config.xml bearbeiten
zfs umount -a -f; zpool export -f new-zroot
qemu-nbd -d /dev/nbd1
```

## Manueller Failover — nur durch Betreiber

**Kein automatischer Test. Kein Agent-Start/Stop.**

### Voraussetzungen

- Beide Nodes normalerweise **parallel** im CARP-Betrieb
- Echter Failover-Test: bewusst geplant, physischer Zugang als Fallback
- VLAN-Trunk: pve1 und pve2 müssen sich CARP-seitig am Trunk sehen

### Prüfliste (Betreiber)

- [ ] pve2 Master läuft, VIP `.1` antwortet
- [ ] pve1 Backup läuft parallel, **hält keine VIPs** (skew 100)
- [ ] pve1 pingt `192.168.10.2`, pve2 pingt `192.168.10.3`
- [ ] Erst bei geplantem Test: Master stoppen → Backup übernimmt VIPs

### Befehle (nur Betreiber, nicht Agent)

```bash
# Failover-Test (Beispiel — nur manuell!)
ssh root@192.168.10.4 "qm stop 104"   # Master stoppen
# Backup auf pve1 sollte VIPs übernehmen
qm terminal 104                        # Konsole prüfen

# Zurück
qm stop 104                            # Backup stoppen
ssh root@192.168.10.4 "qm start 104"  # Master wieder
```

## Fallback-Kopie aktualisieren

Bei größeren OPNsense-Änderungen auf pve2: Backup/Restore (siehe `03_backup_restore.md`), danach Backup-Rolle (advskew 100, IPs `.3`) wieder **offline** setzen.