Doku: OPNsense↔Horus WG produktiv (Route, Firewall, LAN/NAT).
Issue-Vorfall 2026-06-28, opnsense-step-a-nat und README mit Gateway 10.1.1.1 und wg_horus-Regeln. Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
@@ -1,64 +1,139 @@
|
||||
# Schritt A — LAN/VLAN → Horus per NAT (OPNsense)
|
||||
# OPNsense — Horus WireGuard (Routing, Firewall, LAN/NAT)
|
||||
|
||||
**Ziel:** Interne Hosts (LAN/VLANs) erreichen Horus (`10.1.1.1` + dort gehostete Dienste) über den OPNsense↔Horus-WireGuard-Tunnel. Horus kennt **keine** `192.168.x`-Netze → Rückrouting ins Heimnetz ist nicht möglich (gewollt).
|
||||
**Stand:** 2026-06-28 (produktiv getestet)
|
||||
**Interface:** `wg_horus` (opt10) · Tunnel-IP **`10.1.1.22`** · Horus **`10.1.1.1`**
|
||||
|
||||
| Richtung | Verhalten |
|
||||
|----------|-----------|
|
||||
| LAN/VLAN → Horus | ✅ via NAT (Quelle wird `10.1.1.22`) |
|
||||
| Horus → LAN/VLAN | ❌ nicht möglich (Horus kennt die Netze nicht) |
|
||||
| Horus ↔ `10.100.2.0/24` | ✅ bidirektional (Services, OPNsense-Peer) |
|
||||
| Horus ↔ `10.2.2.0/24` | ✅ über **VM-101-Peer** (`10.1.1.5`), nicht OPNsense |
|
||||
|
||||
## Warum NAT zwingend ist
|
||||
|
||||
Horus' Peer-Eintrag für OPNsense hat `AllowedIPs = 10.1.1.22/32, 10.100.2.0/24`. WireGuard verwirft jedes Antwortpaket an eine Quelle, die **nicht** in diesen AllowedIPs steht. LAN-Traffic (`192.168.x`) muss daher **vor** dem Tunnel auf `10.1.1.22` ge-SNAT-et werden — sonst kommt von Horus nie eine Antwort zurück.
|
||||
Vollständiger Vorfall: [../../issues/2026-06-28-opnsense-horus-wireguard-lan.md](../../issues/2026-06-28-opnsense-horus-wireguard-lan.md)
|
||||
|
||||
---
|
||||
|
||||
## 0. Voraussetzung
|
||||
## Topologie
|
||||
|
||||
WireGuard-Instanz „horus" als **Interface zuweisen** (*Interfaces → Assignments*), Tunnel-Adresse `10.1.1.22/32`, z. B. Name `horusopnsense`. Nötig für NAT-Interface + Firewallregeln.
|
||||
```
|
||||
LAN/VLAN (192.168.x) → OPNsense (NAT → 10.1.1.22) → wg_horus → Horus 10.1.1.1
|
||||
Services (10.100.2.0/24) → direkt über wg_horus (bidirektional, kein NAT nötig)
|
||||
VM docbr0 (10.2.2.0/24) → über VM-101-Tunnel (10.1.1.5), nicht OPNsense-WG
|
||||
```
|
||||
|
||||
## 1. Aliase (*Firewall → Aliases*)
|
||||
OPNsense hängt in der **Fritzbox-DMZ** — kein extra WAN-Port-Forwarding für WireGuard nötig (Handshake beweist UDP-Rückweg).
|
||||
|
||||
- **`HORUS_WG`** (Network): `10.1.1.0/24` *(optional zusätzlich `10.1.2.0/24, 10.1.3.0/24, 10.1.4.0/24, 10.8.0.0/24`)*
|
||||
- **`LAN_VLANS`** (Network): `192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24, 192.168.40.0/24, 192.168.50.0/24, 192.168.60.0/24`
|
||||
---
|
||||
|
||||
## 2. Falsche Static Route löschen (*System → Routes → Configuration*)
|
||||
## 0. WireGuard-Basis
|
||||
|
||||
- **Löschen:** jede Route `10.1.1.0/24` (bzw. `10.1.2–4.0/24`, `10.8.0.0/24`) **→ Gateway `192.168.178.1`** — die kapert den Traffic am Tunnel vorbei.
|
||||
- **Behalten:** `10.2.2.0/24 → 192.168.10.10` (VM) und `10.100.2.0/24` (Services).
|
||||
Werte aus [opnsense-client.conf](opnsense-client.conf).
|
||||
|
||||
## 3. Outbound NAT (*Firewall → NAT → Outbound*, Modus **Hybrid**)
|
||||
| Wo | Feld | Wert |
|
||||
|----|------|------|
|
||||
| **Local** | Tunnel Address | `10.1.1.22/32` |
|
||||
| **Local** | Listen Port | z. B. **`51821`** (fester Port; nach NAT-Glitches neu wählen) |
|
||||
| **Local** | Private Key | `AGEam06B9…` (**nicht** VM-Key `SKMnLpkj…`) |
|
||||
| **Peer horus** | Public Key | `qXxhgerS2ORypVadhKCBuxgIX5Pu4J75nSWazdtd+Qk=` |
|
||||
| **Peer horus** | PSK | aus `opnsense-client.conf` |
|
||||
| **Peer horus** | Endpoint | `horus.jeanavril.com:61951` |
|
||||
| **Peer horus** | Allowed IPs | `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` |
|
||||
| **Peer horus** | Persistent Keepalive | `25` |
|
||||
| **Peer horus** | **Disable routes** | **✓ an** (mehrere WG-Instanzen: Surfshark, WGServer, wg_horus) |
|
||||
|
||||
Neue Regel (oben):
|
||||
**Interfaces → Assignments:** Instanz als **`wg_horus` (opt10)** zuweisen — sonst keine Firewall/NAT auf dem Tunnel.
|
||||
|
||||
---
|
||||
|
||||
## 1. Static Route (Pflicht bei Disable routes)
|
||||
|
||||
**System → Routing → Configuration → Routes → +**
|
||||
|
||||
| Feld | Wert |
|
||||
|------|------|
|
||||
| Interface | `horusopnsense` (WG) |
|
||||
| TCP/IP Version | IPv4 |
|
||||
| Protocol | any |
|
||||
| Source | `LAN_VLANS` |
|
||||
| Destination | `HORUS_WG` |
|
||||
| Translation / target | **Interface address** (= `10.1.1.22`); falls Interface nicht zuweisbar: *Single host* `10.1.1.22` |
|
||||
| Network | `10.1.1.0/24` *(weitere Horus-Netze bei Bedarf)* |
|
||||
| Gateway | **`10.1.1.1`** ← Horus-Tunnel-IP (**nicht** `.21`, **nicht** `192.168.178.1`) |
|
||||
| Interface | **`wg_horus`** |
|
||||
|
||||
Nicht NATen: Ziele `10.2.2.0/24`, `10.100.2.0/24` (bleiben geroutet).
|
||||
**Diagnostics → Routes:** Suche `10.1.1.1` → muss über **wg_horus** gehen.
|
||||
|
||||
## 4. Firewall-Pass (*Firewall → Rules → LAN bzw. je VLAN*)
|
||||
Alte Routen **löschen:** `10.1.1.0/24 → 192.168.178.1` (Fritzbox-Umweg).
|
||||
|
||||
| Action | Source | Destination |
|
||||
|--------|--------|-------------|
|
||||
| Pass | LAN-/VLAN-net | `HORUS_WG` |
|
||||
|
||||
Optional (defense in depth, eingehend auf `horusopnsense`): Source `HORUS_WG` → Dest `LAN_VLANS` = **Block**.
|
||||
|
||||
## 5. Test
|
||||
|
||||
- LAN-PC: `tracert 10.1.1.1` → Hop 1 OPNsense, dann Horus (**kein** `192.168.178.x`); dann `ping 10.1.1.1`.
|
||||
- Auf Horus: `tcpdump -ni wg0 icmp` muss als Quelle **`10.1.1.22`** zeigen (NAT greift), nicht `192.168.x`.
|
||||
**Behalten:** `10.2.2.0/24 → 192.168.10.10` (VM), `10.100.2.0/24` (Services).
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ Falls es trotz korrekter Config nicht geht
|
||||
## 2. Firewall — Interface `wg_horus` (opt10)
|
||||
|
||||
Denk an OPNsenses fragilen CARP/State-Zustand (war Ursache des VM-101-Tunnel-Problems, siehe [../../issues/2026-06-28-vm101-horus-wireguard-nat.md](../../issues/2026-06-28-vm101-horus-wireguard-nat.md)). Auf beiden OPNsense-Knoten Sync prüfen, ggf. State-Tabelle zurücksetzen.
|
||||
**Ohne diese Regeln: Handshake ok, Ping/Daten innen tot.**
|
||||
|
||||
| # | Action | Source | Destination | Proto | Zweck |
|
||||
|---|--------|--------|-------------|-------|--------|
|
||||
| 1 | Pass | `10.1.1.0/24` | **This Firewall** | ICMP (oder any) | Horus → OPNsense (`ping 10.1.1.22`) |
|
||||
| 2 | Pass | **This Firewall** / `10.1.1.22/32` | `10.1.1.0/24` | any | OPNsense → Horus (Diagnostics-Ping mit Source wg_horus) |
|
||||
|
||||
→ **Save → Apply Changes**
|
||||
|
||||
**Test OPNsense:** Diagnostics → Ping, Source = **`wg_horus`**, Destination = **`10.1.1.1`** (~17 ms).
|
||||
|
||||
**Test Horus:** `ping 10.1.1.22` (~16 ms).
|
||||
|
||||
---
|
||||
|
||||
## 3. Firewall — LAN / VLANs (LAN → Horus)
|
||||
|
||||
**Firewall → Rules → LAN** (und **PRIVAT**, **GAESTE**, … je nach Netz)
|
||||
|
||||
| Action | Source | Destination |
|
||||
|--------|--------|-------------|
|
||||
| Pass | LAN-/VLAN-net | `10.1.1.0/24` (Alias `HORUS_WG`) |
|
||||
|
||||
Optional Aliase (*Firewall → Aliases*):
|
||||
|
||||
- **`HORUS_WG`:** `10.1.1.0/24` (+ optional `10.1.2–4.0/24`, `10.8.0.0/24`)
|
||||
- **`LAN_VLANS`:** `192.168.10.0/24`, `.20`, `.30`, `.40`, `.50`, `.60`
|
||||
|
||||
---
|
||||
|
||||
## 4. Outbound NAT (LAN → Horus, Step A)
|
||||
|
||||
Horus-Peer erlaubt nur **`10.1.1.22/32`** als Quelle von „Heimnetz“-Traffic — VLANs müssen maskiert werden.
|
||||
|
||||
**Firewall → NAT → Outbound** — Modus **Hybrid**, Regel **oben**:
|
||||
|
||||
| Feld | Wert |
|
||||
|------|------|
|
||||
| Interface | **`wg_horus`** |
|
||||
| Source | `LAN_VLANS` (oder einzelne VLANs) |
|
||||
| Destination | `HORUS_WG` |
|
||||
| Translation | **Interface address** (`10.1.1.22`) |
|
||||
|
||||
**Nicht NATen:** `10.2.2.0/24` (VM), `10.100.2.0/24` (Services — direkt geroutet).
|
||||
|
||||
---
|
||||
|
||||
## 5. Tests (Reihenfolge)
|
||||
|
||||
| Schritt | Befehl / Ort | Erwartung |
|
||||
|---------|--------------|-----------|
|
||||
| 1 | OPNsense Ping, Source **wg_horus** → `10.1.1.1` | 0 % Loss |
|
||||
| 2 | Horus `ping 10.1.1.22` | 0 % Loss |
|
||||
| 3 | LAN-PC / pve1 `ping 10.1.1.1` | 0 % Loss |
|
||||
| 4 | Horus `tcpdump -ni wg0 icmp` während LAN-Ping | Quelle **`10.1.1.22`**, nicht `192.168.x` |
|
||||
| 5 | `tracert 10.1.1.1` vom LAN | kein Hop `192.168.178.x` |
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
| Symptom | Prüfen |
|
||||
|---------|--------|
|
||||
| Handshake ok, kein Ping innen | Static Route Gateway **`10.1.1.1`**, Firewall **wg_horus** |
|
||||
| OPNsense-Ping nur mit Source wg_horus | Route + Outbound-Regel wg_horus |
|
||||
| Horus → 10.1.1.22 fail | Inbound-Regel wg_horus (10.1.1.0/24 → This Firewall) |
|
||||
| Tunnel ok, LAN fail | LAN-Pass + Outbound NAT; Gateway nochmal prüfen |
|
||||
| Live View leer beim LAN-Ping | Route — Traffic verlässt LAN nicht Richtung wg_horus |
|
||||
|
||||
**Firewall → Log Files → Live View** während Ping — schnellster Beweis, welches Interface blockt.
|
||||
|
||||
---
|
||||
|
||||
## Horus (Referenz, bereits erledigt)
|
||||
|
||||
- Peer `walbWTYX…`: AllowedIPs **`10.1.1.22/32`, `10.100.2.0/24`** only
|
||||
- Route-Script: [wg0-opnsense-routes.sh](wg0-opnsense-routes.sh) + `wg0-opnsense-routes.service`
|
||||
- VM-Peer getrennt: [horus-server-peer-vm101.conf](horus-server-peer-vm101.conf)
|
||||
|
||||
Reference in New Issue
Block a user