OpenVPN - bekomme keine Verbindung zustande

[Marcel_75]

Auch auf die Gefahr hin, dass ich hier langsam nerve ... 

Zumindest eine Kleinigkeit (ein bug?) ist mir gerade noch bei der Server-Config aufgefallen.

push "route 192.168.1.0 255.255.255.0"

Dies steht da jetzt 2x drin!

Eingetragen hatte ich es ursprünglich bei "Advanced" als zusätzliche Option (so wie in der weiter oben verlinkten Anleitung auch beschrieben).

Und da ich gestern ja noch einmal wie empfohlen "Disable IPv6" aktiviert hatte, sonst aber nichts geändert hatte, kann ich es mir nur so erklären, dass dies durch dieses nochmaliges ändern und speichern der Server-Config geschehen ist?

Und auch dazu sage ich: Bitte nicht falsch verstehen (ich finde OPNsense spitze, vor allem da es "OpenSource" ist), aber auch das zeigt einmal mehr, dass bei diesem Projekt configs fehlerhaft gesichert werden (können).

Dieser spezielle Fall mag jetzt keine gravierenden Auswirkungen haben (der doppelt vorhandene Eintrag wird sehr wahrscheinlich einfach ignoriert werden), aber es ist doch schon bedenklich, wenn so etwas überhaupt passieren kann!?!

Wer weiß, an welcher Stelle noch ähnliche Fehler lauern, die dann aber weitreichendere Auswirkungen haben?

PS: Da ich den Fehler leider nicht eingrenzen kann werde ich vermutlich nicht drum herum kommen, OPNsense nun komplett auf die Werkseinstellungen zurückzusetzen und das setup noch einmal von vorn zu beginnen. Werde es dann auch in einer anderen Reihenfolge angehen und OpenVPN mit als erstes konfigurieren.

Danke trotzdem für Eure Hilfe!

[JeGr]

>aber auch das zeigt einmal mehr, dass bei diesem Projekt configs fehlerhaft gesichert werden (können).

Ist das angegebene Netz nicht einfach dein LAN? Wenn ja - warum hast du es dann überhaupt nochmal in den Advanced Settings eingetragen?
Dann ist es kein Wunder, dass es doppelt drinsteht - was in dem Fall allerdings auch egal wäre, denn ob es nun einmal oder zweimal gepusht wird, das Netz wird eben in der Routing Table stehen. Das hat dann nichts mit irgendwelchem Projekt, Open Source oder Konfiguration falsch speichern zu tun, wenn du selbst es in den Adv. Settings reinschreibst wird es natürlich auch gespeichert, selbst wenn es doppelt ist. Daher HEISST das Feld ja Advanced! Settings. Dort Einträge zu machen geschieht logischerweise auf eigene Gefahr, denn das zu parsen und auszuwerten ob das OK ist was die Leute da reinpacken ist annähernd unmöglich.

Gruß

[chemlud]

@JeGr

https://www.sparklabs.com/support/kb/article/setting-up-an-openvpn-server-with-opnsense-and-viscosity/

...in der Anleitung steht das mit der "push route" für's eigene Netz ausdrücklich drin. Verstanden hab' ich's nicht wirklich, wenn man doch sein Netz sowieso angeben muss in der Konfig...

[JeGr]

Was wieder ein Grund sein mag, warum ich mich zwar einerseits über Howtos und Tutorials freue aber sie nicht wirklich mag. Oft beziehen sie sich auf ältere oder alte Versionen, Sachen stimmen so nicht mehr oder sind überholt und dann fragt man sich, warum der Kram nicht funktioniert... Da leider die Screens ja ziemlich zusammengeschnitten sind sieht man auch nicht ob sich das Ganze ggf. auf eine alte/ältere Version bezieht. Der Sinn erschließt sich mir aber nicht wirklich.

[Marcel_75]

@JeGr: Diese "Advanced"-Einstellung habe ich an keiner einzigen anderen Stelle gesetzt, sondern ausschließlich (und wie in der Anleitung der Viscosity-Macher vorgesehen) bei der OpenVPN-Server-Config.

