jean/docu

Files

T

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

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>

2026-06-28 18:17:49 +02:00

6.3 KiB

Raw Blame History

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

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)

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:

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

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

Peer in /etc/wireguard/wg0.conf + Verzeichnis /etc/wireguard/clients/<name>/

Client-Config mit:

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)

Server-seitig keine weiteren Schritte — UFW-Route-Regeln gelten für alle wg0-Peers
Config auf dem Gerät neu importieren (QR/Datei), Tunnel neu verbinden

Client-Config neu laden (pixel7)

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

# Am Client (Browser oder Termux)
curl -4 ifconfig.me
# Erwartung: 207.180.222.207

ping -c3 8.8.8.8

# 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:

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
OPNsense Site-to-Site	../shared/horus-opnsense-wireguard/README.md
VM-101 NAT-Vorfall	../issues/2026-06-28-vm101-horus-wireguard-nat.md

6.3 KiB Raw Blame History Unescape Escape