25
PfSense: Block deny trotz Regel
Hallo miteinander,
ich hab gerade ein Problem das mich aufregt. Meine Firewall macht nicht das was ich will. Trotz erstellten und aktivierten Regel in der FW blockt er mir mit der Default deny den Traffic.
Ich setzte pfSense (2.4.4-RELEASE-p3) und das läuft auf einer APU3c4.
Die FW regeln fürs DMZ. Ich hab mir erstmal als Vorbild die Regeln von Netgate genommen.
Die FW Regeln fürs SERVER Netzwerk. Vom DMZ leicht abgewandelt.
Der eine Server ist ein Ubuntu 18.06 LTS. wenn ich dort jetzt Update & Upgrade mache, dann sieht man ja was passiert. Die FW fängt bei der DNS Abfrage an.
Dann hab ich einmal Google angepingt vom Server aus, nach einer Minute warten hab ich abgebrochen. Und dann hab ich die FW angepingt vom Server aus, wieder das selbe Spiel.
Also ich bin im moment ein wenig ratlos. Ich bin mit der pfSense eingentlich schon sehr zufrieden aber da zickt sie gerade total rum. Und ich denke verschluckt hat sie sich nicht weil ich hab sie eben Platt gemacht und dann mit Sicherung neu Aufgesetzt
MfG.
ich hab gerade ein Problem das mich aufregt. Meine Firewall macht nicht das was ich will. Trotz erstellten und aktivierten Regel in der FW blockt er mir mit der Default deny den Traffic.
Ich setzte pfSense (2.4.4-RELEASE-p3) und das läuft auf einer APU3c4.
Also ich bin im moment ein wenig ratlos. Ich bin mit der pfSense eingentlich schon sehr zufrieden aber da zickt sie gerade total rum. Und ich denke verschluckt hat sie sich nicht weil ich hab sie eben Platt gemacht und dann mit Sicherung neu Aufgesetzt
MfG.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 557583
Url: https://administrator.de/contentid/557583
Ausgedruckt am: 26.11.2024 um 00:11 Uhr
25 Kommentare
Neuester Kommentar
Hi,
Im Server Netzwerk hast du folgender Regeln:
1. erlaube aus dem Server Netzwerk DNS,NTP und ICMP auf die Firewall Adresse
2. Blocke alles, außer Kommunikation innerhalb des Servernetzwerkes.
-> Diese Regel ist wohl verkehrt, soll es vielleicht !RFC1918 sein ?
Daß die Server aus dem Server Netzwerk nicht nach außen kommunizieren dürfen ist durch diese Regel so eingetsellt.
Außerdem:
CH
Im Server Netzwerk hast du folgender Regeln:
1. erlaube aus dem Server Netzwerk DNS,NTP und ICMP auf die Firewall Adresse
2. Blocke alles, außer Kommunikation innerhalb des Servernetzwerkes.
-> Diese Regel ist wohl verkehrt, soll es vielleicht !RFC1918 sein ?
Daß die Server aus dem Server Netzwerk nicht nach außen kommunizieren dürfen ist durch diese Regel so eingetsellt.
Außerdem:
blockt er mir mit der Default deny den Traffic.
Ist doch richtig so ! deny = verbieten, allow = erlaubenCH
Hey,
Danke für die schnelle Antwort.
1. Ja genau, DNS, NTP und ICMP hab ich erlaubt.
2. Mit der Regel wollte ich bezwecken das er den Kompletten Traffic ausserhalb vom SERVER Netzwerk blocktbzw abweist aber innnerhalb der Traffic zugelassen ist. Einfach alles außer dem SERVER net abweisen.
MfG
Danke für die schnelle Antwort.
1. Ja genau, DNS, NTP und ICMP hab ich erlaubt.
2. Mit der Regel wollte ich bezwecken das er den Kompletten Traffic ausserhalb vom SERVER Netzwerk blocktbzw abweist aber innnerhalb der Traffic zugelassen ist. Einfach alles außer dem SERVER net abweisen.
Außerdem:
Ich hab aber ja eine regel erstellt das er es nicht soll. Weil bei der FW ist es ja so das "First match, wins!" sag ich mal so. Und wenn ich DNS aber erlaube und er mir DNS mit der default deny das dann sperrt...blockt er mir mit der Default deny den Traffic.
Ist doch richtig so ! deny = verbieten, allow = erlaubenMfG
Oha,
da hätte ich genauer schauen sollen.
Du hast bei DNS in den Regeln TCP/UDP eingetragen.
nehme nur UDP, dann sollte es funktionieren.
CH
da hätte ich genauer schauen sollen.
Du hast bei DNS in den Regeln TCP/UDP eingetragen.
nehme nur UDP, dann sollte es funktionieren.
CH
Vielen Dank für deinen Vorschlag, das werde ich heute Abend bzw morgen dann mal ausprobieren weil ich gerade auf dem Weg zur Arbeit bin.
Ich hatte TCP/UDP ausgewählt weil ich paar mal gelesen hab das er auch TCP nimmt bei DNS abfragen wenn sie zu groß sind. Deswegen auf Nummer sicher gehen.
Aber das erklärt dann aber nicht warum er mir ICMP auch blockt wenn ich auf IP pinge.
Ich hatte TCP/UDP ausgewählt weil ich paar mal gelesen hab das er auch TCP nimmt bei DNS abfragen wenn sie zu groß sind. Deswegen auf Nummer sicher gehen.
Aber das erklärt dann aber nicht warum er mir ICMP auch blockt wenn ich auf IP pinge.
Die DMZ Regel ist soweit OK wenn die DMZ FW Adresse keine RFC 1918 IP ist.
Ist sie das, dann wären die ersten 3 Regeln völlig überflüssig, denn mit der letzten Regel würden ja so oder so sämtlicher Traffic aus dem DMZ Netz auf sämtliche RFC181 IP Ziele erlaubt. Da wären die 3 ersten regeln dann völlig sinnfrei aber auch nicht falsch.
Beim Server Netz machst du vermutlich einen fatalen PEBKAC Denkfehler !
Lokaler LAN Traffic wird doch gar nicht über die Firewall abgewickelt sondern bleibt auch nur lokal. Logisch, denn er basiert ja nur auf Layer 2 und wenn die Firewall routet und nicht als Bridge arbeitet wie bei dir dann kann sie lokalen Traffic im Segment ja niemals "sehenh".
Die Firewall "sieht" logischerweise rein nur Traffic der aus einem ihrer Port Netze in andere Netze geht aber doch Ethernet Prinzipen bedingt niemals Traffic, der sich im lokalen Netz abspielt. Wozu auch ?
Wenn im okalen LAN ein Client mit dem Server redet macht er das doch direkt via Mac Adresse. Der schickt doch niemals seine IP Pakete quasi zuerst als "Durchlauferhitzer" zur Firewall und die dann wieder zurück ins gleiche lokale Netz zum Server !
Das passiert natürlich immer direkt zwischen Client und Server sofern die in einer gemeinsamen Layer 2 Domain sind, ohne jegliche Beteiligung eines Routers oder Firewall. Wie sollte also die FW diesen lokalen Traffic "sehen" ?? Kann sie physisch ja gar nicht !
Stell dir vor das wäre so wie du es dir vorstellst, dann könnte dein Client in einem einfachen, flachen Switch Netz ohne ein Gateway ja niemals mit einen Server kommunizieren. Da du ja selber weisst das dem nie so ist, hast du den besten Beweis das du mit deiner Denke hier völlig auf dem Holzweg bist !
Einfach mal genau nachdenken wie der IP Traffic Flow aussieht !
In sofern sind also deine Regeln an der Firewall, wenn "Server Address" die Alias IP eines Servers im "Server_LAN" ist, dann überflüssig. Sie können technisch nie greifen.
Ist allerdings der Alias eine andere IP, die nicht im Server Segment steht, dann wäre die Regel OK. Oder bedingt OK.
Falsch oder überflüssig wäre dann hier auch wieder die letzte Regel die alles blockt was nicht (das "!" negiert) ServerAdress ist. Sprich also alles was die ServerAddress im Ziel hat geht durch. Das würde dann wie oben schon die 3 ersten Regeln wieder konterkarieren bzw. inkludieren die dediziert ICMP, DNS und NTP haben.
Ein bischen logischer Murks sind diese Regeln also schon. Fragt sich was du genau erreichen willst und vor allem welche IP Adressierung deine Segmente haben ?!
Ist sie das, dann wären die ersten 3 Regeln völlig überflüssig, denn mit der letzten Regel würden ja so oder so sämtlicher Traffic aus dem DMZ Netz auf sämtliche RFC181 IP Ziele erlaubt. Da wären die 3 ersten regeln dann völlig sinnfrei aber auch nicht falsch.
Beim Server Netz machst du vermutlich einen fatalen PEBKAC Denkfehler !
Lokaler LAN Traffic wird doch gar nicht über die Firewall abgewickelt sondern bleibt auch nur lokal. Logisch, denn er basiert ja nur auf Layer 2 und wenn die Firewall routet und nicht als Bridge arbeitet wie bei dir dann kann sie lokalen Traffic im Segment ja niemals "sehenh".
Die Firewall "sieht" logischerweise rein nur Traffic der aus einem ihrer Port Netze in andere Netze geht aber doch Ethernet Prinzipen bedingt niemals Traffic, der sich im lokalen Netz abspielt. Wozu auch ?
Wenn im okalen LAN ein Client mit dem Server redet macht er das doch direkt via Mac Adresse. Der schickt doch niemals seine IP Pakete quasi zuerst als "Durchlauferhitzer" zur Firewall und die dann wieder zurück ins gleiche lokale Netz zum Server !
Das passiert natürlich immer direkt zwischen Client und Server sofern die in einer gemeinsamen Layer 2 Domain sind, ohne jegliche Beteiligung eines Routers oder Firewall. Wie sollte also die FW diesen lokalen Traffic "sehen" ?? Kann sie physisch ja gar nicht !
Stell dir vor das wäre so wie du es dir vorstellst, dann könnte dein Client in einem einfachen, flachen Switch Netz ohne ein Gateway ja niemals mit einen Server kommunizieren. Da du ja selber weisst das dem nie so ist, hast du den besten Beweis das du mit deiner Denke hier völlig auf dem Holzweg bist !
Einfach mal genau nachdenken wie der IP Traffic Flow aussieht !
In sofern sind also deine Regeln an der Firewall, wenn "Server Address" die Alias IP eines Servers im "Server_LAN" ist, dann überflüssig. Sie können technisch nie greifen.
Ist allerdings der Alias eine andere IP, die nicht im Server Segment steht, dann wäre die Regel OK. Oder bedingt OK.
Falsch oder überflüssig wäre dann hier auch wieder die letzte Regel die alles blockt was nicht (das "!" negiert) ServerAdress ist. Sprich also alles was die ServerAddress im Ziel hat geht durch. Das würde dann wie oben schon die 3 ersten Regeln wieder konterkarieren bzw. inkludieren die dediziert ICMP, DNS und NTP haben.
Ein bischen logischer Murks sind diese Regeln also schon. Fragt sich was du genau erreichen willst und vor allem welche IP Adressierung deine Segmente haben ?!
Moin
für mich sehen die ersten 3 Regeln wie Regeln aus, die gerne von FW als implizite Regeln angesehen werden.
Sprich: Wenn die FW DNS-Server/Proxy ist, erlaube ich aus dem Server-Segment DNS-Anfragen auf dem LAN-Interface. Ich deute mal, dass in den 3 Regeln "SERVER Address" ein unglücklicher Alias für das LAN-Interface ist. Ansonsten würde die Regel recht sinnbefreit sein.
Also 192.168.3.1 sind für mich das LAN-Interface, die 192.168.3.2 scheint ein Server zu sein.
Analog: 192.168.4.1 DMZ-Interface (Alias DMZ Address) und 192.168.4.2 irgendeine Büchse in der DMZ.
Wenn wir eine genaue Aufschlüsselung der angelegten Objekte bekommen ( also was steht hinter DMZ/SERVER LAN/ADDRESS) werden wir vermutlich einen Knoten finden
Gruß
Bernhard
für mich sehen die ersten 3 Regeln wie Regeln aus, die gerne von FW als implizite Regeln angesehen werden.
Sprich: Wenn die FW DNS-Server/Proxy ist, erlaube ich aus dem Server-Segment DNS-Anfragen auf dem LAN-Interface. Ich deute mal, dass in den 3 Regeln "SERVER Address" ein unglücklicher Alias für das LAN-Interface ist. Ansonsten würde die Regel recht sinnbefreit sein.
Also 192.168.3.1 sind für mich das LAN-Interface, die 192.168.3.2 scheint ein Server zu sein.
Analog: 192.168.4.1 DMZ-Interface (Alias DMZ Address) und 192.168.4.2 irgendeine Büchse in der DMZ.
Wenn wir eine genaue Aufschlüsselung der angelegten Objekte bekommen ( also was steht hinter DMZ/SERVER LAN/ADDRESS) werden wir vermutlich einen Knoten finden
Gruß
Bernhard
die gerne von FW als implizite Regeln angesehen werden.
Wäre möglich, gilt aber nicht auf der pfSense.Dort hat einzig nur das Default LAN Interface eine Schrotschussregel allow LAN_net -> any.
Alles andere oder neue Interfaces sind Firewall üblich komplett geblockt per Default.
dass in den 3 Regeln "SERVER Address" ein unglücklicher Alias für das LAN-Interface ist.
Hab ich auch gedacht im Nachhinein aber leider hat der TO das ziemlich verschwurbelt bezeichnet und nicht klargestellt ob der Alias eine externe IP ist oder eine im Server-LAN.Das Server LAN impliziert ja das sich darin dann auch Server Adressen befinden in sofern passt das dann wieder mit seinem Denkfehler. Deshalb oben auch die Einschränkung das das natürlich nur gilt wenn der Alias eine IP aus dem Server Segment ist und keine fremde, externe IP.
In der Tat eine irreführende Alias Bezeichnung.
Ansonsten würde die Regel recht sinnbefreit sein.
Richtig !Also 192.168.3.1 sind für mich das LAN-Interface, die 192.168.3.2 scheint ein Server zu sein.
Wenn dem so ist gilt die Sinnfreiheit, denn das sind lokale, Layer 2 IPs die niemals die Firewall "sehen" in einem Routing Design. Solche simplen IP Basics weiss der TO vermutlich auch selber, hat es aber wohl im Eifer des "FW Regelgefechts" schlicht übersehen ?!?Wenn wir eine genaue Aufschlüsselung der angelegten Objekte bekommen
So ist es... Aber vermutlich kommt der TO genau dann auch selber drauf wenn er mal in Ruhe drüber nachdenkt ?! So ist es... Aber vermutlich kommt der TO genau dann auch selber drauf wenn er mal in Ruhe drüber nachdenkt ?!
Wär doch Super - Hilfe zur Selbsthilfe
Vielen Dank für die vielen Antworten.
Der Alias "RFC1918" beinhaltet die privaten Netzwerke (192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8). Wie gesagt, ich hab die Regeln von der Netgate Seite übernommen. Die hatte ich oben auch verlinkt.
DMZ - 192.168.4.0/24
SERVER - 192.168.3.0/24
LAN - 192.168.0.0/24
Edit:
Ehe ich es vergesse, das ! bei der letzten SERVER und DMZ Regel bedeutet negiert. Und der Alias SERVER net hab ich nicht festgelegt sondern von der pfSense. Der sagt nix anderes aus wie die Adresse der pfSense in den Subnet
Der Alias "RFC1918" beinhaltet die privaten Netzwerke (192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8). Wie gesagt, ich hab die Regeln von der Netgate Seite übernommen. Die hatte ich oben auch verlinkt.
DMZ - 192.168.4.0/24
SERVER - 192.168.3.0/24
LAN - 192.168.0.0/24
Edit:
Ehe ich es vergesse, das ! bei der letzten SERVER und DMZ Regel bedeutet negiert. Und der Alias SERVER net hab ich nicht festgelegt sondern von der pfSense. Der sagt nix anderes aus wie die Adresse der pfSense in den Subnet
Beantwortet aber mit keinem Wort unsere obigen Fragen ! 
In den Regeln der NetGate Seite steht mit keinem einzigen Wort das die Regeln für lokalen LAN Traffic gelten !!
Was natürlich auch völliger Quatsch wäre. Warum ? Siehe oben !
In den Regeln der NetGate Seite steht mit keinem einzigen Wort das die Regeln für lokalen LAN Traffic gelten !!
Was natürlich auch völliger Quatsch wäre. Warum ? Siehe oben !
Wenn wir eine genaue Aufschlüsselung der angelegten Objekte bekommen ( also was steht hinter DMZ/SERVER LAN/ADDRESS) werden wir vermutlich einen Knoten finden
Die pfSense ist die 192.168.4.1 im DMZ Netz und 192.168.3.1 im Server Netz. Die 192.168.4.2 und die 192.168.3.2 ist der Ubuntu Server.Die letzte DMZ Regel soll dafür sein das der Server ins inet kann aber nicht untereinander kommunizieren kann. Und die letzte Regel bei SERVER soll dazu sein das intern in diesen subnet nur miteinander kommuniziert werden kann und nicht raus.
Ich hoffe ich hab jetzt keine Frage übersehen
Das heisst der Alias ""ServerAdresse" oben ist dann die 192.168.3.2 und das Server Netz dann das 192.168.3.0 /24 auch richtig ?
Dann gilt ja das oben bereits Gesagte ! Die Regeln am Server Netz Interface sind dann vollkommen sinnfrei.
Du kannst doch keinen internen Traffic des Server Netzes untereinander mit der Firewall filtern ! Wie sollte das gehen ? Die Firewall "sieht" diesen Traffic doch logischerweise physisch gar nicht ! Sie kann ihn doch nur dann "sehen" und damit auch filtern wenn er aus dem .3.0er Netz in andere Netze über sie geroutet wird. Sie ist wie gesagt kein Durchlauferhitzer für lokalen Traffic.
Alles andere weitere dazu steht oben !
Dann gilt ja das oben bereits Gesagte ! Die Regeln am Server Netz Interface sind dann vollkommen sinnfrei.
Du kannst doch keinen internen Traffic des Server Netzes untereinander mit der Firewall filtern ! Wie sollte das gehen ? Die Firewall "sieht" diesen Traffic doch logischerweise physisch gar nicht ! Sie kann ihn doch nur dann "sehen" und damit auch filtern wenn er aus dem .3.0er Netz in andere Netze über sie geroutet wird. Sie ist wie gesagt kein Durchlauferhitzer für lokalen Traffic.
Alles andere weitere dazu steht oben !
Guten Morgen,
Ne eben nicht. Server address ist eine Variable von pfSense. Hinter Server address verbirgt sich die pfSense mit ihrem Interface in diesen Subnet. In dem Fall ist das die 192.168.3.1
Edit:
Damit es nicht zu Missverständnissen kommt, anbei einmal alle Alise.
Und ein Screenshot von von der Regelerstellung wo man sieht was ich meine.
Als Extra, die Schnittstellen meiner pfSense.
MfG
Ne eben nicht. Server address ist eine Variable von pfSense. Hinter Server address verbirgt sich die pfSense mit ihrem Interface in diesen Subnet. In dem Fall ist das die 192.168.3.1
Edit:
Damit es nicht zu Missverständnissen kommt, anbei einmal alle Alise.
Und ein Screenshot von von der Regelerstellung wo man sieht was ich meine.
Als Extra, die Schnittstellen meiner pfSense.
MfG
Hinter Server address verbirgt sich die pfSense mit ihrem Interface in diesen Subnet.
Sorry du hast Recht ! Im Eifer des Gefechts übersehen bzw. kam durch die doppeldeutige Bezeichnung "Server" für dieses Netzsegment.Das Problem ist vermutlich das die die Anti Lockout Rule nicht deaktiviert hast im Setup ?! Kann das sein ?!
Dann greifen Regeln auf die lokalen Firewall Interface IPs nicht !
Hey aqui,
das ist eine gute frage, ich schau mal schnell ob das so ist.
Edit:
Ist bei mir deaktiviert.
das ist eine gute frage, ich schau mal schnell ob das so ist.
Edit:
OK, was genau ist denn dein Vorhaben aus dem Server Netz Segment ?
Das o.g. Regelwerk sieht dann so aus:
Nach den Regeln dürfte dann zwar ein DNS Request und Ping einzig auf das FW Interface durchgehen aber alles in den Rest des Netzwerkes ist blockiert. Das Server Netz ist also quasi vollständig isoliert. Klar das dann natürlich Google Ping und auch der Server Update scheitert.
Das o.g. Regelwerk sieht dann so aus:
- DNS, Ping und NTP von allen Absnder IPs aus dem Server Netz auf das FW Interface im Server Netz erlaubt
- Aller Zugriff aus dem Server Netz in alle anderen Netze geblockt. (Blockt alles was nicht (!) Server Netz ist)
Nach den Regeln dürfte dann zwar ein DNS Request und Ping einzig auf das FW Interface durchgehen aber alles in den Rest des Netzwerkes ist blockiert. Das Server Netz ist also quasi vollständig isoliert. Klar das dann natürlich Google Ping und auch der Server Update scheitert.
OK, was genau ist denn dein Vorhaben aus dem Server Netz Segment ?
Das o.g. Regelwerk sieht dann so aus:
Das o.g. Regelwerk sieht dann so aus:
- DNS, Ping und NTP von allen Absnder IPs aus dem Server Netz auf das FW Interface im Server Netz erlaubt
- Aller Zugriff aus dem Server Netz in alle anderen Netze geblockt. (Blockt alles was nicht (!) Server Netz ist)
Genau, das war meine Absicht. Kommunikation untereinander im Netz ja aber jeglicher andere Traffic nach ausserhalb nein.
Und das ist es ja eben. Ich frage mich warum das dann trotzdem geblockt wird.
Das Server Netz so dazu sein, damit meine 3 "Server zum rumspielen und ausprobieren" untereinander komunizieren können. Wie zum bsp Datenbank abfragen etc aber auch damit ich auf meine "Server" zugreifen kann zum beispiel bei Webserver oder phpmyadmin oder ecodms. Also Verkehr der nicht raus soll. Das DMZ netz ist bei mir dafür da damit sie ne Verbindung nach draußen haben um zum bsp
Updates zu machen oder halt auf denn einen "Server" will ich mir einen TS3-Server einrichten, damit der auch raus telefonieren kann.
Ich frage mich warum das dann trotzdem geblockt wird.
Was denn ???Ping und DNS auf das Firewall Interface ?
DNS geht natürlich nur wenn deine FW als DNS Proxy Server rennt. Ping sollte aber klappen.
Mehr aber auch nicht !
aber auch damit ich auf meine "Server" zugreifen kann zum beispiel bei Webserver oder phpmyadmin oder ecodms.
Von außen, sprich aus anderen Netzen heraus ??Das würde so niemals gehen weil der Antwort Traffic von deiner Regel ja geblockt werden würde.
Das klappt nur wenn du den Antwort Traffic aus dem Netz wo dein Client ist passieren lässt !
Dazu musst du in den Advanced Settings Traffic mit gesetztem ACK Bit aus dem Client Netz selektieren das der durch darf aber Traffic ohne ACK Bit eben nicht !
Ich frage mich warum das dann trotzdem geblockt wird.
Was denn ???Ping und DNS auf das Firewall Interface ?
DNS geht natürlich nur wenn deine FW als DNS Proxy Server rennt. Ping sollte aber klappen.
Mehr aber auch nicht !
Das komische ist aber das er auch bei DMZ alles Blockt bisher. Mit der Scheunentor Regel geht alles aber mit meinen dann nicht mehr.
aber auch damit ich auf meine "Server" zugreifen kann zum beispiel bei Webserver oder phpmyadmin oder ecodms.
Von außen, sprich aus anderen Netzen heraus ??Das würde so niemals gehen weil der Antwort Traffic von deiner Regel ja geblockt werden würde.
Das klappt nur wenn du den Antwort Traffic aus dem Netz wo dein Client ist passieren lässt !
Dazu musst du in den Advanced Settings Traffic mit gesetztem ACK Bit aus dem Client Netz selektieren das der durch darf aber Traffic ohne ACK > Bit eben nicht !
Das komische ist aber das er auch bei DMZ alles Blockt bisher
Das ist jedenfalls normal für alle RFC1918 IP Adressen wenn man mal davon ausgeht das sich hinter deinem Alias "RFC1918" alle diese IP Netze befinden.Du kannst dann aus keinem einzigen deiner lokalen LAN Segmente auf die DMZ zugreifen (die vermutlich alle RFC1918 IPs habe). Die DMZ kann aber ins Internet und die lokale Firewall IP pingen und DNS.
Das Blocking der RFC1918 IPs ist damit also völlig normal.
Das ist ja auch so gewollt. das ich bei DMZ nichts machen kann. Aber DMZ blockt ja auch DNS und ICMP auf Google ip als auch auf pfSense Interface.
edit:
Siehe hier
edit:
Siehe hier
So, hab dein Regelwerk mal an 2 (zwei !) pfSense mit aktueller 2.4.4 getestet:
Fazit:
Funktioniert tadellos und wie es soll !
Fazit:
Funktioniert tadellos und wie es soll !
- Ping aufs FW Interface geht
- DNS klappt
- Internet Zugriff klappt
- Zugriff auf alle anderen lokalen IP Netze der Firewall geht nicht
Okay, dann setze ich sie mal neu auf und schau mal. Vielleicht hat sie sich ja doch verschluckt. Weil wenn ich zur Benutzerverwaltung wollte, dann könnte ich mir Passwort ändern, mehr nicht obwohl ich die vollen Adminrechte hab.
Hi,
Ersetze
https://pfSense_IP/system_usermanager_passwordmg.php
durch
https://pfSense_IP/system_usermanager.php.
-
CH
Okay, dann setze ich sie mal neu auf und schau mal. Vielleicht hat sie sich ja doch verschluckt. Weil wenn ich zur Benutzerverwaltung wollte, dann könnte ich mir Passwort ändern, mehr nicht obwohl ich die vollen Adminrechte hab.
Dies ist ein Fehler in der 2.4.4 p3, hat nichts mit deinem Fehler zu tunErsetze
https://pfSense_IP/system_usermanager_passwordmg.php
durch
https://pfSense_IP/system_usermanager.php.
-
CH
Dies ist ein Fehler in der 2.4.4 p3, hat nichts mit deinem Fehler zu tun
Ah okay, gut zu wissen. Nicht das ich mich wieder aufrege deswegen.
