docu/issues/2026-06-28-opnsense-horus-wireguard-lan.md

OPNsense ↔ Horus WireGuard — Tunnel + LAN (2026-06-28)

Datum: 2026-06-28
Status: gelöst
Betroffen: WireGuard OPNsense (wg_horus / opt10, 10.1.1.22) ↔ Horus (10.1.1.1), LAN/VLAN → Horus

---

Symptom

Test	Ergebnis
WireGuard-Handshake OPNsense ↔ Horus	✅ (trotzdem wirkte Tunnel „tot“)
OPNsense → Horus (ping 10.1.1.1, Source wg_horus)	❌ → später ✅
Horus → OPNsense (ping 10.1.1.22)	❌ → später ✅
LAN/PC → 10.1.1.1	❌ → ✅ nach Gateway-Fix + NAT

Typisch: Bytes gesendet, Handshake da, aber Ping/Daten innen tot — sieht aus wie „Tunnel kaputt“, ist aber oft Routing + Firewall auf dem zugewiesenen WG-Interface.

---

Fehldiagnosen (Zeitfresser)

These	Wahrheit
Keys/PSK auf Horus falsch (VM-Tunnel)	Nein — siehe 2026-06-28-vm101-horus-wireguard-nat.md
Horus-Route-Skript wg0-opnsense-routes.sh blockiert Ping	Nein — betrifft nur Horus-Routing zu OPNsense/LAN, nicht OPNsense→Horus
Fritzbox / fehlende WAN-Zuweisung	Nein — OPNsense steht in Fritzbox-DMZ; Handshake beweist UDP hin+her
Nur LAN-Firewall fehlt	Teilweise — ohne funktionierenden Tunnel innen nützt LAN nichts

---

Echte Ursachen (drei Stellen)

1. Keine Route zu Horus auf OPNsense (Disable routes = an)

Mit Disable routes am Peer legt OPNsense keine Routen aus Allowed IPs an → manuelle Static Route nötig.

Falsch:

• Gateway 10.1.1.21 (existiert nicht — Tunnel-IP ist 10.1.1.22, Horus 10.1.1.1)
• Route 10.1.1.0/24 → 192.168.178.1 (Fritzbox statt Tunnel)

Richtig:

Network:  10.1.1.0/24
Gateway:  10.1.1.1          ← Horus-Tunnel-IP (Peer-Gegenstelle)
Interface: wg_horus (opt10)

Allowed IPs am Peer trotzdem setzen (10.1.1.0/24, …) — WireGuard-Crypto, unabhängig von Disable routes.

2. Firewall auf wg_horus (opt10) — nicht nur LAN/WAN

Handshake läuft im Kernel; innerer Traffic (ICMP/IP) braucht Regeln auf dem zugewiesenen Interface:

Regel	Source	Destination	Zweck
Pass	10.1.1.0/24	This Firewall	Horus → OPNsense (ping 10.1.1.22)
Pass	This Firewall / 10.1.1.22	10.1.1.0/24	OPNsense → Horus (Diagnostics-Ping mit Source wg_horus)

Ohne Inbound-Regel: Horus pingt, OPNsense antwortet nicht → 100 % Loss trotz Handshake.

3. LAN → Horus (Step A)

• Firewall auf LAN/VLAN: Pass → 10.1.1.0/24
• Outbound NAT auf wg_horus: VLAN-Quellen → 10.1.1.0/24 → SNAT 10.1.1.22

Horus-Peer kennt nur 10.1.1.22/32 + 10.100.2.0/24 — ohne NAT sieht Horus 192.168.x und antwortet nicht sinnvoll.

Gateway-Fix (10.1.1.1 statt .21) war der letzte Blocker für LAN.

---

Lösung (Kurz)

1. Interfaces → Assignments: wg_horus (opt10) zugewiesen
2. Peer horus: Allowed IPs 10.1.1.0/24, …, Disable routes = an (wegen mehrerer WG-Tunnel)
3. Static Route: 10.1.1.0/24 → 10.1.1.1 via wg_horus
4. Firewall wg_horus: Pass ICMP (bzw. any) von 10.1.1.0/24 → This Firewall und Richtung raus
5. Firewall LAN/VLAN: Pass → 10.1.1.0/24
6. Outbound NAT (Hybrid): Interface wg_horus, SNAT 10.1.1.22
7. Listen Port Instanz z. B. 51821 (nach NAT-State-Problemen sinnvoll; VM 101 nutzt weiter eigenen Port)

---

Verifikation

# Auf Horus (via VM 101):
ping -c3 10.1.1.22          # ~16 ms
ping -c3 10.1.1.5           # VM-Peer Vergleich

# OPNsense GUI:
# Diagnostics → Ping, Source = wg_horus, Dest = 10.1.1.1  → ~17 ms

# LAN (pve1 / PC):
ping -c3 10.1.1.1

# Horus während LAN-Ping:
tcpdump -ni wg0 icmp and host 10.1.1.1
# Quelle muss 10.1.1.22 sein (NAT), nicht 192.168.x

---

Breakpoint-Matrix (für nächstes Mal)

Symptom	Breakpoint
Handshake ok, OPNsense ping 10.1.1.1 fail (ohne Source)	Route fehlt / falsches Gateway
OPNsense ping ok nur mit Source wg_horus	Static Route + Outbound-FW wg_horus
Horus ping 10.1.1.22 fail	Inbound-FW wg_horus (10.1.1.0/24 → This Firewall)
Tunnel ok, LAN fail	LAN-FW + Outbound NAT + Gateway 10.1.1.1
tcpdump Horus: kein LAN-Traffic	OPNsense vor WG (Route/FW LAN)
tcpdump Horus: 192.168.x statt 10.1.1.22	Outbound NAT fehlt

---

Referenzen

• Setup: ../shared/horus-opnsense-wireguard/README.md
• Step A NAT: ../shared/horus-opnsense-wireguard/opnsense-step-a-nat.md
• VM-101-NAT-Vorfall: 2026-06-28-vm101-horus-wireguard-nat.md

⛔ VM 104 (OPNsense) nie per Agent qm stop/start — siehe ../pve1/04_fallback_aktivierung.md.