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>
This commit is contained in:
root
+4
-2
@@ -20,8 +20,10 @@
|
||||
|
||||
- **Verwaltung: `wg-quick@wg0`** (systemd, enabled). **Es läuft KEIN wireguard-ui** (kein Prozess/Container/Port 5000) — die `wg0.conf` wurde nur *historisch* damit erzeugt.
|
||||
- Server-Config: `/etc/wireguard/wg0.conf` (Header sagt „don't edit manually", aber maßgeblich ist, was `wg-quick` lädt → `wg show wg0` / `wg showconf wg0` ist die Wahrheit).
|
||||
- Client-Keys/Configs: `/etc/wireguard/clients/<name>/` (je `client.conf`, `privatekey`, `publickey`, `presharedkey`), Backup unter `/etc/wireguard/bak/`.
|
||||
- Listen-Port: `61951/udp`. PostUp/PostDown setzen iptables FORWARD/NAT.
|
||||
- Client-Keys/Configs: `/etc/wireguard/clients/<name>/` (je `client.conf`, `privatekey`, `publickey`, `presharedkey`), Backup unter `/etc/wireguard/bak/`. Repo-Kopien: [clients/](clients/).
|
||||
- Listen-Port: `61951/udp`. PostUp/PostDown in `wg0.conf` sind **auskommentiert**; Forward/NAT über **UFW route** + Docker-MASQUERADE.
|
||||
- **Internet-Gateway** für Road-Warrior-Clients (pixel7): [wireguard-internet-gateway.md](wireguard-internet-gateway.md) — UFW `wg0→eth0`, Client `AllowedIPs` inkl. `0.0.0.0/0`.
|
||||
- **Site-to-Site** OPNsense/VM 101: kein Full-Tunnel — [../shared/horus-opnsense-wireguard/README.md](../shared/horus-opnsense-wireguard/README.md).
|
||||
- **Peers sauber löschen** (ohne UI): `[Peer]`-Block aus `wg0.conf` entfernen **+** `clients/<name>/` löschen **+** `wg syncconf wg0 <(wg-quick strip wg0)` (oder `systemctl restart wg-quick@wg0`).
|
||||
- Vorfall NAT/Port siehe [../issues/2026-06-28-vm101-horus-wireguard-nat.md](../issues/2026-06-28-vm101-horus-wireguard-nat.md).
|
||||
|
||||
|
||||
@@ -0,0 +1,15 @@
|
||||
# Horus WireGuard — Client pixel7 (Road Warrior, Internet-Gateway)
|
||||
# Quelle: /etc/wireguard/clients/pixel7/client.conf auf Horus
|
||||
# Stand: 2026-06-28 — AllowedIPs inkl. 0.0.0.0/0 für Internet via Horus
|
||||
|
||||
[Interface]
|
||||
PrivateKey = EPwmQ19R5xUjV7Ve9IpJ/39mFDflHUmpVNkXTgjuSkM=
|
||||
Address = 10.1.1.15/32
|
||||
DNS = 1.1.1.1, 1.0.0.1
|
||||
|
||||
[Peer]
|
||||
PublicKey = qXxhgerS2ORypVadhKCBuxgIX5Pu4J75nSWazdtd+Qk=
|
||||
PresharedKey = /zmUIQ9QW3W9Q3PuZNuMZ1t6xOzdSTRt7qBFCHxQcik=
|
||||
AllowedIPs = 10.1.1.0/24, 192.168.2.0/24, 10.1.2.0/24, 10.8.0.0/24, 0.0.0.0/0
|
||||
Endpoint = 207.180.222.207:61951
|
||||
PersistentKeepalive = 15
|
||||
@@ -0,0 +1,189 @@
|
||||
# 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/<name>/`
|
||||
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) |
|
||||
Reference in New Issue
Block a user