jean/docu
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Doku: Horus Internet-Gateway (Handy + OPNsense LAN).

Browse Source 
Road-Warrior-Setup mit UFW wg0→eth0 und pixel7-Config; OPNsense-LAN-Exit
über HORUS_GW + Outbound-SNAT 10.1.1.22 als verifizierter Breakpoint.

Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
root
2026-06-28 18:17:49 +02:00
parent 3783762769
commit 3cd45f9f3f
6 changed files with 378 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
horus/README.md
+4 -2
View File
@@ -20,8 +20,10 @@
- **Verwaltung: `wg-quick@wg0`** (systemd, enabled). **Es läuft KEIN wireguard-ui** (kein Prozess/Container/Port 5000) — die `wg0.conf` wurde nur *historisch* damit erzeugt. - **Verwaltung: `wg-quick@wg0`** (systemd, enabled). **Es läuft KEIN wireguard-ui** (kein Prozess/Container/Port 5000) — die `wg0.conf` wurde nur *historisch* damit erzeugt.
- Server-Config: `/etc/wireguard/wg0.conf` (Header sagt „don't edit manually", aber maßgeblich ist, was `wg-quick` lädt → `wg show wg0` / `wg showconf wg0` ist die Wahrheit). - Server-Config: `/etc/wireguard/wg0.conf` (Header sagt „don't edit manually", aber maßgeblich ist, was `wg-quick` lädt → `wg show wg0` / `wg showconf wg0` ist die Wahrheit).
- Client-Keys/Configs: `/etc/wireguard/clients/<name>/` (je `client.conf`, `privatekey`, `publickey`, `presharedkey`), Backup unter `/etc/wireguard/bak/`. - Client-Keys/Configs: `/etc/wireguard/clients/<name>/` (je `client.conf`, `privatekey`, `publickey`, `presharedkey`), Backup unter `/etc/wireguard/bak/`. Repo-Kopien: [clients/](clients/).
- Listen-Port: `61951/udp`. PostUp/PostDown setzen iptables FORWARD/NAT. - Listen-Port: `61951/udp`. PostUp/PostDown in `wg0.conf` sind **auskommentiert**; Forward/NAT über **UFW route** + Docker-MASQUERADE.
- **Internet-Gateway** für Road-Warrior-Clients (pixel7): [wireguard-internet-gateway.md](wireguard-internet-gateway.md) — UFW `wg0→eth0`, Client `AllowedIPs` inkl. `0.0.0.0/0`.
- **Site-to-Site** OPNsense/VM 101: kein Full-Tunnel — [../shared/horus-opnsense-wireguard/README.md](../shared/horus-opnsense-wireguard/README.md).
- **Peers sauber löschen** (ohne UI): `[Peer]`-Block aus `wg0.conf` entfernen **+** `clients/<name>/` löschen **+** `wg syncconf wg0 <(wg-quick strip wg0)` (oder `systemctl restart wg-quick@wg0`). - **Peers sauber löschen** (ohne UI): `[Peer]`-Block aus `wg0.conf` entfernen **+** `clients/<name>/` löschen **+** `wg syncconf wg0 <(wg-quick strip wg0)` (oder `systemctl restart wg-quick@wg0`).
- Vorfall NAT/Port siehe [../issues/2026-06-28-vm101-horus-wireguard-nat.md](../issues/2026-06-28-vm101-horus-wireguard-nat.md). - Vorfall NAT/Port siehe [../issues/2026-06-28-vm101-horus-wireguard-nat.md](../issues/2026-06-28-vm101-horus-wireguard-nat.md).
horus/clients/pixel7-client.conf
+15
View File
@@ -0,0 +1,15 @@
# Horus WireGuard — Client pixel7 (Road Warrior, Internet-Gateway)
# Quelle: /etc/wireguard/clients/pixel7/client.conf auf Horus
# Stand: 2026-06-28 — AllowedIPs inkl. 0.0.0.0/0 für Internet via Horus
[Interface]
PrivateKey = EPwmQ19R5xUjV7Ve9IpJ/39mFDflHUmpVNkXTgjuSkM=
Address = 10.1.1.15/32
DNS = 1.1.1.1, 1.0.0.1
[Peer]
PublicKey = qXxhgerS2ORypVadhKCBuxgIX5Pu4J75nSWazdtd+Qk=
PresharedKey = /zmUIQ9QW3W9Q3PuZNuMZ1t6xOzdSTRt7qBFCHxQcik=
AllowedIPs = 10.1.1.0/24, 192.168.2.0/24, 10.1.2.0/24, 10.8.0.0/24, 0.0.0.0/0
Endpoint = 207.180.222.207:61951
PersistentKeepalive = 15
horus/wireguard-internet-gateway.md
+189
View File
@@ -0,0 +1,189 @@
# Horus — WireGuard Internet-Gateway
Road-Warrior-Clients (Handy, Laptop) sollen das **Internet über Horus** nutzen können — Exit-IP ist dann **`207.180.222.207`**.
**Eingerichtet:** 2026-06-28 · **Verifiziert:** pixel7 (Handy), Exit-IP `207.180.222.207`
**Betrifft nicht:** OPNsense-Site-to-Site und VM-101-Tunnel (bleiben Split-Tunnel, kein `0.0.0.0/0`).
**LAN hinter OPNsense:** separates Setup → [../shared/horus-opnsense-wireguard/opnsense-internet-gateway.md](../shared/horus-opnsense-wireguard/opnsense-internet-gateway.md)
---
## Architektur
```
[Client z.B. pixel7 10.1.1.15]
│ WireGuard (AllowedIPs inkl. 0.0.0.0/0)
▼
[Horus wg0 10.1.1.1]
│ ip_forward=1, UFW route wg0→eth0, MASQUERADE
▼
[eth0 → Internet]
```
| Peer-Typ | Tunnel-IP | Internet via Horus? | AllowedIPs (Client-Seite) |
|----------|-----------|---------------------|---------------------------|
| **pixel7** (Road Warrior) | `10.1.1.15` | **Ja** | interne Netze + **`0.0.0.0/0`** |
| **OPNsense** | `10.1.1.22` | **Nein** | nur `10.1.1.0/24`, `10.1.2–4.0/24`, `10.8.0.0/24` |
| **VM 101** | `10.1.1.5` | **Nein** | nur Horus/docbr0-Netze |
---
## Symptom (vor dem Fix)
- WG-Tunnel steht (Handshake ok), interne Horus-Netze erreichbar
- **Kein Internet** vom Client — `ping 8.8.8.8` / Browser tot
- Horus selbst hatte Internet; NAT-Regeln existierten teilweise schon
---
## Ursachen (zwei Breakpoints)
### 1. UFW blockierte Forward wg0 → eth0
- `DEFAULT_FORWARD_POLICY="DROP"` in `/etc/default/ufw`
- Bestehende UFW-Regel: nur **`wg0 → wg0`** (Peer-zu-Peer), nicht **`wg0 → eth0`**
- Zusätzlich existierte in `/etc/ufw/before.rules` noch `-A FORWARD -i wg0 -j ACCEPT` — reichte aber nicht sauber für gerouteten Traffic unter UFW „deny (routed)"
### 2. Client ohne Default-Route im Tunnel
- **pixel7** hatte in `AllowedIPs` nur interne Netze, **kein `0.0.0.0/0`**
- Ohne `0.0.0.0/0` schickt der Client kein Internet-Traffic in den Tunnel (Split-Tunnel-Verhalten)
Server-seitig waren bereits vorhanden (keine Änderung nötig):
- `net.ipv4.ip_forward = 1`
- `iptables -t nat POSTROUTING -o eth0 -j MASQUERADE` (über Docker/mailcow-Setup)
- `rp_filter = 0` auf wg0/eth0
---
## Änderungen auf Horus (2026-06-28)
### UFW Route-Regeln (persistent)
```bash
ufw route allow in on wg0 out on eth0 comment 'WG clients internet gateway'
ufw route allow in on eth0 out on wg0 comment 'WG clients internet return'
```
Verifikation:
```bash
ufw status verbose | grep -E 'FWD|wg0|eth0'
iptables -L ufw-user-forward -n -v
# Erwartung: ACCEPT wg0→eth0 und eth0→wg0 mit steigenden Paket-Zählern
```
Aktuelle nummerierte Regeln (Stand nach Einrichtung):
| # | Regel |
|---|--------|
| 9 | `Anywhere on eth0 ALLOW FWD Anywhere on wg0` (# WG clients internet gateway) |
| 10 | `Anywhere on wg0 ALLOW FWD Anywhere on eth0` (# WG clients internet return) |
*(UFW zeigt in/out in der Status-Ansicht manchmal spiegelverkehrt zur Kommentar-Zeile — maßgeblich sind die iptables-Zeilen in `ufw-user-forward`.)*
### Client pixel7
Datei auf Horus: `/etc/wireguard/clients/pixel7/client.conf`
Backup: `/etc/wireguard/clients/pixel7/client.conf.bak.20260628`
Kopie im Repo: [clients/pixel7-client.conf](clients/pixel7-client.conf)
**Geändert:**
- `DNS = 1.1.1.1, 1.0.0.1` ergänzt
- `AllowedIPs = …, 0.0.0.0/0` ergänzt (interne Netze bleiben explizit drin)
**Nicht geändert:**
- `/etc/wireguard/wg0.conf` (Server-Peer-Block für pixel7 bleibt `AllowedIPs = 10.1.1.15/32`)
- OPNsense- und VM-101-Peers
---
## Neuen Road-Warrior-Client einrichten
1. Peer in `/etc/wireguard/wg0.conf` + Verzeichnis `/etc/wireguard/clients/<name>/`
2. Client-Config mit:
```ini
DNS = 1.1.1.1, 1.0.0.1
AllowedIPs = 10.1.1.0/24, 10.1.2.0/24, …, 0.0.0.0/0
```
*(oder nur `0.0.0.0/0` für Full-Tunnel)*
3. Server-seitig **keine** weiteren Schritte — UFW-Route-Regeln gelten für alle wg0-Peers
4. Config auf dem Gerät **neu importieren** (QR/Datei), Tunnel neu verbinden
---
## Client-Config neu laden (pixel7)
```bash
ssh jean@192.168.10.10
ssh root@10.1.1.1 cat /etc/wireguard/clients/pixel7/client.conf
```
Am Gerät: alte WG-Verbindung löschen oder Config ersetzen, neu importieren, Tunnel aktivieren.
---
## Tests
```bash
# Am Client (Browser oder Termux)
curl -4 ifconfig.me
# Erwartung: 207.180.222.207
ping -c3 8.8.8.8
```
```bash
# Auf Horus während Client-Traffic
ssh root@10.1.1.1 'iptables -L ufw-user-forward -n -v | grep wg0'
ssh root@10.1.1.1 'tcpdump -ni wg0 host 10.1.1.15 and not net 10.0.0.0/8'
```
---
## Troubleshooting
### Häufigster Stolperstein: DNS (pixel7, 2026-06-28)
Server-Forward/NAT war **schon ok** — trotzdem wirkte „kein Internet“, weil das Handy DNS an **`10.3.2.5`** schickte statt an **`1.1.1.1`** aus der WG-Config.
**Fix am Client:**
- WG-Profil **löschen + neu importieren** (Bearbeiten reicht oft nicht)
- Android: **Einstellungen → Netzwerk → Privates DNS** → **Aus** oder **Automatisch**
- Danach: `ping 8.8.8.8` ok, Browser/`curl ifconfig.me` → `207.180.222.207`
**Diagnose auf Horus:**
```bash
tcpdump -ni wg0 "host 10.1.1.15 and port 53"
# Falsch: Ziele wie 10.3.2.5
# Richtig: 1.1.1.1 / 1.0.0.1 (oder DoH außerhalb des Tunnels)
```
| Symptom | Prüfung |
|---------|---------|
| Intern ok, Internet tot | Zuerst **DNS** (s.o.), dann `AllowedIPs` mit **`0.0.0.0/0`** |
| Horus sieht keinen Traffic | `wg show wg0` — Handshake aktiv? |
| Forward blockiert | `iptables -L ufw-user-forward -n -v` — Zähler wg0→eth0 steigen? |
| Ping ok, Browser tot | DNS; Horus-bind9 lauscht nur auf **`207.180.222.207:53`**, nicht auf `10.1.1.1` |
| Exit-IP falsch | Alte Config ohne `0.0.0.0/0` oder Split-Tunnel aktiv |
---
## Was bewusst nicht gemacht wurde
- **Kein** `0.0.0.0/0` für OPNsense oder VM 101 (würde Site-to-Site / Split-Routing kaputt machen)
- **Kein** bind9 auf `10.1.1.1` — öffentliche DNS (`1.1.1.1`) reicht für Clients
- **PostUp** in `wg0.conf` bleibt auskommentiert — Forward/NAT über UFW + bestehendes Docker-MASQUERADE
---
## Referenzen
| Thema | Doc |
|-------|-----|
| Horus allgemein | [README.md](README.md) |
| OPNsense Site-to-Site | [../shared/horus-opnsense-wireguard/README.md](../shared/horus-opnsense-wireguard/README.md) |
| VM-101 NAT-Vorfall | [../issues/2026-06-28-vm101-horus-wireguard-nat.md](../issues/2026-06-28-vm101-horus-wireguard-nat.md) |
issues/README.md
+1
View File
@@ -24,3 +24,4 @@ Das Handover beschreibt den *aktuellen Übergabestand*. Hier dagegen landen **ab
|-------|---------|--------| |-------|---------|--------|
| 2026-06-28 | [VM 101 ↔ Horus WireGuard tot (NAT, nicht Keys)](2026-06-28-vm101-horus-wireguard-nat.md) | gelöst | | 2026-06-28 | [VM 101 ↔ Horus WireGuard tot (NAT, nicht Keys)](2026-06-28-vm101-horus-wireguard-nat.md) | gelöst |
| 2026-06-28 | [OPNsense ↔ Horus Tunnel + LAN (Route, Firewall wg_horus, NAT)](2026-06-28-opnsense-horus-wireguard-lan.md) | gelöst | | 2026-06-28 | [OPNsense ↔ Horus Tunnel + LAN (Route, Firewall wg_horus, NAT)](2026-06-28-opnsense-horus-wireguard-lan.md) | gelöst |
| 2026-06-28 | WG-Clients Internet via Horus (UFW wg0→eth0, pixel7 AllowedIPs) | gelöst → [../horus/wireguard-internet-gateway.md](../horus/wireguard-internet-gateway.md) |
shared/horus-opnsense-wireguard/README.md
+3
View File
@@ -39,6 +39,7 @@ Direkter WireGuard-Tunnel zwischen **OPNsense** (lokales Netz) und **Horus** (VP
|-------|--------| |-------|--------|
| [opnsense-client.conf](opnsense-client.conf) | Keys, PSK, Endpoint (OPNsense) | | [opnsense-client.conf](opnsense-client.conf) | Keys, PSK, Endpoint (OPNsense) |
| [opnsense-step-a-nat.md](opnsense-step-a-nat.md) | **OPNsense-Setup** (Route, Firewall, NAT) | | [opnsense-step-a-nat.md](opnsense-step-a-nat.md) | **OPNsense-Setup** (Route, Firewall, NAT) |
| [opnsense-internet-gateway.md](opnsense-internet-gateway.md) | **Optional:** LAN-Internet-Exit über Horus (GUI-only) |
| [horus-server-peer-opnsense.conf](horus-server-peer-opnsense.conf) | Horus Peer-Block | | [horus-server-peer-opnsense.conf](horus-server-peer-opnsense.conf) | Horus Peer-Block |
| [wg0-opnsense-routes.sh](wg0-opnsense-routes.sh) | Horus Route-Script | | [wg0-opnsense-routes.sh](wg0-opnsense-routes.sh) | Horus Route-Script |
| [vm101-client.conf](vm101-client.conf) / [horus-server-peer-vm101.conf](horus-server-peer-vm101.conf) | VM-Tunnel (getrennt) | | [vm101-client.conf](vm101-client.conf) / [horus-server-peer-vm101.conf](horus-server-peer-vm101.conf) | VM-Tunnel (getrennt) |
@@ -66,6 +67,8 @@ Fritzbox: OPNsense in **DMZ** — kein extra WAN-Forwarding für WG.
- Peer `walbWTYX…`: AllowedIPs `10.1.1.22/32`, `10.100.2.0/24` - Peer `walbWTYX…`: AllowedIPs `10.1.1.22/32`, `10.100.2.0/24`
- `wg0-opnsense-routes.service` für Kernel-Routen zu OPNsense/Services - `wg0-opnsense-routes.service` für Kernel-Routen zu OPNsense/Services
- VM-Peer: `10.1.1.5/32`, `10.2.2.0/24` only - VM-Peer: `10.1.1.5/32`, `10.2.2.0/24` only
- **Road-Warrior Internet-Gateway** (pixel7): [../../horus/wireguard-internet-gateway.md](../../horus/wireguard-internet-gateway.md)
- **LAN-Internet über OPNsense:** [opnsense-internet-gateway.md](opnsense-internet-gateway.md) — Gateway `10.1.1.1` + **SNAT `10.1.1.22`** (verifiziert 2026-06-28)
--- ---
shared/horus-opnsense-wireguard/opnsense-internet-gateway.md
+166
View File
@@ -0,0 +1,166 @@
# OPNsense — Internet optional über Horus (LAN-Gateway)
**Stand:** 2026-06-28
**Status:** **Verifiziert** — Gateway `HORUS_GW` (`10.1.1.1` auf `wg_horus`) + **Outbound SNAT** auf `10.1.1.22` · Exit-IP `207.180.222.207`
**Agent:** kein OPNsense-Zugang — Breakpoint war fehlendes SNAT, nicht das Gateway
Das ist **nicht** dasselbe wie beim Handy (pixel7): Dort trägt der Client selbst `0.0.0.0/0` in WireGuard.
Hinter OPNsense entscheidet der **Router** per Gateway/Firewall/NAT, welcher LAN-Traffic über `wg_horus` rausgeht.
---
## Wann welches Modell?
| Modell | Wer | Mechanismus | Doc |
|--------|-----|-------------|-----|
| **Road Warrior** | Handy/Laptop mit WG-App | Client-Config `AllowedIPs = …, 0.0.0.0/0` | [../../horus/wireguard-internet-gateway.md](../../horus/wireguard-internet-gateway.md) |
| **LAN über OPNsense** | PCs hinter OPNsense | OPNsense-Gateway + Firewall + Outbound-NAT auf `wg_horus` | **dieses Doc** |
**Basis-Site-to-Site** (Horus-Netze, LAN→Horus) bleibt: [opnsense-step-a-nat.md](opnsense-step-a-nat.md) — **nicht** entfernen.
---
## Topologie (LAN-Internet via Horus)
```
LAN-PC (192.168.x) → OPNsense → wg_horus (SNAT 10.1.1.22) → Horus → eth0/NAT → Internet
Exit-IP im Internet: 207.180.222.207
```
**Horus (bereits erledigt, 2026-06-28):**
- `ip_forward=1`
- UFW route `wg0 → eth0` (+ Rückweg)
- `MASQUERADE` auf `eth0` (alle Quellen inkl. `10.1.1.22`)
- Routing-Test: `ip route get 8.8.8.8 from 10.1.1.22 iif wg0` → via `eth0` ✓
**Wichtig:** Wenn du am OPNsense testest und es wieder deaktivierst, sieht Horus **keinen** Internet-Traffic von `10.1.1.22` — tcpdump bleibt leer. Das ist normal.
---
## Empfohlen: nur bestimmte LAN-Hosts (Policy Gateway)
**Nicht** gleich `0.0.0.0/0` als Static Route fürs ganze OPNsense — das killt den normalen WAN-Weg über Fritzbox.
### 1. Gateway anlegen
**System → Routing → Gateways → Single → Add**
| Feld | Wert |
|------|------|
| Name | `HORUS_INET` |
| Interface | **`wg_horus` (opt10)** |
| Gateway | **`10.1.1.1`** ← Horus-Tunnel-IP |
| Monitor | optional aus, oder Monitor-IP `1.1.1.1` (nur wenn du weißt was du tust) |
| Default Gateway | **Nein** |
**Häufiger Fehler:** Gateway `192.168.178.1` (Fritzbox) oder `10.1.1.21` — **falsch**, Interface liegt am Tunnel.
### 2. Outbound NAT (Internet, nicht nur Horus-Netze) — **Pflicht**
Step A ([opnsense-step-a-nat.md](opnsense-step-a-nat.md)) NATet nur **LAN → `HORUS_WG`** (z. B. `10.1.1.0/24`).
**Ohne SNAT funktioniert es nicht**, auch wenn Gateway-Monitoring auf `10.1.1.1` grün ist: Monitoring pingt nur OPNsense→Horus; LAN-Traffic hat sonst Quelle `192.168.x` — Horus kennt den Rückweg nicht (Peer nur `10.1.1.22/32`).
Für **Internet** brauchst du **zusätzlich** (Hybrid-Modus, Regel **oben**):
| Feld | Wert |
|------|------|
| Interface | **`wg_horus`** |
| Source | Alias z. B. `HORUS_INET_CLIENTS` (nur die PCs die Horus-Exit nutzen sollen) |
| Destination | **`any`** |
| Translation | **Interface address** → `10.1.1.22` |
Ohne diese Regel: Horus sieht ggf. `192.168.x` als Quelle oder verwirft/ routet falsch.
### 3. Firewall LAN
**Firewall → Rules → LAN** (Regel **über** block/deny):
| Feld | Wert |
|------|------|
| Action | Pass |
| Source | `HORUS_INET_CLIENTS` |
| Destination | `any` |
| Gateway | **`HORUS_INET`** |
| Description | `Internet via Horus WG` |
Rest des LANs: **kein** Gateway → normaler WAN-Weg (Fritzbox).
### 4. WireGuard Peer „horus“ — Allowed IPs
**Für Policy-Gateway reicht meist:**
```
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
```
**Kein** `0.0.0.0/0` nötig, wenn du nur per Firewall-Gateway routest.
**Disable routes** kann **an** bleiben — Static Route `10.1.1.0/24 → 10.1.1.1` via `wg_horus` (Step A) bleibt.
### 5. DNS
Clients hinter OPNsense nutzen weiter OPNsense/Unbound — **nicht** automatisch Horus-DNS.
Wenn Browser „tot“, obwohl `ping 8.8.8.8` geht: DNS/Filter auf OPNsense prüfen, nicht Horus-NAT.
---
## Alternative (riskant): gesamtes OPNsense-Internet über Horus
Nur wenn bewusst gewollt (Surfshark/WAN entfällt als Default):
- Peer Allowed IPs um **`0.0.0.0/0`** erweitern **oder** Default-Route via `10.1.1.1` auf `wg_horus`
- Outbound NAT auf `wg_horus` für **`any`**
- Konflikt mit **mehreren WG-Instanzen** (Surfshark, WGServer) — „Disable routes“ und Routing-Tabelle genau prüfen
**Nicht empfohlen** ohne klaren Plan — schnell kein Internet mehr über Fritzbox.
---
## Tests (Reihenfolge)
| # | Wo | Befehl | Erwartung |
|---|-----|--------|-----------|
| 1 | OPNsense | Diagnostics → Ping, Source **wg_horus** → `10.1.1.1` | ok (~17 ms) |
| 2 | Horus | `ping 10.1.1.22` | ok |
| 3 | LAN-Test-PC (mit Gateway-Regel) | `ping 8.8.8.8` | ok |
| 4 | LAN-Test-PC | `curl -4 ifconfig.me` | **`207.180.222.207`** |
| 5 | Horus (während Test) | `tcpdump -ni wg0 host 10.1.1.22 and not net 10.1.0.0/16` | Traffic zu 8.8.8.8/443 |
| 6 | Anderer LAN-PC (ohne Regel) | `curl ifconfig.me` | **Fritzbox-WAN-IP**, nicht Horus |
---
## Troubleshooting (OPNsense — Agent blind)
| Symptom | Erste Prüfung in OPNsense GUI |
|---------|-------------------------------|
| Gateway-Monitoring ok, LAN-Internet tot | **Outbound SNAT** auf `wg_horus` → `10.1.1.22`, Destination **`any`** fehlt (häufigster Fix) |
| Gar kein Traffic auf Horus | Gateway **`10.1.1.1`**, Interface **`wg_horus`**, Firewall-Regel mit Gateway gesetzt? |
| Handshake ok, LAN-Internet tot | Outbound NAT **`any`** auf `wg_horus`, nicht nur `HORUS_WG` |
| Nur Horus-Netze ok | Step A ok, Step Internet-NAT fehlt (s.o.) |
| Alles tot nach Experiment | Static Route / Allowed IPs `0.0.0.0/0` wieder entfernen, Default Gateway WAN reaktivieren |
| Live View leer | Traffic geht noch über WAN — Gateway-Regel greift nicht (Source/Order) |
**Firewall → Log Files → Live View** während Test — einziger zuverlässiger Beweis ohne SSH.
---
## Deaktivieren (Rollback)
1. Firewall-Regel „Internet via Horus WG“ **disable/delete**
2. Outbound-NAT-Regel `wg_horus` → **`any`** **disable/delete**
3. Gateway `HORUS_INET` optional löschen
4. **Nicht** Step-A-Regeln (LAN→Horus-Netze) anfassen
Danach tcpdump auf Horus wieder leer — erwartet.
---
## Referenzen
| Doc | Inhalt |
|-----|--------|
| [opnsense-step-a-nat.md](opnsense-step-a-nat.md) | Site-to-Site + LAN→Horus-Netze |
| [../../horus/wireguard-internet-gateway.md](../../horus/wireguard-internet-gateway.md) | Handy/Road Warrior |
| [../../issues/2026-06-28-opnsense-horus-wireguard-lan.md](../../issues/2026-06-28-opnsense-horus-wireguard-lan.md) | Gateway-Fehler `.21`/Fritzbox |