Messages

[Danke im Voraus für Eure Unterstützung!]

Bei "Settings" ist das hier eingestellt:

Enabled: YES
IPS mode: YES (Hardware CRC, Hardware TSO und Hardware LRO sind wie empfohlen deaktiviert)
Promiscuous mode: NO
Enable sylog: NO
Pattern matcher: Aho-Corasick
Interfaces: WAN
Rotate log: Weekly
Save logs: 4

Und im Bereich "Download" sind folgende Filter aktiviert (drop):

abuse.ch/Dyre SSL IPBL   
abuse.ch/Feodo Tracker   
abuse.ch/SSL Fingerprint Blacklist   
abuse.ch/SSL IP Blacklist
ET open/botcc   
ET open/botcc.portgrouped   
ET open/ciarmy   
ET open/compromised
ET open/drop
ET open/dshield
ET open/emerging-activex

Vermutlich sind das einfach "zu viele" für ihn?

Oder liegt es an einer anderen (falschen) Einstellung?

Bei der CPU- und RAM-Auslastung war mir bisher aber nicht aufgefallen, dass da irgend etwas "am Limit" läuft.

Danke im Voraus für Eure Unterstützung!  :D

[Es liegt am aktivierten Intrusion Detection (suricata)!]

Hallo zusammen,

bin gerade durch Zufall darauf gestoßen, warum mein 400er-Kabelanschluss (PYUR) seit Wochen nur knapp 100 MBit statt der versprochenen "bis zu 400 MBit" liefert:

Es liegt am aktivierten Intrusion Detection (suricata)!

Aufgefallen ist es mir nur dadurch, dass der Zack-Speedtest von AVM direkt nach einem Neustart des Routers (AMD GX-416RA SOC mit 4 cores und SSD) für ca. 30 Sekunden stattliche ~360 MBit/s down schaffte - aber nur so lange, bis suricata (Intrusion Detection) aktiv wurde – dann fällt die Geschwindigkeit relativ zeitnah auf unter 100 MBit.

http://avm.de/nc/service/zack-der-speedtest-fuer-ihre-breitbandverbindung/

Wann suricata aktiv wird, kann man ja recht einfach im Dashboard sehen.

Nach dem Neustart von OPNsense war es bei mir schon immer so, dass sowohl der ntpd (Network Time Daemon) immer einige Zeit brauchte, bis er auch wirklich aktiv ist (grün statt rot) - und auch suricata benötigt eben einige Sekunden, bis es aktiv ist.

Und jetzt habe ich das mehrmals durchgespielt, es liegt defintiv am suricata:

Sobald ich es aktiviere, komme ich auf knapp 92 bis maximal 98 MBit/s beim Download.

Ist suricata dagegen deaktiviert, schafft der Anschluss problemlos, was PYUR verspricht – in meinem Fall also 396,159 MBit/s (49,520 MByte/s) down (gerade noch einmal getestet).

Die Frage ist für mich jetzt: Warum ist das so?

Suricata hatte ich auch schon mit meinem alten 120er-Anschluss genutzt, dort dann aber auch immer die knapp 120 MBit/s im Download erreicht – wie gesagt mit aktiviertem suricata.

Und seit der Umstellung auf den 400er-Anschluss kam ich nie über 100 MBit/s im Download, obwohl ich an den Einstellungen nichts geändert hatte (also sowohl beim Intrusion Detection als auch in anderen Bereichen).

Ich hatte das Modem tauschen lassen, sämtliche Netzwerk-Kabel geprüft, alle meine Switche etc. – und am Ende lag es scheinbar an irgend einer "verkorksten" Einstellung beim "Intrusion Detection"?

Bin gespannt, ob das anderen auch schon mal passiert ist?

Meine suricata-settings liefere ich gleich nach ...

Hallo zusammen,

ich hätte da mal eine Art "feature request" bzw. einen Vorschlag, über den man ja mal diskutieren könnte.  :)

Bei (z.B.) Synology-NAS finde ich ein Feature wirklich gut: Mit Hilfe eines sogenannten "Security Advisor" können diverse System-Einstellungen geprüft werden – und bei Problemen wird man dann auch gleich mit einer Erläuterung inklusive passenden Link an die "richtige Stelle" des DSM-GUI geleitet, um die problematische Einstellung entsprechend anzupassen. Das ist auch noch einmal aufgeteilt in "Home" und "Business", bei "Business" dann mit entsprechend höheren Sicherheits-Anforderungen.

