117471
25.05.2018, aktualisiert um 14:08:37 Uhr
2027
14
0
PfSense: GUI Fehler sobald lokales GW vorhanden ist
Hallo,
folgenden Text habe ich auch im pfSense Forum gepostet. Aber da ich ja hier über den Fehler gestolpert bin, dachte ich, ich poste es hier auch noch einmal.
in meinem Beispiel-Szenario habe ich eine pfSense 2.4.3, die ein QSC und ein Telekom Gateway kennt und im Failover-Betrieb nutzt.
Die zusätzliche Anforderung lautet, das Netz 192.168.130.0/24 über ein Gateway anzusprechen, dass bereits im LAN residiert.
Dazu habe ich zuerst ein weiteres Gateway angelegt.
Den Abschnitt mit der statischen Route lasse ich jetzt mal weg, da irrelevant. Anzumerken wäre aber, dass es problemlos funktioniert.
Warum schreibe ich dann überhaupt diesen Beitrag?
Nun, wenn das Gateway 10.10.10.160 nicht angelegt bzw. nicht aktiv ist und ich eine neue übergreifende Firewallregel erstellen möchte, gelange ich "gleich als Erstes" in den gewohnten Dialog:
Wenn das Gateway aktiv ist, dann gelange ich beim Anlegen einer übergreifenden Regel (natürlich) in den gleichen Dialog. Nur sieht der dieses Mal etwas anders aus:
Ihr seht - der Abschnitt mit den erweiterten Optionen wird sofort geöffnet dargestellt. Auch sind hier ein paar Dinge anzumerken:
Inzwischen bin ich so weit zu glauben, dass es sich um einen Betriebssystemfehler handelt. Ein Update auf 2.4.3_1 schafft keine Abhilfe. Das Problem ist hardwareunabhängig und mit einer "frischen" Installation reproduzierbar.
Gruß,
Jörg
folgenden Text habe ich auch im pfSense Forum gepostet. Aber da ich ja hier über den Fehler gestolpert bin, dachte ich, ich poste es hier auch noch einmal.
in meinem Beispiel-Szenario habe ich eine pfSense 2.4.3, die ein QSC und ein Telekom Gateway kennt und im Failover-Betrieb nutzt.
Die zusätzliche Anforderung lautet, das Netz 192.168.130.0/24 über ein Gateway anzusprechen, dass bereits im LAN residiert.
Dazu habe ich zuerst ein weiteres Gateway angelegt.
Den Abschnitt mit der statischen Route lasse ich jetzt mal weg, da irrelevant. Anzumerken wäre aber, dass es problemlos funktioniert.
Warum schreibe ich dann überhaupt diesen Beitrag?
Nun, wenn das Gateway 10.10.10.160 nicht angelegt bzw. nicht aktiv ist und ich eine neue übergreifende Firewallregel erstellen möchte, gelange ich "gleich als Erstes" in den gewohnten Dialog:
Wenn das Gateway aktiv ist, dann gelange ich beim Anlegen einer übergreifenden Regel (natürlich) in den gleichen Dialog. Nur sieht der dieses Mal etwas anders aus:
Ihr seht - der Abschnitt mit den erweiterten Optionen wird sofort geöffnet dargestellt. Auch sind hier ein paar Dinge anzumerken:
- Wenn ich unter "Source" das LAN net auswähle, speichere und erneut öffne, dann wird in dem Eingabefeld rechts daneben das Wort "lan" geschrieben und ich kann weiterhin ein Subnetz auswählen. Normalerweise werden das Eingabefeld und das Subnetz dann ausgegraut dargestellt.
- Der Button "Display Advanced" im Abschnitt "Source" hat keine Funktion
- Der Button "Display Advanced" im Abschnitt "Extra Options" reagiert nicht auf den ersten Klick, beim zweiten Klick schließt er die Optionen
- Ich kann in den erweiterten Optionen kein Gateway auswählen (so bin ich überhaupt erst darauf aufmerksam geworden)
Inzwischen bin ich so weit zu glauben, dass es sich um einen Betriebssystemfehler handelt. Ein Update auf 2.4.3_1 schafft keine Abhilfe. Das Problem ist hardwareunabhängig und mit einer "frischen" Installation reproduzierbar.
Gruß,
Jörg
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 375075
Url: https://administrator.de/forum/pfsense-gui-fehler-sobald-lokales-gw-vorhanden-ist-375075.html
Ausgedruckt am: 28.04.2025 um 05:04 Uhr
14 Kommentare
Neuester Kommentar
Den Abschnitt mit der statischen Route lasse ich jetzt mal weg, da irrelevant.
Nein, keinesfalls ! Wie kommst du darauf ? Ohne das du dort eine statische Route definierst kann das doch logischerweise nicht klappen.Dort muss eine Route:
Zielnetz: 192.168.130.0, Maske: 255.255.255.0, Gateway: 10.10.10.160 <lancom_gw>
eingerichtet sein !
Ebenso natürlich auf den Lancoms eine Route das die das 10.10.10.0er /24 Netz via der VPN Verbindung routen (Rückroute)
Ohne das gehts nicht.
dass es problemlos funktioniert.
Gut dann hast du diese Routen gesetzt. Das solltest du dann aber nicht als irrelevant bezeichnen und die Forums Community verwirren. 
Wir sind aber mal nachsichtig, weil Freitag heute. 
Wenn du eine statische Regel einrichtest, was ja der Normalfall bei einer Firewall ist, dann ist es vollkommen wumpe ob das Gateway aktiv ist oder nicht.
Die Firewall merkt ja so oder so nie ob diese IP des Lancom erreichbar ist oder nicht, denn du hast ja das Gateway Monitoring (zyklischer Ping ob die IP noch "lebt") deaktiviert. Generell ja auch richtig wenn man keine automatisierte Funktion mit der Erreichbarkeit dieser IP aktiviert hat.
Die generelle Frage die sich stellt ob du lokalen 10.10.10er Traffic sinnfrei auch über die Firewall schicken willst ??
Normal macht man das nicht und fackelt den lokal ab, denn warum sollte die FW noch als Durchlauferhitzer dienen ?
Man setzt deshalb den entsprechenden Haken in den Advanced Settings:
Warum schreibe ich dann überhaupt diesen Beitrag?
Gute Frage....versteht man auch nicht wirklich warum du das machst. Oder liegt es am Freitag ? 
dass es sich um einen Betriebssystemfehler handelt.
Nein, daran das du Floating Rules benutzt !
Hallo,
Du hast meinen Beitrag nicht verstanden.
Es geht darum, dass die GUI nicht mehr funktioniert sobald man das Gateway einrichtet.
Um dieses Problem aufzuzeigen, ist das mit der Route irrelevant.
Wie gesagt - ich habe natürlich auch die Route gesetzt und das Routing funktioniert fehlerfrei. Das hatte ich jetzt nur wegen der Übersichtlichkeit weggelassen, da das Problem auch ohne die Route auftritt.
Es geht lediglich darum, dass das Vorhandensein des LAN-seitigen Gateways das Webinterface durcheinanderwirbelt - was sich dann zum Beispiel(!) an den Floating Rules zeigt. Eventuell sind auch weitere Teile der GUI betroffen.
Ich habe lediglich gezeigt, wie man die Darstellungsfehler provoziert. Die Konfiguration ist korrekt, mein Beitrag ist aber unvollständig und die Reproduktion des Fehlers reduziert.
Insofern behalte deinen Freitagsfisch doch bitte für dich.
Über weitere (konstruktive) Antworten bin ich dankbar.
Gruß,
Jörg
Du hast meinen Beitrag nicht verstanden.
Es geht darum, dass die GUI nicht mehr funktioniert sobald man das Gateway einrichtet.
Um dieses Problem aufzuzeigen, ist das mit der Route irrelevant.
Wie gesagt - ich habe natürlich auch die Route gesetzt und das Routing funktioniert fehlerfrei. Das hatte ich jetzt nur wegen der Übersichtlichkeit weggelassen, da das Problem auch ohne die Route auftritt.
Es geht lediglich darum, dass das Vorhandensein des LAN-seitigen Gateways das Webinterface durcheinanderwirbelt - was sich dann zum Beispiel(!) an den Floating Rules zeigt. Eventuell sind auch weitere Teile der GUI betroffen.
Ich habe lediglich gezeigt, wie man die Darstellungsfehler provoziert. Die Konfiguration ist korrekt, mein Beitrag ist aber unvollständig und die Reproduktion des Fehlers reduziert.
Insofern behalte deinen Freitagsfisch doch bitte für dich.
Über weitere (konstruktive) Antworten bin ich dankbar.
Gruß,
Jörg
Du hast meinen Beitrag nicht verstanden.
OK, sorry. Aber vielleicht bin ich da nicht der Einzige Es geht darum, dass die GUI nicht mehr funktioniert sobald man das Gateway einrichtet.
OK, teste ich im Labor. Halte ich für falsch aber Versuch macht klug... 
Um dieses Problem aufzuzeigen, ist das mit der Route irrelevant.
Das ist richtig !Insofern behalte deinen Freitagsfisch doch bitte für dich.
Ich lasse ihn nochmal stehen und warte mal ab was der Test auf einem APU Board mit aktueller Firmware ergibt !!Feedback kommt...
Hallo,
vielen lieben Dank, das wäre mir eine große Hilfe
Ich habe es auf zwei unterschiedlichen APU getestet und es hängt bei mir definitiv damit zusammen, ob ein Gateway aktiv ist, dass im LAN liegt.
Im Anschluss daran hätte ich tatsächlich noch eine Frage bezüglich des o.G. Szenarios. Ich würde da aber gerne Schritt für Schritt vorgehen
Gruß,
Jörg
vielen lieben Dank, das wäre mir eine große Hilfe
Ich habe es auf zwei unterschiedlichen APU getestet und es hängt bei mir definitiv damit zusammen, ob ein Gateway aktiv ist, dass im LAN liegt.
Im Anschluss daran hätte ich tatsächlich noch eine Frage bezüglich des o.G. Szenarios. Ich würde da aber gerne Schritt für Schritt vorgehen
Gruß,
Jörg
Tja, was soll ich sagen...der Fisch muss wie bereits befürchtet leider oben verbleiben ! 
Der Reihe nach...
1.) Testaufbau:
Einfaches Design ohne Schnickschnack, pfSense = Default IP Netz im LAN, RasPi agiert als Router (IPv4 Forwarding aktiv, feste IP .101)), 10.10.10er Netz mit 24 Bit Prefix hinterm RasPi.
2.) RasPi als Gateway anlegen:
Übersicht:
3.) Statische Route aufs 10er Netz eintragen:
Übersicht:
Ergebnis:
Leider müssen wir damit also, wie erwartet, deine Vermutung, das es ein Bug ist, ins Reich der Märchen verbannen.
Ist aber auch klar.
Stell dir mal für so ein gravierender Bug wäre nicht innerhalb von Sekunden der pfSense Community aufgefallen. Das wäre eher ziemlich unwahrscheinlich. Du hast also bei dir in der Konfig irgendwas verbaselt...
So, nun bist du wieder dran !
Der Reihe nach...
1.) Testaufbau:
Einfaches Design ohne Schnickschnack, pfSense = Default IP Netz im LAN, RasPi agiert als Router (IPv4 Forwarding aktiv, feste IP .101)), 10.10.10er Netz mit 24 Bit Prefix hinterm RasPi.
2.) RasPi als Gateway anlegen:
3.) Statische Route aufs 10er Netz eintragen:
Ergebnis:
- Setup GUI aus dem LAN Segment 192.168.1.0 lässt sich durchgehend fehlerlos erreichen...
- MIT eingeschaltetem RasPi Router
- Mit ausgeschaltetem RasPi Router
- Mit abgestöpseltem, also physisch komplett entfernten, RasPi Router
- Aus dem 10.10.10er Netz
Leider müssen wir damit also, wie erwartet, deine Vermutung, das es ein Bug ist, ins Reich der Märchen verbannen.
Ist aber auch klar.
Stell dir mal für so ein gravierender Bug wäre nicht innerhalb von Sekunden der pfSense Community aufgefallen. Das wäre eher ziemlich unwahrscheinlich. Du hast also bei dir in der Konfig irgendwas verbaselt...
So, nun bist du wieder dran !
Hallo,
krass - bei mir tritt es sogar in einer Hyper-V VM "from scratch" auf (WAN auf DHCP und lediglich den Assisten "durchgeeiert").
Frisch installiert -> Webinterface funktioniert
Gateway angelegt und aktiviert -> Webinterface kaputt
Gateway deaktiviert -> Webinterface geht wieder
Aber vielleicht findet sich ja noch jemand, der das Testen und zur Eingrenzung der Ursache beitragen kann. Ich meine - ich kann es ja beweisen und da der Assistent eine grundsätzlich funktionierende Grundkofiguration abliefern sollte, wäre die Ursache schon "irgendwie interessant". Oder nicht?
Meine Kollegen konnten das 100% reproduzieren.
Danke für deine Beiträge.
Gruß,
Jörg
Edit: Es geht nicht um die Routingfunktion. Dass die funktioniert habe ich nie bestritten. Es geht darum, dass der Abschnitt zum Anlegen einer floating Rule fehlerhaft dargestellt wird, sobald das Gateway aktiv ist. Dein Beitrag liest sich so, dass Du das Routing überprüft hast. Das ist jedoch unbestritten...
krass - bei mir tritt es sogar in einer Hyper-V VM "from scratch" auf (WAN auf DHCP und lediglich den Assisten "durchgeeiert").
Frisch installiert -> Webinterface funktioniert
Gateway angelegt und aktiviert -> Webinterface kaputt
Gateway deaktiviert -> Webinterface geht wieder
Aber vielleicht findet sich ja noch jemand, der das Testen und zur Eingrenzung der Ursache beitragen kann. Ich meine - ich kann es ja beweisen und da der Assistent eine grundsätzlich funktionierende Grundkofiguration abliefern sollte, wäre die Ursache schon "irgendwie interessant". Oder nicht?
Meine Kollegen konnten das 100% reproduzieren.
Danke für deine Beiträge.
Gruß,
Jörg
Edit: Es geht nicht um die Routingfunktion. Dass die funktioniert habe ich nie bestritten. Es geht darum, dass der Abschnitt zum Anlegen einer floating Rule fehlerhaft dargestellt wird, sobald das Gateway aktiv ist. Dein Beitrag liest sich so, dass Du das Routing überprüft hast. Das ist jedoch unbestritten...
Da ist irgendwas faul in deinem Setup. Ich gebe dir gerne Remote Access auf die Labor pfSense hier dann kannst du das selber sehen.
Sie rennt auf einem dedizierten Blech, sprich APU Board.
Habe testweise nochmal eine zur pfSense gemachte Watchguard genommen in einer Default Konfig und statt des RasPis oben einen Mikrotik 2011 Router...
Gleiches Ergebnis....funktioniert fehlerlos !
Wie gesagt das ist eine absolute Basic Anwendung und banalstes IP Routing. Sollte das nicht klappen oder irgendwelche Probleme bereiten wäre das der weltweiten pfSense Community in Sekunden aufgefallen.
Und auch sonst...
Wenn man sich mal technisch fragt warum sollte das Webinterface nicht mehr erreichbar sein wenn man mit einem Client im lokalen LAN im Konfig GUI ist nur weil man einen Gateway IP konfiguriert hat, egal ob erreichbar oder nicht.
Das eine hat doch mit dem anderen nicht das Geringste zu tun und eine logische Erklärung gäbe es aus IP Sicht dafür auch nicht.
Die Konfig Web Session bzw. deren IP Traffic hat mit dem Gateway und Routing nicht das Geringste zu tun. Klar, denn sie ist ja im lokalen LAN Segment. Warum sollte sie also von irgendwelchen Gateway IPs beeinflusst werden ?
Ein logische Erklärung gibt es dafür nicht. Und...
Du siehst ja auch in der Praxis das es sauber und fehlerfrei funktioniert.
Vermutung ist das es irgendwas mit deiner Virtualisierung zu tun hat, das da irgendwelcher Mist passiert ist.
Das wäre der einzige Unterschied zw. den Test Setups.
Dein Fehler ist jedenfalls so in einem klassischen Umfeld de facto nicht nachzuvollziehen.
Teste es selber auf einer dedizierten Maschine, dann siehst du es sofort selber. Siehe oben !!
Das Thema Firewalls in VMs ist hier ja schon zur Genüge diskutiert worden, deshalb mal keinen Kommentar mehr dazu.
Sie rennt auf einem dedizierten Blech, sprich APU Board.
Meine Kollegen konnten das 100% reproduzieren.
Ich ebenfalls !Habe testweise nochmal eine zur pfSense gemachte Watchguard genommen in einer Default Konfig und statt des RasPis oben einen Mikrotik 2011 Router...
Gleiches Ergebnis....funktioniert fehlerlos !
Wie gesagt das ist eine absolute Basic Anwendung und banalstes IP Routing. Sollte das nicht klappen oder irgendwelche Probleme bereiten wäre das der weltweiten pfSense Community in Sekunden aufgefallen.
Und auch sonst...
Wenn man sich mal technisch fragt warum sollte das Webinterface nicht mehr erreichbar sein wenn man mit einem Client im lokalen LAN im Konfig GUI ist nur weil man einen Gateway IP konfiguriert hat, egal ob erreichbar oder nicht.
Das eine hat doch mit dem anderen nicht das Geringste zu tun und eine logische Erklärung gäbe es aus IP Sicht dafür auch nicht.
Die Konfig Web Session bzw. deren IP Traffic hat mit dem Gateway und Routing nicht das Geringste zu tun. Klar, denn sie ist ja im lokalen LAN Segment. Warum sollte sie also von irgendwelchen Gateway IPs beeinflusst werden ?
Ein logische Erklärung gibt es dafür nicht. Und...
Du siehst ja auch in der Praxis das es sauber und fehlerfrei funktioniert.
Vermutung ist das es irgendwas mit deiner Virtualisierung zu tun hat, das da irgendwelcher Mist passiert ist.
Das wäre der einzige Unterschied zw. den Test Setups.
Dein Fehler ist jedenfalls so in einem klassischen Umfeld de facto nicht nachzuvollziehen.
Teste es selber auf einer dedizierten Maschine, dann siehst du es sofort selber. Siehe oben !!
Das Thema Firewalls in VMs ist hier ja schon zur Genüge diskutiert worden, deshalb mal keinen Kommentar mehr dazu.
Hi FA-jka,
ich kann den "Fehler" in der GUI bei mir auch nicht reproduzieren.
Kannst du uns/mir mal eine backup.xml zur Verfügung stellen ?
Dann sollte es einfacher sein de Fehler zu sehen und die Ursache zu erkennen.
CH
P.S.
Wo hast du den Fehler im Forum geposted ? Ich kann die Frage dort nicht finden.
ich kann den "Fehler" in der GUI bei mir auch nicht reproduzieren.
Kannst du uns/mir mal eine backup.xml zur Verfügung stellen ?
Dann sollte es einfacher sein de Fehler zu sehen und die Ursache zu erkennen.
CH
P.S.
Wo hast du den Fehler im Forum geposted ? Ich kann die Frage dort nicht finden.
Hallo,
Hier ein Video: https://youtu.be/SZMXuhYt-E0
Ich beginne damit, dass ich den Abschnitt zum Anlegen einer "Floating Rule" fehlerfrei zeige.
Danach aktiviere ich das Gateway.
Wenn ich dann eine "Floating Rule" anlege, erhalte ich den im Video und im Screenshot oben gezeigten Darstellungsfehler.
Ich deaktiviere das Gateway wieder - danach kann ich wie gewohnt "Floating Rules" anlegen.
Das Problem tritt bei virtualisierten Firewalls genau so wie bei APU Boards auf. Insofern scheidet die Virtualisierung als Fehlerursache aus.
Für mich erweckt das den Eindruck, als wenn die Scripte zur Darstellung der GUI die Konfiguration der pfSense beim Aufruf in Echtzeit interpretieren und dabei über "irgend etwas" in Zusammenhang mit dem Gateway stolpern - was dann zu dem Darstellungsfehler führt.
Von einer vollständigen Veröffentlichung möchte ich, alleine schon aufgrund Aquis vorherrschendem, "recht agressiven" Ton Abstand nehmen. Die Konfiguration enthält auch sicherheitsrelevante Informationen (z.B. Zertifikate und die Passwörter). Ich werde hier als "unwissender Troll" dargestellt, mit "Fischen" bedacht und dass schafft kein Vertrauen.
Wie gesagt - mit der oben dargestellten Konfiguration ist das 1:1 auf einer "bare metal from scratch" installierten pfSense nachvollziehbar. Für mich ist das jetzt auch nicht so dramatisch, da ich den Fehler kenne und diverse Alternativen habe. Ich habe gedacht, ich könnte die "Community" dieser Firewall unterstützen, indem ich noch ein bisschen an der Ursache herumforsche und dann einen konkreten Bugreport schreibe. Allerdings habe ich gerade das Gefühl, mich - wieder einmal - in einer emotional geführten "Dauerdiskussion" zu verlaufen. Ich ärgere mich über die Zeit, die ich mit dieser unnötigen Auseinandersetzung verbracht habe.
Wer etwas inhaltliches dazu beitragen kann, darf sich hier natürlich gerne weiterhin äußern.
Gruß,
Jörg
Hier ein Video: https://youtu.be/SZMXuhYt-E0
Ich beginne damit, dass ich den Abschnitt zum Anlegen einer "Floating Rule" fehlerfrei zeige.
Danach aktiviere ich das Gateway.
Wenn ich dann eine "Floating Rule" anlege, erhalte ich den im Video und im Screenshot oben gezeigten Darstellungsfehler.
Ich deaktiviere das Gateway wieder - danach kann ich wie gewohnt "Floating Rules" anlegen.
Das Problem tritt bei virtualisierten Firewalls genau so wie bei APU Boards auf. Insofern scheidet die Virtualisierung als Fehlerursache aus.
Für mich erweckt das den Eindruck, als wenn die Scripte zur Darstellung der GUI die Konfiguration der pfSense beim Aufruf in Echtzeit interpretieren und dabei über "irgend etwas" in Zusammenhang mit dem Gateway stolpern - was dann zu dem Darstellungsfehler führt.
Kannst du uns/mir mal eine backup.xml zur Verfügung stellen ?
Von einer vollständigen Veröffentlichung möchte ich, alleine schon aufgrund Aquis vorherrschendem, "recht agressiven" Ton Abstand nehmen. Die Konfiguration enthält auch sicherheitsrelevante Informationen (z.B. Zertifikate und die Passwörter). Ich werde hier als "unwissender Troll" dargestellt, mit "Fischen" bedacht und dass schafft kein Vertrauen.
Wie gesagt - mit der oben dargestellten Konfiguration ist das 1:1 auf einer "bare metal from scratch" installierten pfSense nachvollziehbar. Für mich ist das jetzt auch nicht so dramatisch, da ich den Fehler kenne und diverse Alternativen habe. Ich habe gedacht, ich könnte die "Community" dieser Firewall unterstützen, indem ich noch ein bisschen an der Ursache herumforsche und dann einen konkreten Bugreport schreibe. Allerdings habe ich gerade das Gefühl, mich - wieder einmal - in einer emotional geführten "Dauerdiskussion" zu verlaufen. Ich ärgere mich über die Zeit, die ich mit dieser unnötigen Auseinandersetzung verbracht habe.
Wer etwas inhaltliches dazu beitragen kann, darf sich hier natürlich gerne weiterhin äußern.
Gruß,
Jörg
Hallo,
Ein weiterer Unterschied ist, dass Du kein MultiWAN konfiguriert hast.
Und ich habe das Gefühl, als wenn Du dich auf die Funktionalität des Routings versteift hast.
Es geht wie gesagt um die (optische) Darstellung der Bereiches zum Anlegen einer neuen Floating Rule. Dass dieser Fehler existiert, beweise ich anhand eines Screenshots und eines Videos.
Getestet mit Firefox und dem Internet Explorer.
Ich habe es wie gesagt auch "in Hardware" darstellen können. In der Virtualisierungslösung habe ich es lediglich noch einmal zur Überprüfung "from scratch" nachvollzogen. Auch dafür hätte ich ein Board nehmen können, was aber keinen Unterschied gemacht hätte. Wäre es ein reiner Virtualisierungsfehler, gäbe es auf der APU ja keine Probleme...
Gruß,
Jörg
Ein weiterer Unterschied ist, dass Du kein MultiWAN konfiguriert hast.
Und ich habe das Gefühl, als wenn Du dich auf die Funktionalität des Routings versteift hast.
Es geht wie gesagt um die (optische) Darstellung der Bereiches zum Anlegen einer neuen Floating Rule. Dass dieser Fehler existiert, beweise ich anhand eines Screenshots und eines Videos.
Getestet mit Firefox und dem Internet Explorer.
Das Thema Firewalls in VMs ist hier ja schon zur Genüge diskutiert worden, deshalb mal keinen Kommentar mehr dazu.
Ich habe es wie gesagt auch "in Hardware" darstellen können. In der Virtualisierungslösung habe ich es lediglich noch einmal zur Überprüfung "from scratch" nachvollzogen. Auch dafür hätte ich ein Board nehmen können, was aber keinen Unterschied gemacht hätte. Wäre es ein reiner Virtualisierungsfehler, gäbe es auf der APU ja keine Probleme...
Gruß,
Jörg
Hast du es mal mit "normalen" Regeln versucht anstatt der Floating Rules ?
Ist es dort auch reproduzierbar ?
Warum hängst du so an den Floating Rules, bzw. WAS nutzt du da spezifisches was klassische Regeln nicht können.
OK, das Look and Feel des Floating Rules GUI habe ich nach Einrichtung des Gateways nicht getestet.
Werde das aber gleich mal nachholen um zu sehen ob das reproduzierbar ist.
Ist es dort auch reproduzierbar ?
Warum hängst du so an den Floating Rules, bzw. WAS nutzt du da spezifisches was klassische Regeln nicht können.
OK, das Look and Feel des Floating Rules GUI habe ich nach Einrichtung des Gateways nicht getestet.
Werde das aber gleich mal nachholen um zu sehen ob das reproduzierbar ist.
Hallo,
ich habe den Fehler nur an der Stelle gefunden.
Ich habe wie gesagt eine andere Lösung konfiguriert. Es geht mir hier lediglich darum, den Fehler aufzuzeigen.
Der kann ja an anderer Stelle noch weitere, dramatischere Konsequenzen haben.
Gruß,
Jörg
ich habe den Fehler nur an der Stelle gefunden.
Ich habe wie gesagt eine andere Lösung konfiguriert. Es geht mir hier lediglich darum, den Fehler aufzuzeigen.
Der kann ja an anderer Stelle noch weitere, dramatischere Konsequenzen haben.
Gruß,
Jörg
Hallo,
ich habe mich nach gewisser Zeit noch einmal mit dem Thema beschäftigt.
Das Problem tritt dann auf, wenn die Beschreibung vom Gateway Anführungszeichen bzw. Plus-Zeichen enthält.
Wenn ich die Beschreibung lösche, funktioniert allles wie gewünscht.
Schade, dass der Umgangston hier dermaßen ekelhaft ist, dass man schlichtweg irgendwann die Muße verliert, derartige Dinge zu diskutieren. Ich hatte diesen Thread einigen Teilnehmern im pfSense und OPNsense Forum gezeigt und die waren schon ziemlich entsetzt, wie hier miteinander umgesprungen wird
Ich bin froh, dass ich den Fehler gefunden habe und dass meine Firewall ein Vierteljahr später endlich funktioniert
Gruß,
Jörg
ich habe mich nach gewisser Zeit noch einmal mit dem Thema beschäftigt.
Das Problem tritt dann auf, wenn die Beschreibung vom Gateway Anführungszeichen bzw. Plus-Zeichen enthält.
Wenn ich die Beschreibung
"LANCOM 1721+ VPN" im Serverraum West Schade, dass der Umgangston hier dermaßen ekelhaft ist, dass man schlichtweg irgendwann die Muße verliert, derartige Dinge zu diskutieren. Ich hatte diesen Thread einigen Teilnehmern im pfSense und OPNsense Forum gezeigt und die waren schon ziemlich entsetzt, wie hier miteinander umgesprungen wird
Ich bin froh, dass ich den Fehler gefunden habe und dass meine Firewall ein Vierteljahr später endlich funktioniert
Gruß,
Jörg
Auf sowas zu kommen ist auch nicht gerade einfach. Als Admin geht man ja davon meist nicht aus und verliert sich dann leider meist in Komplizierterem, da die Wechselwirkung bzw. Verhalten ja quasi nicht verhersehbar sind.
Aber gut das du das gefunden hast. Schafft man meistens ja nur wenn man mal wirklich alles ausprobiert was oft viel Zeit frisst die viele nicht haben oder investieren.
Letztlich bewahrheitet sich aber die goldene Regel nichts mit Sonderzeichen zu beschreiben oder zu benennen wie es auch bei unixoiden Betriebsystemen oft die Regel ist.
Sinnvoll wäre hier mal ein Bug Report bei pfSense oder im Forum. Das ist in der Tat reproduzierbar.
Case closed...
Aber gut das du das gefunden hast. Schafft man meistens ja nur wenn man mal wirklich alles ausprobiert was oft viel Zeit frisst die viele nicht haben oder investieren.
Letztlich bewahrheitet sich aber die goldene Regel nichts mit Sonderzeichen zu beschreiben oder zu benennen wie es auch bei unixoiden Betriebsystemen oft die Regel ist.
Sinnvoll wäre hier mal ein Bug Report bei pfSense oder im Forum. Das ist in der Tat reproduzierbar.
Case closed...
