Messages

Auf der pfSense gibt es leider keinen Eintrag für Selfhost, deswegen kann ich es nicht nachvollziehen.

Ich habe aber mal einen TXT-Record angelegt und anschließend über den Webbrowser die URL mit entsprechenden Daten abgesetzt, funktioniert!

https://selfhost.de/cgi-bin/api.pl?username=Benutzername&password=Passwort&rid=3304322&content=0815

Benutzername und Passwort vom Selfhost Account-Login (https://kirk.selfhost.de/cgi-bin/selfhost?p=account), nicht die vom DynDNS Account!

Das mit der API ist völlig an mir vorbeigegangen, man findet dazu auch kaum etwas. Ich habe es noch nicht getestet, aber das könnte theoretisch funktionieren. Praktisch vermutlich nicht umsetzbar, da das ACME Plugin keine Möglichkeit dazu anbietet, zumindest nicht bei meiner pfSense.

Automatisiert Wildcard Zertifikate unter Selfhost zu erstellen funktioniert nicht. Dazu wäre eine entsprechende API notwendig die Selfhost nicht anbietet.

Manuell funktioniert es, wenn beim Erstellen des Wildcard Zertifikates der angezeigte Token als TXT-Record im Selfhost DNS hinterlegt wird. Dieser Token ändert sich aber bei jeder Erstellung, deswegen geht das nur manuell und nicht automatisch.

Diese Prozedur wäre mir aber alle 2-3 Monate zu umständlich.

@Helge: Ist hier wirklich IPv6 ICMP mit allen Submodi vollständig an und vom LAN erlaubt? Oder nur einzelne Submodi wie echo-reply etc.? Nur interessehalber :)

Ja,  IPV6 ICMP ist komplett in beiden Richtungen erlaubt.

Da es nur wenige Webseiten betrifft, würde ich doch von einer Fehlkonfiguration der Gegenstelle ausgehen.  Vermutlich werden da die IPV6 ICMP vollständig, oder zum Teil blockiert.

Nachtrag
Eine Webseite die nicht funktionierte und ich noch in Erinnerung hatte, funktioniert jetzt auch ohne Veränderung des MTU Standard Wertes am LAN Interface. Scheint also doch an einer Fehlkonfiguration der Gegenstelle gelegen zu haben.

Ich sollte wohl Fehler nicht immer bei mir selbst suchen ;).

Bei der von Lumpy genannten Webseite webmail.tu-clausthal.de besteht das Problem weiterhin. Wenn jemand Lust und Zeit hat, kann ja mal mit Wireshark schauen, ob der Webserver auf IPV6 ICMP Pakete korrekt antwortet.

Hi Droppie391,

IPV6 ICMP Pakete sind in beiden Richtungen in der Firewall erlaubt. Der "Fehler" tritt nur bei sehr wenigen Webseiten auf, deswegen wird es vermutlich nicht bemerkt. Es kann natürlich auch an einer Fehlkonfiguration am Webserver der Gegenstelle liegen, der das zurücksenden von IPV6 ICMP Pakete verhindert. Sowas müsste man mal mit Wireshark prüfen.

Hi JeGr,

es geht ausschließlich um Dual Stack Verbindungen, die eine Änderung des MTU Wertes am WAN Interfaces erfordern. Das betrifft alle Internet Anbieter, die einen abweichenden Standard MTU Wert von 1500 benötigen, wie es z.B. bei einer PPPoE Einwahl der Fall ist. Dieser WAN MTU Wert muss zwingend auch am LAN Interface (abweichend vom Standard 1500 MTU Wert) eingetragen werden, da sonst einige Webseiten nicht mehr erreichbar sind, wenn IPv6 Vorrang hat.

Das wurde mit verschiedener Hardware, OpnSense / PFSense und Providern getestet und ist immer reproduzierbar.

Der Workaround funktioniert, ist aber nicht korrekt und muss m.M.n. ein Bug in FreeBSD sein.

Hi Lumpy, freut mich das es bei dir auch so funktioniert :).

Ich habe das mit verschiedener Hardware unter OpnSense / PFSense getestet, überall das gleiche Verhalten.
Auch eine Anfrage im PFSense Forum blieb dazu unbeantwortet. Daher gehe ich von einem Bug in FreeBSD aus. Mich wundert es nur, dass es bisher kaum einer bemerkt hat. Diesen Bug beobachte ich schon seit FreeBSD 10 und ist auch in der aktuellen Version 11 vorhanden.

Das gleich Verhalten hatte ich auch bei PFSense. Ändere zum Test mal deinen MTU Wert vom LAN Interface auf den gleichen Wert wie du ihn unter dem WAN Interface eingetragen hast. Normalerweise bleibt dieses Feld frei und damit hat das LAN den Standard MTU Wert von 1500.

