Hallo, liebe Freunde der Currywurst! ;D
An der fortgeschrittenen Zeit sieht man schon in etwa, dass ich eine kleine Nachtschicht einlege. ::)
Mein Aufbau ist denkbar einfach:
Meine OPNsense-Kiste hängt direkt am Internet (über den sog. Mediakonverter der Deutschen Glasfaser). Die IP-Adresse bekomme ich über DHCP(4/6). Die Verbindung steht (das hier schreibe ich über diese).
Über eine FritzBox 4060, die als IP-Client läuft, stelle ich Telefonie bereit (VoIP). Außerdem funzt die Kiste als DECT-Basis. Damit das zuverlässig funktioniert, habe ich ein paar Einstellungen. Es sind ein paar NAT-Regeln (für IPv4 und IPv6) und Port-Forwards. Ich bin mit dem Ergebnis da auch recht glücklich, die Telefonie funktioniert zuverlässig. 👍🏼
Obwohl mich etwas irritiert, dass ich eine Regel scheinbar weder editieren noch klonen kann. Aber ein Mülleimer ist vorhanden. 🤔
Jetzt geht es aber darum, eine Verbindung zu OVPN (dem schwedischen Anbieter, OpenVPN ist nicht gemeint) aufzubauen. Endziel ist es, Ports an eine Kiste bei mir in Heimnetz weiterzuleiten (erstmal ssh). Bei der DG bekomme ich ja nur einen DSlite-Anschluss, ohne öfftenliche IPv4 Adresse. Ich weiß, man kann, was ich will, auch mit IPv6 erreichen, ohne VPN, aber irgendwie komme ich mit IPv6 nicht so richtig klar. :P
OVPN gibt freundlicherweise eine komplette und sehr "handliche" Anleitung:
https://www.ovpn.com/en/guides/wireguard/opnsense (https://www.ovpn.com/en/guides/wireguard/opnsense)
Die habe ich auch befolgt. Hiernach sollten alle Geräte über den VPN-Tunnel mit dem Internet verbunden werden. Das Ergebnis: Die Verbindung kommt gar nicht erst zu Stande. Im Log kommt "error" und etwas von einer fehlenden Route. Sorry, habe vergessen, die genaue Fehlermeldung zu kopieren. :-[
Die Fehlermeldung verschwindet aber, wenn ich "Dynamic gateway policy" im Interface ausschalte.
Jetzt steht die Verbindung, aber es fließen keine Daten. Ein ping 8.8.8.8 gibt nur Timeouts.
Nachdem ich die Einstellungen da zig mal überprüft und auch an einigen Schrauben gedreht habe (das Ergebnis bleibt: Starte ich wg, klappt kein ping mehr, stoppe ich wg, klappt es wieder), habe ich eine andere Anleitung gefunden:
https://0x2142.com/how-to-protect-your-home-network-with-mullvad-vpn-opnsense/ (https://0x2142.com/how-to-protect-your-home-network-with-mullvad-vpn-opnsense/)
Ich weiß, die ist eigentlich für Mullvad, aber ich habe die Daten der OVPN-Anleitung für Instance und Peer benutzt.
Doch auch hier das gleich Ergebnis: Die Verbindung steht. Ein ifconfig sieht (jetzt) so aus:
wg0: flags=10080c1<UP,RUNNING,NOARP,MULTICAST,LOWER_UP> metric 0 mtu 1420
options=80000<LINKSTATE>
inet 172.28.116.74 netmask 0xffffffff
inet6 fd00:0:1337:cafe:::: prefixlen 128
groups: wg wireguard
nd6 options=103<PERFORMNUD,ACCEPT_RTADV,NO_DAD>
Ich hatte dann den Verdacht, es könnte vielleicht an den Regeln für die IP-Telefonie liegen, doch auch durch das Abschalten oder verschieben der Regeln, konnte ich nichts erreichen.
Die offizielle OPNsense Dokumentation habe ich mir zu dem Thema natürlich auch angesehen. Sie enthält auch einige Bespiele. Ich habe keine wirkliche Ahnung, was eine Roadwarrier-Konfiguration ist (dem Namen nach), aber für meine Begriffe sieht das ziemlich nach meiner Anwendung aus. Ich bin diese Schritte auch durchgegangen und leider ist das Ergebnis gleich.
Mein Verdacht ist, es liegt an den Firewall Regeln, weil die Verbindung aufgebaut wird (im Status "up") und unter System -> Routes -> Status das Interface wg0 ein paar mal auftaucht mit den richtigen Adressen. Aber ich komme zum Verrecken nicht dahinter, wo jetzt das Problem liegt.
Kann mir vielleicht jemand einen Schubser in die richtige Richtung geben?
Vielen Dank und viele Grüße!
Chris
P.S. Ich liefere gerne weitere Information noch nach. Ich wollte nicht alles in den Post packen, der ist schon lang genug, so wie er ist. :P
Quote from: dracolich on October 30, 2024, 02:30:32 AM
Hallo, liebe Freunde der Currywurst! ;D
Hallo, ich bevorzuge Bosna! ;)
Hast du auch Punkt 6 der Anleitung genau befolgt?
Wenn ja, darf man die Regel sehen?
Ich bin jetzt noch Halloween so langsam wieder nüchtern. ;D
QuoteHallo, ich bevorzuge Bosna! ;)
Der Hotdog von südlich des Weißwurstequators? ;D
Damit kann ich mich durchaus auch anfreunden! 👍🏼
QuoteHast du auch Punkt 6 der Anleitung genau befolgt?
Ich würde das jetzt nicht als sonderlich schwer ansehen. Also: Ja, habe ich. 😇
QuoteWenn ja, darf man die Regel sehen?
Logisch! ;)
Übersicht:
got82 LAN net * * * Interface address * NO
got82 ist die Beschreibung des Device (wg0 -> opt1)
Ausführlicher:
Disabled false
Do not NAT false
Interface got82
TCP/IP Version v4
Protocol any
Source invert false
Source address LAN net
Source port any
Destination invert false
Destination address any
Destination port any
Translation / target interface address
Log false
Translation / port: [none]
Static-port: false
Pool Options: default
Set local tag [none]
Match local tag [none]
No XMLRPC Sync false
Ist das ok so?
Beste Grüße!
Quote from: dracolich on November 03, 2024, 01:45:05 AM
Ich bin jetzt noch Halloween so langsam wieder nüchtern. ;D
:) War wohl eine heftige Feier...
QuoteDer Hotdog von südlich des Weißwurstequators? ;D
👍🏼
QuoteIch würde das jetzt nicht als sonderlich schwer ansehen. Also: Ja, habe ich. 😇
Nein, ist es nicht, aber aufgrund der Fehlerbeschreibung könnte hier am ehesten der Fehler liegen.
Ja, die Regel scheint in Ordnung zu sein.
Der Hybride Modus ist auch aktiviert?
Habe mir die Anleitung nochmals durchgesehen. Die hat ja gar kein Gateway Setting und "Dynamic gateway policy" im Wireguard Interface ist damit wohl Pflicht.
Ich vermute, ohne diesem Haken wird dir auch gar kein Gateway angezeigt am Dashboard oder in
System: Gateways: Configuration?
Wireguard kenne ich nur mit manuellem Gateway Setting, bin daher da auch überfragt.
Aber ein Gateway ist natürlich essentiell fürs Routing.
Es könnte vielleicht ein Fehler in der Tunnel Adresse sein, wodurch die Kommunikation mit dem Gateway nicht zustande kommt.
Ansonsten könnte eventuell doch das Wireguard Log hilfreiche Hinweise auf das Problem liefern
Grüße.
Quote:) War wohl eine heftige Feier...
You have no idea! 🤣
QuoteDer Hybride Modus ist auch aktiviert?
Japp. Diese Einstellung sehe ich nur unter NAT->Outbound. Ich nehme an, das ist normal so.
QuoteHabe mir die Anleitung nochmals durchgesehen. Die hat ja gar kein Gateway Setting und "Dynamic gateway policy" im Wireguard Interface ist damit wohl Pflicht.
Ich vermute, ohne diesem Haken wird dir auch gar kein Gateway angezeigt am Dashboard oder in System: Gateways: Configuration?
Hier kommt etwas auf, was mir bislang immer komisch vorkam. Wenn ich diesen Haken setze, bekomme ich im Log einen Fehler:
2024-11-13T13:18:26 Notice wireguard wireguard instance OVPN (wg0) started
2024-11-13T13:18:26 Notice wireguard /usr/local/opnsense/scripts/Wireguard/wg-service-control.php: plugins_configure monitor (execute task : dpinger_configure_do(,[GOT82_GW]))
2024-11-13T13:18:26 Notice wireguard /usr/local/opnsense/scripts/Wireguard/wg-service-control.php: plugins_configure monitor (,[GOT82_GW])
2024-11-13T13:18:26 Error wireguard /usr/local/opnsense/scripts/Wireguard/wg-service-control.php: ROUTING: not a valid opt1 interface gateway address: 'missing'
2024-11-13T13:18:26 Notice wireguard /usr/local/opnsense/scripts/Wireguard/wg-service-control.php: ROUTING: entering configure using opt1
2024-11-13T13:18:26 Notice wireguard wireguard instance OVPN (wg0) can not reconfigure without stopping it first.
Dieser Fehler kommt nicht, wenn
Dynamic gateway policy ausgeschaltet ist.
Are we getting closer? :)
Gruß zurück!
UPDATE (und ein ziemlicher WTF-Moment):Gerade läuft das VPN und ich kann es
reproduzierbar starten. Allerdings ist das noch keine wirklich tragbare Lösung, because, WTF⁉️
Was ich mache, ist folgendes:
- In einer shell starte ich einen ping 8.8.8.8 (der auch funktioniert)
- Ich starte Wireguard. Der Ping bekommt nur noch timeouts.
- Ich beende Wireguard wieder und die pings kommen wieder zurück.
- Ich schalte Dynamic gateway policy im Interface opt1 (das auf wg0 zeigt) ein.
- Ich schalte Wireguard ein.
Jetzt verändern sich die Pingzeiten (von ~6ms auf ~38ms). Das heißt, die Route hat sich verändert. mtr[8] bestätigt dies, weil jetzt auch z.B. 193-187-91-205.pool.ovpn.com im Trace drin ist.
Das ist aber nicht der WTF-Moment. Der kommt im Anschluss:
Ich starte Wireguard neu. Hier ist es egal, ob über den "restart" Knopf auf dem Dashboard oder indem ich den "Enable Wireguarg" Haken unter VPN ➡️ Wireguard ➡️ Instances einmal entferne, übernehme und wieder setze und übernehme. Jetzt ist die Verbindung wieder weg (Pings bekommen wieder nur Timeouts). Wenn ich das nicht über das Dashboard mache, bekomme ich bei abgeschaltetem Wireguard (wenig überraschend) die kürzeren Pingzeiten und einen anderen Trace. Wenn ich Wireguard wieder ganz ausmache, habe ich wieder Verbindung zum Netz.
Richtig bizarr wird es aber jetzt (Wireguard ist aus):
- Ich schalte Dynamic gateway policy im Interface opt1 (das auf wg0 zeigt) aus.
- Ich schalte Wireguard ein.
Und siehe da, ich habe wieder längere Pingzeiten und den Trace über OVPN! Zusammengefasst heißt das: Ich muss
Dynamic gateway policy "togglen" (Neudeutsch) vor einem erneuten Start von Wireguard. Wireguard funktioniert also bei beiden Einstellungen (an und aus) aber jeweil nur
ein Mal.
War meine WTF-Reaktion gerechtfertigt? ;D
Weitere Beobachtungen:
- Dynamic gateway policy zu togglen, während WG läuft bringt nichts. Ich muss WG einmal neu starten. Der Toggle muss nach dem Stopp und vor dem Start geschehen. Toggle bei laufendem WG und Neustart bringt nichts. Und ja, wenn ich das gemacht habe, muss ich WG stoppen, den Schalter wieder umwerfen und WG starten, damit es funktioniert.
- Wenn ich den besagten Schalter umwerfe und auf "Save" klicke, bekomme ich anschließend den Hinweis angezeigt, dass ich etwas verändert habe und ich die Einstellungen übernehmen müsse. Auf diese Taste muss ich seltsamerweise zweimal klicken, bevor sich etwas sichtbar verändert. Nach dem ersten Mal passiert nichts sichtbares. Der Browser (in meinem Fall Firefox) zeigt nur unten links 127.0.0.1 an (als die Adresse auf die ich geklickt habe. Nach dem zweiten Klick tut sich etwas: Ich bin wieder in den Einstellungen für das Interface. Ich habe keine Ahnung, ob das irgendwie Relevant ist, aber ich dachte, ich erwähne es mal. 🤷🏼♂️😇
- Ich habe gerade das Update auf Version 24.7.8 eingespielt. No change.
Hallo,
wie gesagt, habe ich mit automatischer Interface Konfiguration bei Wireguard leider keine Erfahrung. Ich könnte da auch nur herumprobieren. Aber das hast du vielleicht selbst schon alles gemacht.
Die Konfiguration hast du ja wahrscheinlich schon mehrmals mit der Anleiten gegen
geprüft.
Anhand deiner Schilderungen vermute ich, dass Wireguard hier die Default Route setzt.
So wie ich deinen ersten Post verstanden haben, beabsichtigst du über OVPN eingehende Verbindungen zu bekommen, um Services von außen erreichbar zu machen. Nur dafür braucht es gar kein Default Gateway.
Wäre interessant, was sich in der Routing-Tabelle ändert, wenn die Verbindung hergestellt wird.
Bekommst du auch ein sichtbares Gateway dazu?
Wenn ja, vielleicht mal die Einstellungen öffnen und den Haken bei Upstream Gateway entfernen, falls gesetzt.
Dann geht zwar erst mal kein Traffic von lokal drüber, aber mal sehen, wie es sich verhält.
"Far Gateway" würde ich auch versuchen, wenngleich das ohnehin automatisch durch die Interface-Konfiguration aktiv sein sollte (ohne den Haken).
In den Interface-Einstellungen würde ich testweise auch in den Hardware Settings die diversen Offloadings aktivieren.
Huhu,
gibt es denn neue Erkenntnisse zum Thema?
Ich habe genau dasselbe Phänomen zu beklagen.
Habe es mittlerweile hinbekommen :)
Wireguard läuft nun, inkl. no DNS-Leak!
Zwar mit einem andrem VPN Anbieter wie hier gewünscht, aber es funktioniert.
Die Problematiken dürften hier jedoch die selben sein.
Versuche heute Abend mal ne Anleitung zu schreiben.
Vielleicht hilfts...
Geholfen hat die Anleitung von Koshun aus dem englischen Forum:
https://forum.opnsense.org/index.php?topic=21350.0
Linux für die ersten Schritte empfehlenswert, sofern nicht alle Daten in der vom VPN Anbieter generierten Config bereit stehen...