Wäre so etwas in der Art theoretisch auch für das OPNsense-System umsetzbar?

Habe mir mit Hilfe diverser Tutorials zwar vieles so konfiguriert, wie es laut Anleitung auch sein soll (z.B. auch einen Werbe- & Tracking-Blocker per blacklist.conf in den Custom-Einstellungen des Unbound DNS Resolver), und das scheint auch alles gut und zuverlässig zu funktionieren.

Aber da ich weder Netzwerk- noch Sicherheits-Experte bin, bleibt bei so etwas halt irgendwie das mulmige Gefühl, dass man an der einen oder anderen Stelle vielleicht doch einen Haken zu viel oder zu wenig gemacht hat ...  :-[

Also ist so etwas denkbar? Oder aufgrund der unendlich vielen Konfigurationsmöglichkeiten und der schieren Komplexität von Netzwerk-Umgebungen eher aussichtslos?

@JeGr: Ja, Deine Empfehlung klingt für mich auch sinnvoll und absolut nachvollziehbar.

Und so wäre es tatsächlich das Beste für uns – ich und meine Freundin dürfen sich mit "unserem Netzwerk" verbinden und gleichzeitig auch darüber surfen.

Aber alle anderen User dürfen standardmäßig per VPN zwar in "unser Netzwerk" (und somit per zusätzlichen User-Account für die AFP- bzw. SMB/CIFS-Freigabe auch auf das NAS).

Aber grundsätzlich dürfen diese anderen User nicht über "unser Netz" surfen.

Werde das so erst einmal versuchen zu konfigurieren und würde bei Problemen / Verständnisschwierigkeiten noch einmal hier nachfragen.

Danke schon einmal Euch beiden für diese hilfreichen Ratschläge.

Vielen Dank schon mal, das führt mich schon auf die richtige Spur.

Habe jetzt dem User Dank Deiner Beschreibung eine feste IP zugewiesen (in meinem Fall ist das die 10.1.2.76).

D.h., in den "client specific overrides" für diesen User steht jetzt:

Code Select Expand

ifconfig-push 10.1.2.76 255.255.255.0

CommonName seines Zertifikats ist auch ausgewählt und als IPv4 Tunnelnetwork 10.1.2.0/24 eingetragen.

OpenVPN-Zugriff klappt, er bekommt auch wie gewünscht die IP 10.1.2.76 und kann sich per AFP auf dem NAS anmelden.

Wie genau gehe ich jetzt vor, um die Firewall so einzustellen, dass er nur noch OpenVPN + AFP-Zugriff machen darf bei mir?

Könnte ich z.B. "alles" für die IP 10.1.2.76 verbieten und dann Ausnahmen für die AFP-Ports erlauben?

Das wären meines Wissens nach dann:

Port     Protokoll     Name                                              Zweck

427     TCP            Service Location Protocol (SLP)         Network Browser, Authentication
523     TCP            Apple Filing Protocol (AFP)                Apple File Service
548     TCP            Apple Filing Protocol (AFP) über TCP  AppleShare, Persönliche Dateifreigabe, AFP-Dateiserver
5353   UDP           Multicast DNS (MDNS)                      Service Announcement

Und dann ist die Firewall der OPNsense ja auch noch einmal aufgeteilt in die Bereiche WAN, LAN und OpenVPN.

Dort habe ich bisher nur automatisch generierte Regeln drin - denn leider habe ich bisher noch nie manuell Regeln für die Firewall erstellt, von daher vielen Dank für weitere Unterstützung (Einführung ins "Neuland" sozusagen).  ;D

Hallo zusammen,

vor einigen Monaten hatte ich hier schon einmal einen längeren Thread zum Thema OpenVPN eröffnet – letztlich funktionierte alles wie es soll, das Problem lag bei meinem Internet-Provider (carrier graded NAT aka CGN war ungefragt aktiviert worden beim Wechsel von Tele Columbus zu PYUR).

Seitdem CGN deaktiviert ist, funktioniert auch wieder der OpenVPN-Server wie gewünscht, bzw. genauer gesagt mein DynDNS-Name zeigt wieder auf meine "eigene" IP.  :)

