Messages

Hm....ich danke dir.

Und natürlich auch den anderen Kollegen.

@ lfirewall1243

Vielen Dank für den Lösungsvorschlag. Aber mich interessiert auch die Fehlermeldung im Report. Vielleicht kann Franco auch was dazu sagen.

@ Gauss23:
Danke für den Tipp:

Hast du eine Beispielkonfiguration, an der ich mich orientieren kann?

Okay. Ich versuche es noch einmal zu erklären...
Ich will von draussen mit einem Domain- Namen auf meine Nextcloud  in der DMZ zugreifen. Ohne VPN- Client. Ganz normal über den Webbrowser. Die IP- Adresse des Mulvad- Servers ist gesynct mit dem Domain- Namen.
Um es in einem Satz zu sagen:
Ich will von überall über einen Webbrowser auf meine Ressourcen in der DMZ zugreifen. Nur geht das nicht über eine normale LAN- Verbindung, sondern über einen Wireguard- Tunnel mit einem Mullvad- Server als GW.
Einen Post darüber gibt es hier als Beispiel:

https://forum.opnsense.org/index.php?topic=18013

Er hat das gleiche Problem. Vielleicht hilft dir das, um meine Lage zu begreifen.

Outbound ist alles eingestellt und funktioniert auch. Ich will von extern auf die den Webserver in der DMZ zugreifen. Und dieser externe Zugriff(443) soll weiter geleitet werden.

HIer habe ich noch einen Eintrag gefunden:

https://github.com/opnsense/core/issues/4389

Aber mich interessiert auch die Fehlermeldung im Crash-Report. Was hat es damit auf sich?

Die FW-Regel wird nach mkeines Wissens automatisch bei der Erstellung der Portforwarding erstellt. Aber das ist für mich nicht die Kernfrage.

[PHP Warning: implode(): Invalid arguments passed in /usr/local/www/firewall_nat_edit.php on line 216]

Hallo zusammen,

ich habe schon viele Foren durchforstet und auch einige Posts zu diesem Thema gefunden. Trotzdem schaffe ich es nicht, den HTTPS- Port durch den Wireguard- Tunnel in die DMZ zu forwarden.
Folgendes Szenario:
Ich möchte eine Provate- Cloud in der DMZ mit Nextcloud einrichten. Mein gesamter Traffic wird durch ein Wireguard- VPN getunnelt. mei Provider ist Mullvad. Die Sense ist als dynDNS- Client eingerichtet. Die Namensauflösunf gekoppelt mit dem Mullvad- Server funktioniert. So weit, so gut.
Ich habe gemäß der Anleitung in diesem Post die Portweiterleitung eingerichtet:

https://forum.opnsense.org/index.php?topic=13316.0

Der Kollege hatte aber auch das gleiche Problem wie ich.

Es gab noch andere Beiträge zu dieser Problematik. Kann OPNsense nicht mit den Mullvad- Servern?
Noch ein Indiz ist, wenn ich das Forwarding aktiviere, egal mit welcher Konfig, wird vom Reporter ein Bericht erstellt mit dem Eintrag:

PHP Warning:  implode(): Invalid arguments passed in /usr/local/www/firewall_nat_edit.php on line 216

Ich bin jetzt auch nicht der FreeBSD- Spezi, daher kann ich mit dieser Meldung erst einmal nix anfangen.

Gibt es hier bereits einen Lösungsansatz?

Vielen Dank im Voraus.

Grüße

Mario

2. nutz doch monitoring tools wie zabbix oder ähnliche ein

Vielen Dank, aber wenn ich Monitoring haben wollte, hätte ich es schon längst eingebaut.
Mein Wunsch wäre, es auf dem Dashbord zu haben, denn dafür ist es ja da. Es gibt ja auch ein Gateway- Widget, wo man den Status direkt sehen kann.

Aber vielleicht kommt es in den späteren Versionen. Trotzdem vielen Dank an alle.

Trotzdem ist der Vorschlag von Gauss23 nicht schlecht und käme auch meinen Vorstellungen sehr nahe.

würde mich persönlich stören, da meine clients sich sehr selten im vpn befinden (1 x im monat oder weniger)

Nun,es betrifft ja nur das Wigdet und man muss es ja nicht installieren.

Der Hintergedanke ist:
Mein gesamter Traffic im internen LAN läuft über ein Wireguard-VPN. Vor ein paar Tagen hatte ich aus dem Nichts heraus plötzlich kein Internet mehr. Man arbeitet dann natürlich das übliche Procedere ab, um das Problem zu finden. Es hat sich dann herausgestellt, dass der VPN- Server offline war.
Ich denke, ihr könnt mir folgen, warum ich diese Frage gestellt habe.

Danke erstmal für die Antwort.

Hallo zusammen,

wäre es möglich, hier auch ein optisches Signal einzubauen? So würde man direkt erkennen, ob der VPN- Server noch online ist. Bisher sieht man ja nur den Zeitpunkt des letzten Handshake.
Das erleichtert auch das Troubleshooting.

Dank für die Info.

Nun, im Endeffekt muss jeder für sich entscheiden, was für seine Umgebung die beste Lösung ist. Aber es ist positiv, auch mal mehrere Varianten hier zu erfahren.

Hallo zusammen,

interessantes Thema....
Meine Frage ist, wo das Problem ist, hier doppeltes NAT zu machen? Ich habe seit fast 2 Jahren die gleiche Konfig wie Meschmesch und bisher keine jeglichen Probleme feststellen können. Auch nicht in der Performance.

Der einzige Unterschied ist, dass  die Mac-Adresse von der Sense auf der Fritzbox reserviert ist, damit sie immer die gleiche IP bekommt. Der Vorteil dieser Konfig ist, dass man ein "Hintertürchen" hat, falls die Sense (aus welchen Gründen auch immer) kein Internet mehr aufbaut.
So kannst man schnell via Fritzbox ins WAN, hast doppelte FW- Funktionalität und erleichtert das Troubleshooting.

Danke für die Info.