Es bleibt also dabei: Diese Einstellung wurde eindeutig deshalb 2x in das Config-file geschrieben, weil ich an der OpenVPN-Server-Config (wie von einem weiteren Foren-Mitglied vorgeschlagen) die Option "Disable IPv6" aktiviert hatte!

Wie Du darauf kommst, dass ich das im "LAN"-Netz eingetragen hätte, erschließt sich mir nicht ...

Auch hatte ich ja das Problem (eingangs erwähnt), dass Firewall-Configs, die eigentlich schon gelöscht waren, plötzlich doch wieder auftauchten! Mag am Browser-Caching oder was auch immer gelegen haben, aber Mozilla Firefox ist ja nun auch kein ungewöhnlicher Browser behaupte ich mal.

Und aus meiner Sicht habe ich hier auch so ziemlich alles gepostet, was möglich war bzw. gewünscht wurde:

- Server- & Client-Config
- TCPDUMP-Aufzeichnungen sowohl der OPNsense als auch des MacBooks

Auch habe ich sichergestellt, dass DynDNS ordnungsgemäß funktioniert, dass das korrekte Interface (WAN) bei der OpenVPN-Server-Config ausgewählt ist, dass die per Wizard gesetzten Firewall-Regeln korrekt sind - ja ich habe sogar auf einen Fehler in der Viscosity-Anleitung verwiesen (DNS-settings), der nun korrigiert ist.

Und trotzdem haben wir leider keine Lösung gefunden! 

Ich kann auch gern den Part übernehmen, eine komplett deutsche Anleitung inklusive Screenshots zu erstellen, die dann auch wirklich von allen "abgesegnet" ist und als Referenz-Anleitung durchgehen kann.

Aber eigentlich hätte ich, bevor ich die OPNsense wieder auf die Werkseinstllungen zurücksetze, schon gern gewusst, warum zum T***** das nicht funktioniert?

[chemlud]

Maaaannn, liess mal deine Anleitung unter Punkt 9.:

" To allow access to machines on the local network, enter your local IP range in the Local Network setting. It will probably be something like 10.0.0.0/24."

Damit sollte die route *auch* gepushed werden.

"Wir" brauchen keine Lösung, openVPN funzt, du hast die Konfig irgendwo mit einem Typo oder ähnlichem verk*t. Hinsetzen, nochmal machen, bis es geht. Weinen hilft ja nix, es kommt niemand und setzt dir deinen Kram auf... ;-)

[Marcel_75]

Das hier niemand vorbei kommt, um mir das aufzusetzen, ist mir schon klar. 

Dass es der Hauptsonsor Deciso (bei dem ich auch die Hardware gekauft habe, um dieses Projekt zu unterstützen) aber scheinbar nicht für nötig hält, auf eine E-Mail zu reagieren (ich warte nun bereits eine Woche auf eine Reaktion), ist mehr als schwach, zumal ich eigentlich noch extra draufgezahlt hatte für einen (offensichtlich ja nicht vorhandenen!!!) Support für ein Jahr.

Fakt ist, Du empfiehlst mir so zu agieren, wie ich es eigentlich nur von Windows-Kollegen kenne - wenn es nicht klappt, Maschine einfach platt machen und noch einmal von vorn beginnen (geht schneller, als den eigentlichen Fehler einzugrenzen).

Sorry, aber ich nutze macOS, weil ein BSD darunter steckt und Du eventuell ein Linux, weil es eben Linux ist.

Und dort haben wir Log-Files und TCPDUMP und und und ...

Und wenn ich schon seit Monaten an irgend welchen configs schrauben würde, gäbe ich Dir im Zweifel ja sogar recht.

Hier reden wir aber von einer OPNsense, die taufrisch vor wenigen Tagen mit 17.7 bestückt wurde!

Und da kann es ja wohl nicht sein, dass alles schon so verkorkst sein soll ...

[chemlud]

...die Idee zum Werksreset kam von DIR. ;-)

Was bitte soll denn der Hersteller machen? Wenn deine Fritzbox "nicht geht", kommen die dann vorbei und setzen dir das Ding auf? :-D

[JeGr]

