07.01.2022, aktualisiert am 08.01.2022

1334

Wireguard auf OpenBSD

Hallo zusammen,
ich versuche seit ein paar Tagen einen Wireugard-Server auf OpenBSD zum Laufen zu kriegen. Hauptmotivation ist zur Anbindung von Android-Smartphones. Aber irgendwie schaffe ich es nicht, einen Tunnel aufzubauen. Ich habe auf der OpenBSD-Kiste das Wireugard-Paket installiert und dann folgende Konfigurationsdatei angelegt:

#Datei: /etc/wireguard/wg0.conf 
[Interface]
PrivateKey = AB....=
ListenPort = 51820
Address = 10.255.0.123/24

# Android client 1
[Peer]
PublicKey = oO8....=
AllowedIPs = 10.255.0.207/24

# client pc test
[Peer]
PublicKey = WpI....=
AllowedIPs = 10.255.0.208/24

Auf dem Test-PC habe ich folgende Konfiguration angelegt:

[Interface]
PrivateKey = wCd...=
Address = 10.255.0.208/24

[Peer]
PublicKey = zew...=
AllowedIPs = 0.0.0.0/0
Endpoint = 10.0.180.2:51820

Ausserdem habe ich pf zum Test folgende Konfiguration am Ende gegeben:

pass in on wg0
pass in inet proto udp from any to any port 51820
pass out on egress inet from (wg0:network) nat-to (em0:0) 

Anschließend habe ich reboot ausgeführt.

Mittels

tcpdump -n -e -ttt -i em0 port 51820

sehe ich die Pakete eintrudeln.

Der Wireguard Windows-Client meldet mir aber immer nur, dass der Handshake einen Timeout hat.

Was mache ich falsch?

Viele Grüße

Peter

EDIT: Für Leser: Ich hatte mich an diesem Tutorial (https://ianix.com/wireguard/openbsd-howto.html) orientiert. Dort fehlt, dass man

wg-quick up wg0

ausführen muss, um den Server zu starten.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 1699161309

Url: https://administrator.de/forum/wireguard-auf-openbsd-1699161309.html

Ausgedruckt am: 03.05.2025 um 07:05 Uhr

12 Kommentare

Neuester Kommentar

AllowedIPs = 0.0.0.0/0

So habe ich WG noch nie zum Fliegen gebracht. Spezifiziere das doch mal testweise.

Ich habe das einmal auf 10.255.0.0/24 geändert, bringt aber leider nichts. Handshake ist immer noch im Timeout.

Hallo,

was sagt das Log?

MfG

was sagt das Log?

Das die IP vom Host nicht passt

Zitat von @Visucius:

was sagt das Log?

Das die IP vom Host nicht passt

Dann dürfte ja wohl kaum der Traffic ankommen, oder?
Der TO hat doch tcpdump am laufen und sagt dass er eingehende Pakete sehen kann....

Der TO hat doch tcpdump am laufen und sagt dass er eingehende Pakete sehen kann....

Ich kann doch nur das sehen, was oben steht:

Der Host gibt sich die IP: "Address = 10.255.0.123/24"
Der Client verbindet auf "Endpoint = 10.0.180.2:51820"

Keine Ahnung was da für Pakete eingehen?!

Was mache ich falsch?

Das hiesige Tutorial dazu hast du gelesen ??
Merkzettel: VPN Installation mit Wireguard

Der erste Fehler der auffällt ist das der Client Peer (Endpoint) nicht auf die Server IP zeigt. Der Client kann also niemals einen Tunnel zum WG Server aufbauen weil die IP schlicht und einfach falsch ist.
Der zweite Fehler ist das du die Allowed IPs auf den Clients im internen WG Netz mit einer falschen Maske versehen hast. Das muss eine /32er sein.

Zitat von @aqui:
Der erste Fehler der auffällt ist das der Client Peer (Endpoint) nicht auf die Server IP zeigt. Der Client kann also niemals einen Tunnel zum WG Server aufbauen weil die IP schlicht und einfach falsch ist. Kollege @Visucius hat es oben schon richtig gesagt.

Nöpp denn am Server steht dort ja die Wireguard interne IP des Servers nicht die externe

Der Wireguard Windows-Client meldet mir aber immer nur, dass der Handshake einen Timeout hat.

In dem Fall sind dann zu 95% die Keys falsch bzw. wie @aqui schin geschrieben hat stimmen auch die Subnetzmasken der AllowedIPs der Clients sowohl auf Server- als auch auf Clientseite nicht die müssen auf /32 stehen.

Server

[Interface]
PrivateKey = AB....=
ListenPort = 51820
Address = 10.255.0.123/24

# Android client 1
[Peer]
PublicKey = oO8....=
AllowedIPs = 10.255.0.207/32

# client pc test
[Peer]
PublicKey = WpI....=
AllowedIPs = 10.255.0.208/32

Client

[Interface]
PrivateKey = wCd...=
Address = 10.255.0.208/32

[Peer]
PublicKey = zew...=
AllowedIPs = 0.0.0.0/0
Endpoint = <externe ip des wireguard servers>:51820

Zitat von @Visucius:

AllowedIPs = 0.0.0.0/0

So habe ich WG noch nie zum Fliegen gebracht.

Dann hast du Wireguard bzw. das Cryptokey-Routing allgemein noch nicht verstanden

. Läuft hier überall ohne Probleme ... Die meisten vergessen halt auf der Remote-Seite am Gateway entweder ne statische Route für die Wireguard-Clients(Netz) zu setzen oder der Traffic dieser ausgehend zu Masqueraden.

Dann hast du Wireguard bzw. das Cryptokey-Routing allgemein noch nicht verstanden

face-smile.

Bestimmt. Macht aber nix. Läuft seit 2 Jahren in diversen Setups absolut stabil. Und darauf kommts mir ja an

Nöpp denn am Server steht dort ja die Wireguard interne IP des Servers nicht die externe

Wie peinlich ! 🤦‍♂️ Sollte wohl selber mal das Tutorial lesen...

Aber heute ist ja Freitag 🐟 da darf einem das auch mal passieren.... 😉

Mea culpa!

Das Problem war, dass ich vergessen hatte

wg-quick up wg0

auszuführen!

Danke auf jeden Fall für den Hinweis zu den Subnetzen. Ich habe es jetzt auf ein /32er Netz angepasst. Jetzt funktioniert es. Ich muss noch die "0.0.0.0/0" für AllowedIPs probieren. Aber wenn das Subnetz für die 2. DMZ, das ich dort eingetragen habe, funktioniert, dann sollte es auch für den Internet Traffic klappen. Ja, Rückroute muss natürlich sein. Masquerading / NAT will ich nicht, denn so kann ich in Serverlogs sehen, von welchem Client was kam. Entsprechend habe ich auch wieder das nat-to in der pf.conf entfernt. Das mit der internen IP für den Server hatte schon seine Richtigkeit, ich wollte erstmal das in einem lokalen Netzwerksegment testen, bevor ich ein Portforwarding ins freie Internet mache. Deshalb steht da die IP aus der DMZ.