Schritt A: VLANs nicht mehr an Horus routen (NAT-Modell).

OPNsense-Peer nur 10.1.1.22/32 + 10.100.2/24; OPNsense-NAT-Checkliste ergänzt. Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-28 13:25:50 +02:00
parent 98d41347ab
commit 8897103d45
4 changed files with 101 additions and 8 deletions
@@ -0,0 +1,91 @@
+# Schritt A — VLANs → Horus per NAT (OPNsense)
+
+**Ziel:** LAN/VLANs erreichen Horus, aber Horus kennt **keine** `192.168.x`-Subnetze (kein Routing zurück ins Heimnetz).
+
+| Richtung | Verhalten |
+|----------|-----------|
+| VLAN → Horus | ✅ NAT (Quelle wird `10.1.1.22`) |
+| Horus → VLAN | ❌ nicht möglich (Horus kennt VLANs nicht) |
+| Horus ↔ `10.100.2.0/24` | ✅ bidirektional (Services, OPNsense-Peer) |
+| Horus ↔ `10.2.2.0/24` | ✅ über **VM-Peer** (`10.1.1.5`), nicht OPNsense |
+
+**Horus-Seite:** erledigt — OPNsense-Peer `AllowedIPs` = `10.1.1.22/32`, `10.100.2.0/24` only.
+
+---
+
+## OPNsense — Checkliste
+
+### 1. WireGuard Peer „horus“ (unverändert sinnvoll)
+
+Peer **Allowed IPs** (Horus-Netze, outbound vom Router):
+
+`10.1.1.0/24, 10.1.2.0/24, 10.1.3.0/24, 10.1.4.0/24, 10.8.0.0/24`
+
+Local Instance: Tunnel `10.1.1.22/32`, Keys aus [opnsense-client.conf](opnsense-client.conf).
+
+### 2. Outbound NAT
+
+**Firewall → NAT → Outbound**
+
+Modus: **Hybrid** (oder Manual), damit eine explizite Regel greift.
+
+Neue Regel (oben):
+
+| Feld | Wert |
+|------|------|
+| Interface | `horusopnsense` (WG) |
+| TCP/IP Version | IPv4 |
+| Source | Alias z. B. `RFC1918` oder einzeln: `192.168.10.0/24`, `.20`, `.30`, `.40`, `.50`, `.60` |
+| Destination | `10.1.1.0/24`, `10.1.2.0/24`, `10.1.3.0/24`, `10.1.4.0/24`, `10.8.0.0/24` (Alias `HORUS_WG`) |
+| Translation / Target | **Interface address** (`10.1.1.22`) |
+
+Nicht NATen: Traffic zu `10.2.2.0/24`, `10.100.2.0/24` (bleiben intern geroutet, kein Horus-WG).
+
+### 3. Firewall
+
+**LAN / VLAN10 / VLAN20 / … → Horus**
+
+| Source | Destination | Action |
+|--------|-------------|--------|
+| VLAN-Subnetz | Alias `HORUS_WG` | Pass |
+
+**WG `horusopnsense` → LAN**
+
+| Source | Destination | Action |
+|--------|-------------|--------|
+| `10.1.1.0/24` (Horus) | RFC1918 / VLANs | **Block** (Defense in depth; Horus routet dorthin ohnehin nicht) |
+
+Ausnahme Services: Horus → `10.100.2.0/24` läuft über OPNsense-Routing (kein NAT nötig für initiierte Verbindungen von Horus, wenn gewünscht — ggf. separate Pass-Regel WG → `10.100.2.0/24`).
+
+### 4. Static Routes prüfen
+
+**System → Routes**
+
+- Kein Eintrag `10.1.1.0/24` via `192.168.178.1` o. ä.
+- `10.2.2.0/24` → `192.168.10.10` (VM) — **bleibt**
+- `10.100.2.0/24` → opt7 — **bleibt**
+
+### 5. Test
+
+Vom PC (VLAN20):
+
+```powershell
+tracert 10.1.1.1     # Hop 1 OPNsense, danach Horus (kein 192.168.178.x)
+ping 10.1.1.1
+ssh root@10.1.1.1
+```
+
+Auf Horus (via VM):
+
+```bash
+ssh jean@192.168.10.10 'ssh root@10.1.1.1 wg show wg0 | grep -A5 walbWTYX'
+# allowed ips: nur 10.1.1.22/32, 10.100.2.0/24
+```
+
+Horus sollte eingehende SSH/Ping von **`10.1.1.22`** sehen (NAT), nicht von `192.168.20.x`.
+
+---
+
+## Referenz Horus
+
+[horus-server-peer-opnsense.conf](horus-server-peer-opnsense.conf) · [wg0-opnsense-routes.sh](wg0-opnsense-routes.sh)