OPNsense Forum
International Forums => German - Deutsch => Topic started by: mczocker32 on May 30, 2023, 04:50:54 pm
-
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?
-
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:
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:
AllowedIPs = 192.168.1.4/30
-
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
-
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?
-
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.
-
Wird vielleicht mal Zeit für Screenshots der WG Konfig ???
-
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
-
Und auch wenn der Handshake scheinbar klappt:
Bitte so dass man sieht welcher Key wo eingetragen ist.
-
Ok, dann hier mal die Configs. Hoffe das reicht (hab es mal etwas zensiert).
WG Interface wegen dem 4 Attachments limit mal weggelassen.
-
Ä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.
-
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.
-
Fritte ist aber auch speziell.
Ich würde auf jeden Fall erstmal ein anderes Subnet nehmen um weiter zu testen.
-
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
-
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.
-
Also WireGuard Client zu WireGuard Client funktioniert. WireGuard Client zu LAN nicht, umkgekehrt ebenfalls nicht.
-
Wie sehen denn deine Firewall Regeln für die WG Schnittstelle aus? Oder habe ich das überlesen? Du hast ja sicherlich dem Wiregard eine Schnittstelle zugewiesen. Dann gibt es ja auch Regeln dafür, oder? Zugriff DNS, Zugriff Internet usw.
Ich denke, dass dort einfach der Zugriff von der Wiregard Schnittstelle zum LAN nicht erlaubt ist. Ansich sehen die Config's meiner Meinung nach schlüssig aus, wobei ich nicht verstehe, warum x.x.x.x/24 nicht geht und du /22 nimmst? ::)
-
Die /24 und /22 haben bei mir das selbe Ergebnis. Ich nutze für den WireGuard den LAN Bereich was an sich kein Problem ist wie es scheint. Der ist eben 192.168.0.0/22 und 192.168.3.1 aufwärts dann WireGuard. Auf dem WG1 Interface oder der Gruppe (beides getestet) ist any any freigegeben für IPv4 und IPv6 alle Ports. Ich habe gestern nochmal alles 1:1 wie in der Anleitung konfiguriert also 10.10.10.1/24 usw. und es hat sich nichts getan. Bei einem Portscan sieht man in der Live View wie alles erreicht wird aber der Client bekommt nie eine Rückmeldung. Als ich auf dem LAN eine Regel gemacht habe mit Source WG1 und eine mit Destination WG1 ist gar nichts mehr in der Firewall aufgetaucht. Das einzige was sich bei mir ggf. unterscheiden könnte, wäre meine bridge Konfiguration bei den Ethernet Ports. Ich habe 5 LAN Ports und möchte dort Geräte anschließen können und trotzdem nur ein Interface haben, was an sich ja funktioniert.
-
Ähm...
Die IPs vom Tunnel liegen im Subnetz vom LAN... Du musst für WG ein eigenens Subnetz verwenden!
Ich würde auf jeden Fall erstmal ein anderes Subnet nehmen um weiter zu testen.
Die Docs sagen ausdrücklich:
The tunnel address must be in CIDR notation and must be a unique IP and subnet for your network, such as if it was on a physically different routed interface. The subnet should be an appropriate size that includes all the client peers that will use the tunnel. For IPv4 it should be a private (RFC1918) address, for example 10.10.10.1/24. For IPv6, it could either be a unique ULA /64 address, or a unique GUA /64 address derived from your prefix delegation. Do not use a tunnel address that is a /32 (IPv4) or a /128 (IPv6)
Also willst Du nun weiter auf Deinem WG/LAN-Mix verharren oder willst Du das Problem lösen?
-
Wie bereits erwähnt habe ich es mit genau dieser 10.10.10.1/24 angelegt und es ändert trotzdem nichts an dem Problem.
-
Dann hast Du vielleicht noch ein anderes Problem... nun baust Du Dir aber noch mehr Probleme rein.
-
Ersetze alle /22 durch /24. Wenn man wenig Ahnung hat, sollte man es tunlichst vermeiden, seine eigene Extra-Wurst zu braten.
-
Wie wahr... ich sollte gestern Rippchen kurz und heiß grillen, statt wie üblich lange bei niedriger Temperatur... Ergebnis der "Extra-Wurst" war ein brennender Grill, eine brennende Außenküche und alles eingesaut mit Löschpulver. Aber das ist OT :-X
-
@mczocker32
Ich muss hier leider den anderen zustimmen. Nicht soviel abweichen, bei Einstellungen die bei allen anderen funktionieren. Ich würde hier wie folgt vorgehen und ggf. noch einmal zurückbauen:
1. Schnittstelle zuweisen -> WG1 oder sowas
2. Wireguard Server einrichten mit einer ANDEREN IP Range wie dein LAN > LAN 192.168.0.0/24 / Wireguard 10.10.10.0/24, zum Beispiel
3. Clients einrichten -> erstmal nur EIN Handy als Beispiel
4. Firewall -> Regeln "schreiben" -> Zugriff auf DNS erlauben/ Zugriff auf LAN erlauben, Internet erlauben
5. Mit dem Handy extern einwählen -> UND TESTEN
6. Regeln verfeinern/härten
7. Dann die restlichen Clients einrichten
Ich habe zum Public-/Privatekey auch noch einen Preshared Key im Einsatz. Ich musste hier aber auch erst ein wenig probieren. Aber es läuft. Ich komme vom Wireguard-Netz ins LAN.
Viel Erfolg.
-
Also gestern habe ich einen neuen Endpoint erstellt mit der 10.10.10.1/24 dann einen Peer mit der 10.10.10.2/24 dem Endpoint den Peer zugewiesen. Allowed IP in der Peerconfig war 10.10.10.2/32. Allowed IPs in der Clientconfig 10.10.10.0/24 und 192.168.0.0/22 da der DNS 192.168.1.5 ist. Aber auch mit 192.168.1.1 oder 10.10.10.1 gab es keinen erfolg. WAN ist 51820 für UDP IPv6 offen. Das WG Interface ist assignt, aktiviert und hat die Regel Pass IPv4+6 *
Es wird laut log alles erreicht, alles gepingt aber keine Rückmeldung auf dem Clientgerät
-
Brauchst du als LAN wirklich ein /22 subnet?
Wenn nicht hier auch auf /24 umstellen, das 22er macht zuletzt nicht nur bei dir Probleme...
https://forum.opnsense.org/index.php?topic=34284.0
-
Das macht bei mir keinen unterschied, habs eben mal getestet. WireGuard selber funktioniert ja auch, dort steht ja es kam gar nicht mehr hoch und es wird ja auch geroutet aber eben nie mit antwort
-
tcpdump auf allen Interfaces, gucken, wo es hängen bleibt. Dann suchen, weshalb.
-
Nachdem ich alles durchprobiert habe mit der Erkenntnis dass ich immer auf die OPNsense (WG Interface) und andere WireGuard Clients komme, habe ich den DNS auf die 192.168.3.1 geändert. WG1 = 192.168.3.1/22. Nach dieser Änderung habe ich noch die Allowed IPs im Client auf 0.0.0.0/0 gestellt. Ich konnte nun ins Internet und dies auch im Live View nachvollziehen. Unter test-ipv6 wurde unter IPv6 nun auch DG angezeigt. Da ich zu der Zeit in einem Telekom Netz war, wurde mir dies noch unter IPv6 angezeigt, also habe ich der Allowed IP liste ::/0 hinzugefügt, um auch IPv6 in den Tunnel zu routen. Nun habe ich keine IPv6 aber komme auch nicht ungewollt aus dem Tunnel. Nun kam mir die Frage auf wieso WAN geht aber nicht LAN. Ich habe es mit verschiedensten Freigaben probiert und nichts funktionierte. Da ist mir der einzige Unterschied eingefallen. Die Outbound NAT Freigabe für WAN. Ich habe also eine Outbound freigabe für das Interface LAN gemacht und plötzlich ging es. So konnte ich nun auch den PiHole als DNS nutzen und alles erreichen. Vielleicht habe ich nicht genau geschaut, doch dies gab es in keiner Anleitung, dort ging es immer nur um die WAN Regel. Naja vielleicht hilft das hier jemanden. Die anderen Beiträge verliefen immer im Sande.
-
Ist für die Geräte im LAN die OPNsense mit dem Wireguard Tunnel der Defaultgateway oder nicht?
-
Ja die OPNsense ist der Router und default Gateway
-
Dann braucht es kein NAT in das LAN hinein. Was genau ist eine "outbound Freigabe für NAT"?
-
Wie auch hier beschrieben: https://docs.opnsense.org/manual/how-tos/wireguard-client.html
Nur das gleiche nochmal für das LAN Interface
-
Das brauchts nicht, wenn die Systeme im LAN die OPNsense als Defaultgateway haben. Dann wird das irgendwo anders geblockt. Aber wenn es so funktioniert und du zufrieden bist, dann ist ja gut.
-
Und wo kann es geblockt sein wenn LAN Regeln und WG Regeln mit Quelle LAN ziel WG alles erlauben und andersherum nicht funktionieren + In der Firewall alles als nicht geblockt steht
-
Müsste ich mir vor Ort auf deinem System angucken, wenn es wirklich quirky wird, ist so ein Forum irgendwann am Ende. Ich finde sowas in der Regel. Ist mein Job ;)
-
Du könntest natürlich schauen wenn du magst, oder zeig erstmal was genau du alles bei dir gemacht hast damit der VPN erstmal überhaupt funktioniert. Wie gesagt blockiert war vorher auch nie etwas aber es hat immer nur richtig verbunden wenn sich zwei WireGuard VPN Clients erreichen wollten. LAN ging bis zu dieser Outbound Regel scheinbar immer ein und wurde auch weitergeschickt aber kam wohl nicht wieder zurück
-
Ich hab Wireguard auf der OPNsense nur site to site und das funktioniert. Für Road Warrior benutzen wir OpenVPN, wegen Adresspool, Active Directory, etc. pp.
Ich hab privat zwei Wireguard Installationen in virtuellen Maschinen in den USA und im UK aus offensichtlichen Gründen.
Und 1:1 Support mach ich normalerweise gegen Bezahlung. Sorry, dein Problem ist gelöst, irgendwann ist ein Forum auch mal am Ende.
-
Outbound NAT?
Interface: LAN
Source Address: WG NET
Destination Address: LAN NET
Translation / address: Interface address
Edit: Sorry, hatte nur die erste Seite vom Thread gelesen.