# Schritt A — LAN/VLAN → Horus per NAT (OPNsense)

**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).

| 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.

---

## 0. Voraussetzung

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.

## 1. Aliase (*Firewall → Aliases*)

- **`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*)

- **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).

## 3. Outbound NAT (*Firewall → NAT → Outbound*, Modus **Hybrid**)

Neue Regel (oben):

| 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` |

Nicht NATen: Ziele `10.2.2.0/24`, `10.100.2.0/24` (bleiben geroutet).

## 4. Firewall-Pass (*Firewall → Rules → LAN bzw. je VLAN*)

| 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`.

---

## ⚠️ Falls es trotz korrekter Config nicht geht

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.