Für mich selbst und meine Freundin habe ich einen ganz normalen OpenVPN-Zugriff, d.h. ich kann von außen auf mein internes Netzwerk zugreifen und kann darüber auch surfen.

Jetzt habe ich aber eine grundsätzliche Verständnisfrage:

Wie kann ich einen weiteren VPN-User einrichten, der zwar in mein Netzwerk kommt (damit er auf Fotos meines NAS zugreifen darf), aber dann nicht gleichzeitig über meinen Anschluss surfen kann?

Hatte schon ein paar settings probiert, letztlich mache ich aber scheinbar irgend etwas falsch, denn mit ein wenig rumprobieren (Änderungen an der exprotierten ovpn.cfg) konnte letztlich auch dieser User über meinen Anschluss surfen, obwohl ich das wie gesagt nicht erlauben möchte.

Kann man das denn überhaupt irgendwie komplett unterbinden, wenn es gleichzeitig User auf diesem OpenVPN-Server gibt, die das dürfen sollen?

Vielen Dank für Eure Unterstützung!

PS: aktuelles OPNsense 18.1.2_2-amd64 / FreeBSD 11.1-RELEASE-p6 / LibreSSL 2.6.4

[Ich frage mich auch nach wie vor, ob man in solch einem Falle nicht ein Sonderkündigungsrecht hat, denn Anschlüsse mit solchem CGN sind doch - wenn man es genau nimmt - "verkrüppelte" Internet-Anschlüsse, die für Oma Trude und Netflix ja ausreichen mögen, für jeden ambitionierten Anwender aber so massive Einschränkungen mit sich bringen (kein normales IPv4-Port-Forwarding mehr möglich), dass der Anschluss im Prinzip völlig nutzlos ist, sobald man "von außen" auf sein privates Netzwerk zugreifen möchte.]

Ich danke Euch allen erst einmal für Eure Geduld und Unterstützung.

Echt übel, dieses CGN (Carrier Graded NAT).

Habe eine "echte" IPv4-Adresse heute sowohl im PYUR-Shop beantragt (ehemals Tele Columbus) als auch jetzt noch einmal per Kontakt-Formular auf der PYUR-Webseite.

Die Hotline von denen ist der absolute Witz - egal zu welcher Uhrzeit man von Mo. bis Fr. zwischen 8 und 22 Uhr anruft, entweder wartet man bis zu 30 Minuten in der Warteschleife und fliegt dann raus (es wird einfach aufgelegt nach knapp einer halben Stunde) oder aber es kommt sogar gleich die Ansage, dass alle Mitarbeiter beschäftigt sind und man es später noch einmal versuchen solle (und da wird dann auch direkt aufgelegt).

Im Shop sagte man mir heute schon, solch eine Änderung könne bis zu 4 Wochen dauern, da aktuell alle Mitarbeiter überlastet seien.  :(

Das ist wirklich übel, zumal es ja ursprünglich (zu Tele Columbus Zeiten) funktioniert hatte und nun scheinbar seit PYUR nicht mehr!

Ich frage mich auch nach wie vor, ob man in solch einem Falle nicht ein Sonderkündigungsrecht hat, denn Anschlüsse mit solchem CGN sind doch - wenn man es genau nimmt - "verkrüppelte" Internet-Anschlüsse, die für Oma Trude und Netflix ja ausreichen mögen, für jeden ambitionierten Anwender aber so massive Einschränkungen mit sich bringen (kein normales IPv4-Port-Forwarding mehr möglich), dass der Anschluss im Prinzip völlig nutzlos ist, sobald man "von außen" auf sein privates Netzwerk zugreifen möchte.

Als Notbehelf habe ich jetzt QuickConnect auf der Synology aktiviert, finde das zwar nicht so pralle, weil der Relay-Server von Synology ja im Prinzip auch ein "man in the middle" ist (bzw. sein kann wenn er möchte), aber anders geht es ja vorerst erst einmal nicht und so komme ich wenigstens erst einmal an wichtige Dateien auf meiner Synology.

DynDNS und IPv4-Port-Forwarding oder von mir aus auch eine "feste" IPv4-Adresse nebst entsprechender Port-Weiterleitung brauche ich aber nach wie vor, um OpenVPN spielen zu können.

Hoffe, dass das so schnell wie möglich geklärt wird bei PYUR ...  :-\

Auf alle Fälle noch einmal vielen vielen Dank für Eure Geduld und Unterstützung - ihr seid Klasse!

[Was sagt ihr dazu? Was wäre Eure Empfehlung?]

PS: Das hier habe ich gerade noch bei heise gefunden, ist zwar von 2013, aber betrifft mich ja auch (Quelle: https://www.heise.de/forum/c-t/Netze/Server-Dienste/Re-DYNDNS-nutzlos/posting-243003/show/):

Solltest du wirklich hinter CGN stecken, bleiben dir nur noch folgende Optionen, wie teilweise schon von anderen gesagt:

1.) IPv6 – langfristig die ,,richtig" Lösung. Wenn Telecolumbus CGN bereits eingeführt hat, dann besteht auch die Chance, dass sie dir evtl. auch schon IPv6 geben. Guck doch mal, ob dein Router das unterstützt (Fritzboxen bspw. ab 7270 – oder wie AVM sagt: ,,die zweite Ziffer in der Modellnummer muss >= 2 sein) und ob dir Telecolumbus IPv6 gibt. Dann noch einen mobilen Tunnel für den Zugriff von außen organisieren und mit der Zukunft glücklich werden.

2.) einen VPN-Tunnel bauen, der sich von drinnen nach draußen über einen Relay-Server aufbaut. Großes Gebastel. Wahrscheinlich auch nicht allzu stabil. Aber einen Versuch wert.