Das hier niemand vorbei kommt, um mir das aufzusetzen, ist mir schon klar. 

Doch, "vorbei" kommen und aufsetzen könnten schon Leute. Aber da das Zeit-intensiv sein kann, kostet das meistens Geld

Dass es der Hauptsonsor Deciso (bei dem ich auch die Hardware gekauft habe, um dieses Projekt zu unterstützen) aber scheinbar nicht für nötig hält, auf eine E-Mail zu reagieren (ich warte nun bereits eine Woche auf eine Reaktion), ist mehr als schwach, zumal ich eigentlich noch extra draufgezahlt hatte für einen (offensichtlich ja nicht vorhandenen!!!) Support für ein Jahr.

Der "Hauptsponsor" hat erstmal primär nix mit der Projektleitung oder -führung (im Sinne von "er muss aber X oder Y") zu tun. Nur weil du bspw. eine Asterisk Appliance von Firma X kaufst, hat die Firma an der Stelle auch nichts damit zu tun, wenn dein Asterisk nicht läuft und kann dann dem Projekt vorschreiben irgendwas zu ändern. Ich glaube da verwechselst du ein paar Abhängigkeiten.
Was du für Support gekauft hast, kann ich natürlich nicht sagen, aber ich vermute es war Hardware(!) Support und kein Software Support? Ansonsten hättest du sicherlich entsprechende Daten bekommen an die du dich direkt wenden kannst für den OPNsense Support.

Fakt ist, Du empfiehlst mir so zu agieren, wie ich es eigentlich nur von Windows-Kollegen kenne - wenn es nicht klappt, Maschine einfach platt machen und noch einmal von vorn beginnen (geht schneller, als den eigentlichen Fehler einzugrenzen).

Das wird auch nur deshalb empfohlen, weil es in deinem Fall sehr schwierig ist genau klar zu erkennen, an welcher Stelle was falsch aufgesetzt ist. Du hast irgendwelche Einstellungen vorgenommen, dann ein externes Tutorial verwendet das ggf. ältere oder nicht mehr aktuelle Einstellungen beschreiben könnte und nun noch beim Debugging irgendwelche Haken gesetzt. Inzwischen ist einfach nicht mehr klar erkennbar, wo du dir ggf. selbst auf der Leitung stehst. Deshalb ist es in solch einem Fall - und weil das Aufsetzen im Normalfall sehr schnell geht - einfach die einfachste Form nochmal schnell von einem eindeutigen Stand anzufangen ohne irgendwelche falschen Einstellungen. Ansonsten müsste man schon alle Ecken prüfen, von DNS über Filter Regeln, NAT, OpenVPN settings etc. um mal ein konkretes Bild zu erkennen.

> Sorry, aber ich nutze macOS, weil ein BSD darunter steckt und Du eventuell ein Linux, weil es eben Linux ist.
> Und dort haben wir Log-Files und TCPDUMP und und und ...

Was hat das denn gerade mit dem Problem zu tun?

Es bleibt also dabei: Diese Einstellung wurde eindeutig deshalb 2x in das Config-file geschrieben, weil ich an der OpenVPN-Server-Config (wie von einem weiteren Foren-Mitglied vorgeschlagen) die Option "Disable IPv6" aktiviert hatte!

Das sagst du - allerdings sage ich an der Stelle, dass die Option mit der Route Push Option eigentlich nichts zu tun hat denn das einzige was dadurch getriggert wird, ist die Option "tun-ipv6". Kann ich hier mehrfach problemlos nachvollziehen. Der Eintrag hat absolut keine Auswirkung auf irgendwelche Route Pushes.

Wie gesagt, das ist alles nicht böse gemeint, aber du machst Annahmen und Aussagen, die so einfach nicht ganz passen und deshalb war die Aussage mit "vielleicht mal resetten/neu installieren" gar nicht so verkehrt. Wenns nur um OpenVPN geht, könnte man auch sicherlich nochmal den ganzen VPN Server wegwerfen und löschen und statt eines externen Tutorials einfach mal den intern bereits vorhandenen! Wizard/Assistenten zum Aufsetzen benutzen. Dann klappts auch vielleicht besser als wenn man mögliche Fehler aus externen Quellen immer wieder wiederholt werden