Bringt aber nichts, wenn man wie ich, zur Fehlereingrenzung die alten Einträge löscht und neu anlegt. Dann hat man nicht die Möglichkeit die Zertifizierungsstelle auszuwählen.

Vermutlich funktioniert das nur wenn man die alten Einträge lässt und OpnSense gleich neu startet.

Ich habe das Vertrauen in OpnSense verloren. Es wird nur am "Unterbau" geschraubt, aber die ganzen Fehler werden nicht angegangen. Im Gegenteil, es kommen zu jedem Update neue dazu. Ich bin in der produktiven Umgebung zurück zu PFSense und habe nur noch in der Testumgebung eine OpnSense. Ich hatte es einfach satt jede Nacht von Icinga raus geklingelt zu werden, nur weil neue Updates eingespielt wurden, nach denen wieder was nicht funktioniert.

Meiner Meinung nach müsste eine grundlegende Entscheidung getroffen werden. Einstellung aller Neuerungen an OpnSense und nur noch Bugs bearbeiten. Ich glaube, damit hat man gut 2 Jahre zu tun.

Mir persönlich ist es doch egal ob FreeBSD11 oder PHP7 läuft, entscheidend ist doch was "hinten raus kommt" und da kommt mir OpnSense langsam wie ein Trümmerhaufen vor.

Hallo zusammen,

seit der Aktualisierung auf OpnSense 17.1.6 funktioniert Xauth nicht mehr. Das Anlegen eines neuen Phase 1 Vorschlag scheitert mit der Meldung "Die folgenden Eingabefehler wurden entdeckt: Das Feld Zertifizierungsstelle ist erforderlich" s.Bild. Würde ich ja gerne angeben, aber dieses Feld verschwindet wenn man die Authentifizierung auf Mutual RSA  + Xauth stellt.

Des weiteren werden die Firewallregeln vom IPSec Interface ignoriert. Nur eine any -> any Freischaltung funktioniert.

Bei mir das gleiche, seit dem Update auf 17.1.6 funktioniert auch XAUTH bei IPSec nicht mehr.

Da aber die Firewallregeln von IPSec immer noch nicht funktionieren, habe ich mich zwischenzeitlich für eine andere Lösung entschieden.

Ich hatte mal das gleiche Problem gehabt. Die exportierte Konfiguration war von einer etwas aktuelleren Opnsense Version. Nachdem ich auf die gleiche Version aktualisiert habe, wurden die Seiten korrekt angezeigt.

Handelt es sich bei dir um die aktuelle Version 17.1 und verlief die Installation auf dem Board reibungslos?

Wenn ja, hast du auch schon einen Reboot gemacht?

Hi JeGr,

man muss ja keine Firewallregeln für den Zugriff vom LAN zur DMZ haben, aber man kann es machen wenn es notwendig ist. Auch spielt es kaum eine Rolle (bin jetzt lieber etwas vorsichtiger  ;) ) wenn Geräte im LAN stehen und rein Sicherheitstechnisch der Super-GAU sind, aber keine Internetverbindung besitzen. Dafür ist nun mal die Firewall da, um dafür zu sorgen. Auch kann man im LAN mehrere Bereiche mit unterschiedlichen Sicherheitsanforderungen definieren und die  per Router / Firewall von einander trennen.

Eine DMZ kenne ich nur als einen Bereich, der einen geringeren bzw. gar keinen Schutzbedarf hat. Dienste die aus dem Internet erreichbar sein müssen, können nicht zu 100% abgesichert werden. Deswegen stehen Webserver oder andere Dienste in der DMZ, um den Zugriff vom Internet aus zu gewährleisten, aber das eigentliche LAN nicht zu gefährden.

Hi Oxy,

vielleicht sollte man erstmal grundsätzliches klären. In eine DMZ gehören Server die vom bösen Internet und Intranet aus erreichbar sein sollen. Dazu werden Portweiterleitungen und Firewalleinstellungen zu den jeweiligen Servern in die DMZ geöffnet.

Eine Kamera die vom Internet aus erreichbar sein soll, gehört demzufolge in die DMZ. Da die Kamera aber nur über VPN aus erreichbar sein soll, ist das nicht unbedingt notwendig. Diese kann sich auch im LAN befinden, darf natürlich keine zutreffenden Firewall Regeln besitzen.Damit kann diese nicht auf das Internet zugreifen, vom Internet ist sie auch nicht erreichbar (außer per VPN). Deine Vorsicht mit dem VPNs verstehe ich nicht, genau für sowas wurde es entwickelt. Man kann sich streiten ob IPSec richtig konfiguriert etwas sicherer ist wie OpenVPN, aber grundsätzlich kann man beides als ziemlich sicher ansehen.

Das Thema UDP "hole punching" hat an und für sich nichts mit einer DMZ zu tun, sondern ist generell vorhanden, sobald man UDP Ports vom Intranet zum Internet öffnet.