# 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//` 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) |