[NicholasRush]

Hallo zusammen,

gerade bei OpenVPN empfehle ich mal die Offizielle "Readme" vom Projekt: https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage

Um beim Server mehr im Log zu sehen sollte das Verbose Level "verb 4" sein.

Damit eine vom Server gepuschte Route vom Client akzeptiert wird, muss in der Client Config mit einem "pull" ergänzt werden. Dies steht in deiner Client Config, wie ich gerade im Thread gelesen habe, nicht drin.

Beste Grüße
NR

[Marcel_75]

So, habe jetzt mal den User (der die VPN-Verbindung aufbauen darf) sowie sämtliche Zertifikate gelöscht. Sowie den Server natürlich.

Zusätzlich habe ich auch noch einmal per SSH auf der OPNsense geschaut, ob da configs von OpenVPN liegen geblieben sind und diese ebenfalls entfernt.

Außerdem den Browser gewechselt (Safari 11.0.2 statt Firefox 57) und sicherheitshalber den Browser-Cache gelöscht.

Am Ende auch noch einmal die OPNsense komplett neu gestartet.

Frage: Nach einem Neustart der OPNsense sehe ich im Dashboard, dass ntpd und suricata nicht automatisch aktiv sind (sondern nur configd, dhcpd, dyndns, pf sowie unbound) - woran kann das liegen?

Wenn ich ntpd dann manuell starte, läuft ntpd problemlos und auch suricata wird dabei automatisch mit gestartet.

[JeGr]

Bei Suricata kann ich dir das leider nicht sagen. Bei NTP könnte es an mehreren Dingen liegen. Gibt es dazu Log Einträge? Der NTP kann z.B. ein bestimmtes Fehler-Intervall nicht überschreiten. Sprich wenn die Zeit um mehr als (2h?) daneben liegt, wird der NTP nicht korrigieren und ggf. beenden. Oder er konnte nicht starten/laufen weil ggf. das WAN noch nicht sauber da war o.ä. - das sollte sich aber im Log finden lassen. Hast du direkt nach einem Neustart geschaut oder den Diensten ein paar Minuten Zeit gegeben dass sie vielleicht noch gestartet hätten?

[Marcel_75]

Du hast recht, wenn man sich etwas in Geduld übt, startet der Zeit-Server doch noch. 

Im log stand übrigens folgendes direkt nach einem Neustart:

Nov 18 18:04:17 OPNsense ntpdate[723]: step time server 129.70.132.34 offset -0.596793 sec
Nov 18 18:04:17 OPNsense ntp: Successfully synced time after 1 attempts.
Nov 18 18:04:17 OPNsense ntp: Starting NTP Daemon.
Nov 18 18:04:17 OPNsense ntpd[79547]: ntpd 4.2.8p10@1.3728-o Wed Oct 25 06:38:17 UTC 2017 (1): Starting
Nov 18 18:04:17 OPNsense ntpd[79547]: Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
Nov 18 18:04:18 OPNsense ntpd[79894]: proto: precision = 0.202 usec (-22)
Nov 18 18:04:18 OPNsense ntpd[79894]: Listen and drop on 0 v6wildcard [::]:123
Nov 18 18:04:18 OPNsense ntpd[79894]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Nov 18 18:04:18 OPNsense ntpd[79894]: Listen normally on 2 em0 192.168.1.1:123
Nov 18 18:04:18 OPNsense ntpd[79894]: Listen normally on 3 em0 [fe80::f690:eaff:fe10:1eef%1]:123
Nov 18 18:04:18 OPNsense ntpd[79894]: Listen normally on 4 lo0 [::1]:123
Nov 18 18:04:18 OPNsense ntpd[79894]: Listen normally on 5 lo0 127.0.0.1:123
Nov 18 18:04:18 OPNsense ntpd[79894]: Listening on routing socket on fd #26 for interface updates
Nov 18 18:04:18 OPNsense ntpd[79894]: mlockall(): Cannot allocate memory
Nov 18 18:05:14 OPNsense ntpd[79894]: ntpd exiting on signal 15 (Terminated)
Nov 18 18:05:14 OPNsense ntpd[79894]: 129.70.132.34 local addr 192.168.1.1 -> <null>