3.) Quängeln. Verschiedene andere Kabelprovider (wenngleich auch nicht Telecolumbus) haben auf dem IPv6-Kongress unter der Hand gesagt, sie würden Kunden, die nur lange genug jammerten, bei CGN auch wieder auf eine public IP umstellen (die anderen störts nicht)

4.) PCP – ganz heiße Scheiße, das ,,Port Control Protocol" gibt die Möglichkeit, auch bei einem CGN noch ein Portforwarding zu installieren. Das ist aber momentan wirklich brandneu (RFC vom April 2013) und wahrscheinlich noch nicht implementiert. AVM baut das gerade in die Fritzbox ein und es ist angemessen, es von deinem ISP zu erwarten, dass er das umsetzt, wenn er dich hinter ein NAT verfrachtet. Nachfragen!

Was sagt ihr dazu? Was wäre Eure Empfehlung?

[Was wäre denn in solch einem Fall die beste Lösung für mich?]

In Ordnung, jetzt habe ich also (endlich!!!) erst einmal verstanden, warum das bisher nicht funktioniert.

Sobald ich statt meiner DynDNS-Adresse zum Test die interne 192.168.1.111 meines Synology-NAS eintrage, funktioniert die OpenVPN-Verbindung.

Das selbe Ergebnis hätte ich mit Sicherheit, wenn ich den OpenVPN-Server jetzt z.B. wieder direkt auf der OPNsense einrichte und mich dann mit der internen 192.168.1.1 der OPNsense verbinden würde.

Die OpenVPN-Config war also grundsätzlich i.O., sowohl auf der OPNsense, also auch auf dem Synology-NAS.

Mein Problem ist also dieses so genannte "Carrier Graded Nat" - extern habe ich zwar die IP 158.181.74.19, teile mir diese aber "dank" NAT mit vielen anderen Nutzern. Und mein WAN-Interface hat eigentlich die 100.93.0.154 ... Deshalb funktioniert das alles nicht zur Zeit.  :-[

Wie gehe ich damit am besten um? Egal ob ich bei synology.me oder bei no-ip.com eine DynDNS-Adresse nutze, beide geben mir ja nur diese (gemeinsam genutzte) öffentliche IP 158.181.74.19.

Was ich jetzt bräuchte, nämlich eine Port-Weiterleitung von dieser 158.181.74.19 auf meine WAN-Adresse 100.93.0.154 kann ja sowieso nur mein Provider für mich einrichten, und das macht der garantiert nicht.  :'(

Was wäre denn in solch einem Fall die beste Lösung für mich?

Ich würde schon gern mein NAS und auch einige Dienste, die ich im lokalen Netzwerk betreibe, per VPN von außen erreichen können.

[Ist also eventuell mein Internet-Provider Schuld?]

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?

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

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.

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 ...

[Und trotzdem haben wir leider keine Lösung gefunden!]

@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?

[Dies steht da jetzt 2x drin!]

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!