WireGuard keine Verbindung trotz Handshake

[mczocker32]

Hallo nochmal,

nachdem ich erfolgreich die OPNsense hinter dem DG Anschluss zum laufen bekommen habe wollte ich nun auch den WireGuard VPN wieder aufbauen. Ich habe hier orientiert an den alten FRITZ!Box Einstellungen dem WAN Interface wieder eine eigene IPv6 zuweisen lassen. Diese IP habe ich als Eintrag in meiner Subdomain hinterlegt. Den WireGuard habe ich anhand des Guides und Videos konfiguriert und lediglich so angepasst, dass es mit den alten Configs der FRITZ!Box übereinstimmt.

LAN ist bei mir aktuell 192.168.0.0/22, sprich 192.168.1.1/22 hat die OPNsense und 192.168.3.1/22 habe ich dem WireGuard Interface gegeben. Die Clients dann ab 192.168.3.2/32 auf der OPNsense bzw. 192.168.3.2/22 auf dem Client selber, sowie Allowed IPs 192.168.0.0/22, 0.0.0.0/0.
Der WireGuard Port ist auf dem WAN freigegeben. Auf dem WireGuard Interface ist eine IPv4 Pass * Regel und ich bekomme auch immer einen Handshake.

Ich habe allerdings nie Internet und keine Verbindung zu internen IPs, außer am iPhone da komm ich mit 192.168.1.1 auf die OPNsense drauf. In der Firewall Liveview sehe ich wie Pakete von 192.168.3.2 zum PiHole gehen oder die Anfragen mit :443 aufs NAS. Diese sind auch alle Grün. Es lädt trotzdem nie etwas und ich finde nichts dazu. Konfigurieren mit 10.0.0.0/24 habe ich auch schon durch. OpenVPN ebenfalls probiert.


Jemand eine Idee?

[Reiner030]

Vor der Umstellung hat das Wireguard Routing funktioniert?

UDP Kommunikation kann stattfinden, auch wenn die jeweiligen Schlüssel nicht übereinstimmen - hier gibt WireGuard leider keine Fehlermeldung aus.
Dazu muss man auch die erlaubten Routings / Netzwerke der Gegenseite auf beiden Seiten entsprechend freigeben.

wie z.B. beim Client:

Code Select Expand


PrivateKey = xxx
Address = 192.168.1.4/30
DNS = 192.168.1.1

[Peer]
PublicKey = xxx
AllowedIPs = 10.0.0.0/8, 192.168.0.0/16
Endpoint = host:port
PersistentKeepAlive= 25


Und dem Server z.B. ein dem Client entsprechende zugewiesenes Routing:

Code Select Expand

AllowedIPs = 192.168.1.4/30

[mczocker32]

Das stimmt bei mir so überein. Über die FRITZ!Box ging es also liegt es immerhin nicht am IPv6.
Es gibt nicht nur Verbindung sondern wirklich einen Handshake und auch Austausch, siehe Anhang

[Ronny1978]

Evtl. ein IPv4 / IPv6 Problem??? ???

Was hast du den bei DNS im Wireguard Client eingegeben bzw. wer macht DNS bei dir? Die OpnSense oder der PiHole?

[mczocker32]

DNS fähig sind beide. Über DHCP gibt die OPNsense den PiHole weiter und den habe ich auch bei WireGuard genutzt. Dort sehe ich wie gesagt erfolgreiche und nicht geblockte Verbindungen. Mit der OPNsense als DNS hat es auch nicht funktioniert.

[tiermutter]

Wird vielleicht mal Zeit für Screenshots der WG Konfig  ???

[Ronny1978]

Wird vielleicht mal Zeit für Screenshots der WG Konfig  ???

Ich stimme hier zu. Bitte von BEIDEN: WG Server und den Clients, sowohl in der OpnSense (Endpoint) wie auch am Client selbst. Sonst ist hier nur "Glaskugelschauen".

Danke

[tiermutter]

Und auch wenn der Handshake scheinbar klappt:
Bitte so dass man sieht welcher Key wo eingetragen ist.

[mczocker32]

Ok, dann hier mal die Configs. Hoffe das reicht (hab es mal etwas zensiert).
WG Interface wegen dem 4 Attachments limit mal weggelassen.

[tiermutter]

Ähm...
Die IPs vom Tunnel liegen im Subnetz vom LAN... Du musst für WG ein eigenens Subnetz verwenden!
Also zB 192.168.4.1/22 wenn du unbedingt bei dieser Netzmaske bleiben willst.

[mczocker32]

Wie bereits erwähnt hatte ich es anfänglich mit 10.0.0.0/24 konfiguriert was aber auch nicht ging. Soweit ich das beurteilen kann sollte das auch egal sein. Der WireGuard der FRITZ!Box hat es ebenfalls im selben Subnet angelegt und die Adressen ab .200 vergeben.

[tiermutter]

Fritte ist aber auch speziell.
Ich würde auf jeden Fall erstmal ein anderes Subnet nehmen um weiter zu testen.

[tiermutter]

Die allowed IPs in der Client Konfig sind auch etwas "unsauber":
0.0.0.0/0 enthält alle IPs, demnach ist es überflüssig weitere Bereiche anzugeben, aber das sollte kein Problem sein. Versuche es aber auch mal ohne 0.0.0.0/0. Windows mag das zB nicht, stattdessen nehme ich hier 0.0.0.0/1, 128.0.0.0/1

[mczocker32]

Das mit dem 0.0.0.0/0 habe ich ebenfalls übernommen. Dort scheint es aber so zu sein, dass im Windows Client erst mit der 0.0.0.0/0 die Checkbox für den Kill-Switch erscheint, die dann zwischen der 0.0.0.0/0 und der 0.0.0.0/1, 128.0.0.0/1 wechselt. Das scheint vermutlich der Grund zu sein, weshalb das bei AVM so konfiguriert wird. Aber auch das hatte ich mit mehreren Variationen getestet. Entweder nur interne IP oder 0.0.0.0/0. Ich kann eben auch auf andere VPN Clients drauf. Wenn die 192.168.3.2 einen WebDAV startet kann die 192.168.2.3 den sehen. Aber niemand kommt auf die wirklich internen Geräte, obwohl die Firewall Verbindungen zum DNS sogar anzeigt.

[mczocker32]

Also WireGuard Client zu WireGuard Client funktioniert. WireGuard Client zu LAN nicht, umkgekehrt ebenfalls nicht.