12
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:
Auf dem Test-PC habe ich folgende Konfiguration angelegt:
Ausserdem habe ich pf zum Test folgende Konfiguration am Ende gegeben:
Anschließend habe ich reboot ausgeführt.
Mittels 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
ausführen muss, um den Server zu starten.
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/24Auf 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:51820Ausserdem 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 51820Der 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 
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1699161309
Url: https://administrator.de/contentid/1699161309
Printed on: April 19, 2024 at 02:04 o'clock
12 Comments
Latest comment
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?
MfG
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?!
1
Was mache ich falsch?
Das hiesige Tutorial dazu hast du gelesen ??Merkzettel: VPN Installation mit Wireguard
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 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.
.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/32Client
[Interface]
PrivateKey = wCd...=
Address = 10.255.0.208/32
[Peer]
PublicKey = zew...=
AllowedIPs = 0.0.0.0/0
Endpoint = <externe ip des wireguard servers>:51820Dann 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.2Dann hast du Wireguard bzw. das Cryptokey-Routing allgemein noch nicht verstanden face-smile.
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
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.
Das Problem war, dass ich vergessen hatte
wg-quick up wg0 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.
Dann bitte Beitrag auch schließen. Danke.
1