Dieses "Cannot allocate memory" sieht etwas eigenartig aus, kann ich aber wahrscheinlich ignorieren?

Später sieht es im log dann so aus:

Nov 18 18:05:31 OPNsense ntpdate[49019]: adjust time server 85.14.245.16 offset 0.001104 sec
Nov 18 18:05:31 OPNsense ntp: Successfully synced time after 1 attempts.
Nov 18 18:05:31 OPNsense ntp: Starting NTP Daemon.
Nov 18 18:05:31 OPNsense ntpd[93042]: ntpd 4.2.8p10@1.3728-o Wed Oct 25 06:38:17 UTC 2017 (1): Starting
Nov 18 18:05:31 OPNsense ntpd[93042]: Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
Nov 18 18:05:31 OPNsense ntpd[93075]: proto: precision = 0.205 usec (-22)
Nov 18 18:05:31 OPNsense ntpd[93075]: restrict: 'monitor' cannot be disabled while 'limited' is enabled
Nov 18 18:05:31 OPNsense ntpd[93075]: Listen and drop on 0 v6wildcard [::]:123
Nov 18 18:05:31 OPNsense ntpd[93075]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Nov 18 18:05:31 OPNsense ntpd[93075]: Listen normally on 2 em0 192.168.1.1:123
Nov 18 18:05:31 OPNsense ntpd[93075]: Listen normally on 3 em0 [fe80::f690:eaff:fe10:1eef%1]:123
Nov 18 18:05:31 OPNsense ntpd[93075]: Listen normally on 4 lo0 [::1]:123
Nov 18 18:05:31 OPNsense ntpd[93075]: Listen normally on 5 lo0 127.0.0.1:123
Nov 18 18:05:31 OPNsense ntpd[93075]: Listening on routing socket on fd #26 for interface updates
Nov 18 18:05:31 OPNsense ntpd[93075]: mlockall(): Cannot allocate memory

[Marcel_75]

So, mittlerweile habe ich es per OPNsense Wizard noch einmal "from scratch" versucht - hat leider wieder nicht funktioniert.

Habe deshalb jetzt alternativ in meinem Synology-NAS einen OpenVPN-Server aktiviert und in der OPNsense NAT/Port Forward aktiviert.

Source
--------
If: WAN
Proto: UDP
Address: *
Ports: 1194 (OpenVPN)

Destination
-------------
Address: LAN address
Ports: 1194 (OpenVPN)
IP: 192.168.1.111
Ports: 1194 (OpenVPN)

Und auch so klappt es nicht. 

Jetzt habe ich langsam die Vermutung, dass es eventuell mit meinem Internet-Provider zu tun haben könnte?

Tele Columbus (mein bisheriger Kabelnetz-Provider) wurde vor kurzem zu Pyur.

https://www.pyur.com/

Und da seit der Umstellung zum Beispiel auch im Online-Portal keine Rechnungen mehr abrufbar sind, würde es mich nicht wundern, wenn es eventuell auch an anderer Stelle klemmt?

Ist das denkbar? Falls ja, wie kann man so etwas am besten überprüfen?

PS: Ich habe schon auf gefühlt hunderten Synology-NAS OpenVPN aktiviert und das entsprechende Port Forwarding & DynDNS im Router konfiguriert, das hatte bisher nirgendwo Probleme bereitet. Nur bei mir will es nicht klappen ... weder mit OPNsense selbst noch mit Synology.

Ist also eventuell mein Internet-Provider Schuld?

Ergänzung: Denn auf dem WAN-Interface habe ich einen 100.xxx.xxx.xxx Adresse, außen aber meine auch per DynDNS-erreichbare "normale" IPv4-Adresse. Pyur setzt also Carrier Graded Nat ein - und das ist dann also offensichtlich mein Problem?

[chemlud]

Tunnel mit gleicher (öffentlicher) IP für Server und Client funktionieren nicht. Nie.

Du bräuchtest einen Server bei einem Bekannten, mit anderer öffentlicher IP...