29
Pfsense default deny rule blockt trotz any any Regel
Hallo zusammen,
ich setze eine pfsense 2.6.0 ein und bin damit hochzufrieden. Sie läuft hinter einer FritzBox, das Outbound NAT ist ausgeschaltet. Auf der Fritte gibt’s entsprechende statische Routen. Zwei Netze (Verwaltungsnetz 192.168.14.0/24 und Schulnetz 192.168.10.0/24) sollen geroutet werden. Was auch bestens funktioniert (RDP, WSUS, DNS, Drucker, Domänenanmeldung, GPO etc.).
Nur an einem Punkt hakt es: wir setzen das Programm HDguard ein um bei jedem Neustart eines Schülerrechners immer wieder den Ursprungszustand des Rechners zu gewährleisten. Die HDguard-Clients liegen alle im Netz 192.168.10.0 – um sie zu administrieren gibt es einen HDguard-Master im Netz 192.168.14.0
Die HDguard-Master-Konsole zeigt sämtliche Schulrechner, ob sie an- oder ausgeschaltet sind, ob der Client aktiviert oder deaktiviert ist, ich kann sie aufwecken, ausschalten oder neustarten, mich per RDP verbinden usw., usw.
Das funktioniert prima über die pfsense – ABER nur wenn ich über die Konsole mit dem Befehl pfctl –d die Firewallfunktion abschalte.
Zu Testzwecken habe ich auf allen Schnittstellen als erste Firewallregel eine any any any Regel erstellt. Ich dachte das käme einer ausgeschalteten Firewall gleich. Denkste.
Trotz dieser ALLES zu ALLEM Regeln erhalte ich im Firewall-Log folgende Meldung:
CLIENTS Default deny rule IPv4 (1000000103) 192.168.10.101:49808 192.168.14.134:52234 TCP:A
VERW Default deny rule IPv4 (1000000103) 192.168.14.134:52234 192.168.10.101:49808 TCP:A
Ich glaube dass der Master eine Lizensanfrage in irgend einer Weise stellt. Bin mir aber nicht sicher.
Kann mir jemand helfen?
VG Ralf
ich setze eine pfsense 2.6.0 ein und bin damit hochzufrieden. Sie läuft hinter einer FritzBox, das Outbound NAT ist ausgeschaltet. Auf der Fritte gibt’s entsprechende statische Routen. Zwei Netze (Verwaltungsnetz 192.168.14.0/24 und Schulnetz 192.168.10.0/24) sollen geroutet werden. Was auch bestens funktioniert (RDP, WSUS, DNS, Drucker, Domänenanmeldung, GPO etc.).
Nur an einem Punkt hakt es: wir setzen das Programm HDguard ein um bei jedem Neustart eines Schülerrechners immer wieder den Ursprungszustand des Rechners zu gewährleisten. Die HDguard-Clients liegen alle im Netz 192.168.10.0 – um sie zu administrieren gibt es einen HDguard-Master im Netz 192.168.14.0
Die HDguard-Master-Konsole zeigt sämtliche Schulrechner, ob sie an- oder ausgeschaltet sind, ob der Client aktiviert oder deaktiviert ist, ich kann sie aufwecken, ausschalten oder neustarten, mich per RDP verbinden usw., usw.
Das funktioniert prima über die pfsense – ABER nur wenn ich über die Konsole mit dem Befehl pfctl –d die Firewallfunktion abschalte.
Zu Testzwecken habe ich auf allen Schnittstellen als erste Firewallregel eine any any any Regel erstellt. Ich dachte das käme einer ausgeschalteten Firewall gleich. Denkste.
Trotz dieser ALLES zu ALLEM Regeln erhalte ich im Firewall-Log folgende Meldung:
CLIENTS Default deny rule IPv4 (1000000103) 192.168.10.101:49808 192.168.14.134:52234 TCP:A
VERW Default deny rule IPv4 (1000000103) 192.168.14.134:52234 192.168.10.101:49808 TCP:A
Ich glaube dass der Master eine Lizensanfrage in irgend einer Weise stellt. Bin mir aber nicht sicher.
Kann mir jemand helfen?
VG Ralf
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: 6168305274
Url: https://administrator.de/contentid/6168305274
Ausgedruckt am: 24.11.2024 um 14:11 Uhr
29 Kommentare
Neuester Kommentar
Moin,
wie sehen deine Regeln denn genau aus? Passt das definierte Interface zu der Regel?
Poste mal einen Screenshot davon.
Gruß
Spirit
wie sehen deine Regeln denn genau aus? Passt das definierte Interface zu der Regel?
Poste mal einen Screenshot davon.
Gruß
Spirit
Moin,
das pfSense Handbuch sagt dazu folgendes:
Viele Grüße
das pfSense Handbuch sagt dazu folgendes:
Sometimes log entries will be present that, while labeled with the “Default deny” rule, look like they belong to legitimate traffic. The most common example is seeing a connection blocked involving a web server.
This is likely due to a TCP FIN packet arriving after firewall has removed the connection state. This happens because on occasion a packet will be lost, and the retransmits will be blocked because the firewall has already closed the connection. Another possible reason for the messages is if a packet arrived too slowly and was outside of its expected arrival window. It can also happen when web servers attempt to reuse connections.
This is likely due to a TCP FIN packet arriving after firewall has removed the connection state. This happens because on occasion a packet will be lost, and the retransmits will be blocked because the firewall has already closed the connection. Another possible reason for the messages is if a packet arrived too slowly and was outside of its expected arrival window. It can also happen when web servers attempt to reuse connections.
Viele Grüße
Hi,
Was sagen die Logs? Ist übrigens eine gute Idee, um erst einmal herauszufinden wo es klemmt.
Vielleicht musst Du auch die NAT-Rules erst einmal auf automatic stellen, denn Deine pfSense sollte, wenn die Fritte nicht als Modem arbeitet, schon auch NAT machen.
Gruß orcape
Ich glaube dass der Master eine Lizensanfrage in irgend einer Weise stellt. Bin mir aber nicht sicher.
Deine Beschreibung in allen Ehren, aber das Thema ist einfach zu komplex, um hier zielführend etwas zu sagen.Was sagen die Logs? Ist übrigens eine gute Idee, um erst einmal herauszufinden wo es klemmt.
Vielleicht musst Du auch die NAT-Rules erst einmal auf automatic stellen, denn Deine pfSense sollte, wenn die Fritte nicht als Modem arbeitet, schon auch NAT machen.
Gruß orcape
Das Handbuch sagt hier vor allem Folgendes:
https://networkguy.de/the-problems-with-asynchronous-routing/
Viele Grüße, commodity
If reply traffic such as TCP:A, TCP:SA, or TCP:RA is shown as blocked in the logs, the problem could be asymmetric routing. See Troubleshooting Asymmetric Routing for more info.
Das HDGUARD.master Handbuch sagt unter "2. Installation" wiederum:Die HDGUARD Clients, die HDGUARD Lehrerkonsole und die HDGUARD.master Installationen im Netzwerk verbinden sich mit dem zentralen HDGUARD.master Dienst. Dieser Dienst vermittelt die gesamte Kommunikation der angeschlossenen HDGUARD Komponenten.
Allerdings vermag ich ein klassisches Routerdreieck Deiner Schilderung (noch) nicht zu entnehmen. Die Konstellation von Fritzbox, Pfsense und"Auf der Fritte gibt’s entsprechende statische Routen. "
geben zumindest Anlass, diesem Gedanken nachzugehen. Vielleicht stellst Du uns mal den Netzaufbau dar?https://networkguy.de/the-problems-with-asynchronous-routing/
Viele Grüße, commodity
Alls Allererstes solltest du ja mal gründsätzlich klären WIE dieser HDGuard Master Rechner denn mit den HDGuard Clients kommuniziert? TCP, UDP, Multicast usw.
Allein davon ist dann doch das Regelwerk abhängig oder andere Massnahmen die ergriffen werden müssen um diesen Traffic in einem gerouteten Netz forwarden zu können.
Interessant ist auch die Aussage: "Die HDguard-Master-Konsole zeigt sämtliche Schulrechner, ob sie an- oder ausgeschaltet sind"
Wie der Master mit einem vollständig ausgeschalteten Clientrechner kommunizieren soll grenzt fast an ein Wunder....aber egal.
Fazit: Nimm einen Wireshark oder die in der pfSense integrierte Paket Capture Funktion (unter Diagnostics) und schneide den Traffic des Masters in seinem IP Segment mit. Dann weisst du doch genau was los ist. Verwunderlich warum du da nicht auch selbst drauf gekommen bist?!
Allein davon ist dann doch das Regelwerk abhängig oder andere Massnahmen die ergriffen werden müssen um diesen Traffic in einem gerouteten Netz forwarden zu können.
Interessant ist auch die Aussage: "Die HDguard-Master-Konsole zeigt sämtliche Schulrechner, ob sie an- oder ausgeschaltet sind"
Wie der Master mit einem vollständig ausgeschalteten Clientrechner kommunizieren soll grenzt fast an ein Wunder....aber egal.
Fazit: Nimm einen Wireshark oder die in der pfSense integrierte Paket Capture Funktion (unter Diagnostics) und schneide den Traffic des Masters in seinem IP Segment mit. Dann weisst du doch genau was los ist. Verwunderlich warum du da nicht auch selbst drauf gekommen bist?!
Warum so streng? Die Lehrer haben es doch schon schwer genug.
Das hier
Und das hier
Wie das alte Handbuch
Der Hersteller verlangt nichts weiter als Erreichbarkeit
Viele Grüße, commodity
Das hier
CLIENTS Default deny rule IPv4 (1000000103) 192.168.10.101:49808 192.168.14.134:52234 TCP:A
VERW Default deny rule IPv4 (1000000103) 192.168.14.134:52234 192.168.10.101:49808 TCP:A
sieht für mich nach TCP/IP aus.VERW Default deny rule IPv4 (1000000103) 192.168.14.134:52234 192.168.10.101:49808 TCP:A
Und das hier
"Die HDguard-Master-Konsole zeigt sämtliche Schulrechner, ob sie an- oder ausgeschaltet sind"
ist doch nur die Markteting-schwurbel-Version von ICMP erreichbar/nicht erreichbar. Wie das alte Handbuch
Hinweise zur Einrichtung Vorbereitung Windows XP (ab Service Pack 2) Um HDGUARD mit dem Zusatzprogramm HDGUARD.master bedienen zu können, muss jeder HDGUARD-PC auf Ping-Signale reagieren.
nahe legt Der Hersteller verlangt nichts weiter als Erreichbarkeit
Viele Grüße, commodity
2Der Hersteller verlangt nichts weiter, als Erreichbarkeit
Gut, die ist bei einer routenden Firewall ja immer gegeben! 😉Die TCP Ports sind dennoch etwas komisch da sie nicht im IANA Bereich liegen sondern den Ephemeral Ports. Aber das muss ja nix bedeuten. Der Firewall ist das eh völlig Wurscht.
da sie nicht im IANA Bereich liegen sondern den Ephemeral Ports
Das liegt daran, dass die Softwareentwickler nicht von Dir ausgebildet wurden Viele Grüße, commodity
Ich habe jetzt mal den Wireshark eingesetzt (Danke an aqui, dass Du mich dazu "geprügelt" 😉 hast - ein super Werkzeug).
Da bin ich auf einen Sachverhalt gestoßen, den ich erst mal klären muss. Danke auch an commodity für den Link https://networkguy.de/the-problems-with-asynchronous-routing/ das könnte in die Richtung gehen.
Ich werde mich auf jeden Fall melden, wenn ich genaueres weis und eventuell mein Problem gelöst habe.
Übrigens: ein Mitschnitt bei ausgeschalteter Firewallfunktion (pfctl -d) und gerade gestartetem Hdguard-Master sieht so aus: (192.168.14.134 Master 192.168.10.101 Client)
bei eingeschateter (pfctl -e) bleibt das Fenster einfach leer.
Nur zur Erinnerung: es gibt auf den Schnittstellen nur eine Regel:
Viele Grüße, ralhue
Da bin ich auf einen Sachverhalt gestoßen, den ich erst mal klären muss. Danke auch an commodity für den Link https://networkguy.de/the-problems-with-asynchronous-routing/ das könnte in die Richtung gehen.
Ich werde mich auf jeden Fall melden, wenn ich genaueres weis und eventuell mein Problem gelöst habe.
Übrigens: ein Mitschnitt bei ausgeschalteter Firewallfunktion (pfctl -d) und gerade gestartetem Hdguard-Master sieht so aus: (192.168.14.134 Master 192.168.10.101 Client)
bei eingeschateter (pfctl -e) bleibt das Fenster einfach leer.
Nur zur Erinnerung: es gibt auf den Schnittstellen nur eine Regel:
Viele Grüße, ralhue
Der Mitschnitt sagt (mir) nur, das (erwartungsgemäß) TCP eingesetzt wird. Vielleicht sieht der liebe Kollege @aqui da noch mehr.
Viel interessanter (wenn Du meinen Ansatz verfolgen magst), wäre die Netzwerktopologie inkl. Routing, vielleicht gar in einer kleinen Grafik. Insbesondere das Thema hier:
bei eingeschateter (pfctl -e) bleibt das Fenster einfach leer.
Wo konkret hast Du denn mitgeschnitten?Viel interessanter (wenn Du meinen Ansatz verfolgen magst), wäre die Netzwerktopologie inkl. Routing, vielleicht gar in einer kleinen Grafik. Insbesondere das Thema hier:
Auf der Fritte gibt’s entsprechende statische Routen
Viele Grüße, commodityNur zur Erinnerung: es gibt auf den Schnittstellen nur eine Regel:
Die Quelle sollte man in jedem Falle schon auf das lokale IP Netz begrenzen! Du willst da ja wohl kaum Frames durchlassen die andere Absender IPs haben als die des lokalen LANs. In der Beziehung solltest du deine Scheunentor Regel schon sinnvoll anpassan.Vielleicht sieht der liebe Kollege @aqui da noch mehr.
Nein und kann er in der geposteten Ansicht auch nicht. 
Es sind in der Tat stinknormale TCP Keepalives mit Absender IP aus dem lokalen IP Netz, Quellport TCP 52234 auf die Destination im .10er Netz mit Destination Port TCP 56151. (innerhalb Ephemeral Portrange)
Fragt sich jetzt ob der Destination TCP Port immer fest ist oder willkürlich genommen wird?
Und interessant wäre was bei einem Sessionaufbau passiert also wenn der Master einen Session zu einem der Zielrechner aufbaut!! Dieser Trace fehlt leider.
Also als Fazit stinknormale TCP Frames die stinknormal geroutet werden von der Firewall.
Wenn man mehr sehen will muss man die L2 und L3 Header Sicht im Wireshark aufklappen!
Und interessant wäre was bei einem Sessionaufbau passiert also wenn der Master einen Session zu einem der Zielrechner aufbaut!! Dieser Trace fehlt leider.
Ich glaube nicht dass da was fehlt. Ich lasse wireshark auf 192.168.14.134 mit dem Ip addr Filter auf 192.168.10.101 lauschen. Leeres Fenster. Jetzt starte ich den HDguard-Master und erhalte genau obige Ausgabe. Allerdings bei ausgeschalteter Firewallfunktion.Hier mal mein Aufbau (ojeh - jetzt gibt´s bestimmt Haue!)
Sehr schön! Es geht doch nichts über eine ordentliche Darstellung. Es fehlen zwar noch Angaben zu DHCP-Servern und Standard-Gateways. Für mich sieht es aber so aus:
Im Produktivnetz ist die Fritte der Chef, macht wahrscheinlich DHCP für Netz 14 und ist für dieses Standard-Gateway.
Im Testnetz ist die PfSense der Chef, macht wahrscheinlich DHCP für Netz 10 und 30 und ist für diese Standard-Gateway.
Wenn das so ist, hast Du das Routing-Dreieckschon gefunden:
Der HDG-Client 10.101 funkt seine Anfrage über Gateway 10.10/14.110 (PfSense) zum HDG-Master 14.134. Das Gateway kennt die 14.134, schickt also das Paket direkt dorthin. Der HDG-Master 14.134 antwortet an den Client nach 10.101. Da der in einem für ihn fremden Netz steht, geht das Paket an sein Standardgateway 14.2 (Fritte), von dort über die gesetzte Route an 14.110 (PfSense) und die arme kann mit dem Paket nichts anfangen, weil ja bei dem vorherigen (Anfrage-)Paket gar keine Kommunikation mit 14.2 erfolgt ist. Das ist für sie invalid-Traffic und das Paket wird verworfen.
@aqui: Korrekt so?
@ralhue: verständlich so?
Merke: Zwei Gateways im selben Netz, da ist das Routing-Dreick nicht weit.
Aber Hausaufgaben:
1. Löse das Problem mit dem Routing-Dreieck
2. Erwäge vielleicht mal eine konsistente Adressvergabe, insbesondere für die Gateways, sonst verlierst Du den Überblick. Standard-Gateway könnte z.B. immer die .1 sein
3. Dieses tolle Beispiel aus dem Leben vielleicht gleich mal im Unterricht verwursten! Aber nicht so: https://www.youtube.com/watch?v=nUl_HIw3VLs
Dein Kollege Sebastian Philippi macht zu den Basics tolle Videos auf YT.
Viele Grüße, commodity
Im Produktivnetz ist die Fritte der Chef, macht wahrscheinlich DHCP für Netz 14 und ist für dieses Standard-Gateway.
Im Testnetz ist die PfSense der Chef, macht wahrscheinlich DHCP für Netz 10 und 30 und ist für diese Standard-Gateway.
Wenn das so ist, hast Du das Routing-Dreieckschon gefunden:
Der HDG-Client 10.101 funkt seine Anfrage über Gateway 10.10/14.110 (PfSense) zum HDG-Master 14.134. Das Gateway kennt die 14.134, schickt also das Paket direkt dorthin. Der HDG-Master 14.134 antwortet an den Client nach 10.101. Da der in einem für ihn fremden Netz steht, geht das Paket an sein Standardgateway 14.2 (Fritte), von dort über die gesetzte Route an 14.110 (PfSense) und die arme kann mit dem Paket nichts anfangen, weil ja bei dem vorherigen (Anfrage-)Paket gar keine Kommunikation mit 14.2 erfolgt ist. Das ist für sie invalid-Traffic und das Paket wird verworfen.
@aqui: Korrekt so?
@ralhue: verständlich so?
Merke: Zwei Gateways im selben Netz, da ist das Routing-Dreick nicht weit.
jetzt gibt´s bestimmt Haue!
Haue gibt's keine, Du bist ja mit dem Problem ausreichend gestraft Aber Hausaufgaben:
1. Löse das Problem mit dem Routing-Dreieck
2. Erwäge vielleicht mal eine konsistente Adressvergabe, insbesondere für die Gateways, sonst verlierst Du den Überblick. Standard-Gateway könnte z.B. immer die .1 sein
3. Dieses tolle Beispiel aus dem Leben vielleicht gleich mal im Unterricht verwursten! Aber nicht so: https://www.youtube.com/watch?v=nUl_HIw3VLs
Dein Kollege Sebastian Philippi macht zu den Basics tolle Videos auf YT.
Viele Grüße, commodity
1Ich glaube nicht dass da was fehlt.
Muss ja, denn der Master wird ja zum kompletten Management der Clients nicht nur simple TCP Keepalives senden, oder?! Wenn doch gehen die natürlich problemlos durch jeden Router oder Firewall, was du auf den Zielsystemen dann ebenfalls mit dem Wireshark problemlos nachweisen kannst. Alles was vor der Firewall rausgeht sollte dann auch hinter der Firewall am Ziel ankommen!!Korrekt so?
Fast... - HDG Master "sieht" das das sein Ziel HDG Client in einem fremden IP Netz liegt mit .10.101 und befragt sein Gateway FritzBox (ARP) und sendet das Paket dorthin.
- FritzBox erkennt das das Zielgateway im gleichen IP Netz liegt .14.110 und sendet ein ICMP Redirect Frame (Typ 5) an den HDG Master so das der Master PC signalisiert bekommt das er das Ziel über einen anderen Router im gleichen Netz erreicht und nun die pfSense direkt ARPt und sein .10.101er Paket direkt dahin routet ohne den überflüssigen Umweg über die FB.
- So geht das zum HDG Client und dessen Antwort dann wieder via pfSense direkt zum Master
Möglich ist das der Master PC ICMP Redirects blockt in seiner lokalen Firewall was fatal wäre. Dann läuft der gesamte Traffic in alle anderen lokalen Subnetze immer als überflüssiger "Durchlauferhitzer" über die FritzBox und verdoppelt sinnlos den Traffic im .14er Netz mit einer deutlichen Mehrbelastung für die schwachbrüstige Consumer FritzBox. Das ICMP Setup sollte man also unbedingt prüfen in einem gerouteten Umfeld!
Deutlich besser und sinnvoller vom Layer 3 Design wäre das Default Gateway ALLER lokalen IP Netze auf die pfSense zu legen und der pfSense eine Default Route auf die FritzBox zu verpassen! Siehe dazu auch das hiesige VLAN Tutorial!!
In jedem Falle MUSS in der pfSense in so einem Setup wie oben immer das Firewalling in den Advanced Settings unter Firewall&NAT über lokale Netze deaktiviert werden, was vermutlich vergessen wurde?!:
Haue gibt es nur wegen der kosmetisch miesen IP Adressierung. Router und Firewalls werden im best Practise immer statisch an den Netzwerk Enden oder Anfang der IP Segmente adressiert (.1 und/oder .254 bei /24er Prefix). Das minimiert die Gefahr von Überschneidungen in der IP Adressierung bei DHCP Pools usw. Sowas lernt auch der Azubi im ersten Lehrjahr!
... und sendet ein ICMP Redirect
Großartig, hier kann man immer was lernen! Danke @aquiIn jedem Falle ...
Wenn das redirecten von ICMP klappte, wäre das doch nicht nötig, denn "Static route filtering" ist ja dafür da, den über das Dreieck fließenden invalid-Traffic durchzulassen. Netgate:This may be required in situations where multiple subnets are connected to the same interface, to avoid blocking traffic that is passed through the firewall in one direction only due to asymmetric routing.
Und @ralhue: Netgate erklärt das auch geradezu vorbildlich nochmals hier:https://docs.netgate.com/pfsense/en/latest/routing/static.html#asymmetri ...
Das Bild gibt ja faktisch Dein Netz wieder
@aqui: Unter Windows wird ICMP doch lokal standardmäßig geblockt. Das betrifft dann auch die redirects, oder?
Viele Grüße, commodity
Hallo Commodity und alle Anderen,
Jetzt kippt mein Verständnis aber um 180 Grad. Eigentlich dürfte dann doch alles andere auch nicht funktionieren:
All das funktioniert nur dieser sch.... HDguard nicht.
Viele Grüße ralhue
Im Produktivnetz ist die Fritte der Chef, macht wahrscheinlich DHCP für Netz 14 und ist für dieses Standard-Gateway.
Im Testnetz ist die PfSense der Chef, macht wahrscheinlich DHCP für Netz 10 und 30 und ist für diese Standard-Gateway.
Genauso ist es.Im Testnetz ist die PfSense der Chef, macht wahrscheinlich DHCP für Netz 10 und 30 und ist für diese Standard-Gateway.
Der HDG-Client 10.101 funkt seine Anfrage über Gateway 10.10/14.110 (PfSense) zum HDG-Master 14.134. Das Gateway kennt die 14.134, schickt also das Paket direkt dorthin. Der HDG-Master 14.134 antwortet an den Client nach 10.101. Da der in einem für ihn fremden Netz steht, geht das Paket an sein Standardgateway 14.2 (Fritte), von dort über die gesetzte Route an 14.110 (PfSense) und die arme kann mit dem Paket nichts anfangen, weil ja bei dem vorherigen (Anfrage-)Paket gar keine Kommunikation mit 14.2 erfolgt ist. Das ist für sie invalid-Traffic und das Paket wird verworfen.
Besser kann man´s nicht erklären. Hab´s verstanden.Jetzt kippt mein Verständnis aber um 180 Grad. Eigentlich dürfte dann doch alles andere auch nicht funktionieren:
- Teilhabe am WSUS (der läuft auch auf dem 14.134er)
- RDP-Verbindungen zum 10.101er vom 14.134er
- Drucken auf Druckern im 14.0 Netz
- Teilhabe an anderen Domänen-Diensten wie z.B. GPO´s
- korrekter DNS-Eintrag des 10.101. auf beiden DCs im 14.0 Netz
- Alles was mit Internet zu tun hat
- selbst ein banaler PING müsste doch verworfen werden - klappt aber
All das funktioniert nur dieser sch.... HDguard nicht.
1. Löse das Problem mit dem Routing-Dreieck
Gibt es da überhaupt eine Lösung ohne Veränderung am Produktivnetz?Dein Kollege Sebastian Philippi macht zu den Basics tolle Videos auf YT.
Aber Hallo!!! Sephis Youtube-Kanal ist einfach nur fantastisch. Seine Kursunterlagen haben zusammen mit aquis Toturials einen eigenen Ordner bei mir.Viele Grüße ralhue
@aqui @commodity
habe beim schreiben meines obigen Beitrags Eure beiden letzten noch nicht gesehen. Lese Sie mir zuhause in Ruhe durch.
Habe noch schnell den Haken bei "Static route filtering" gesetzt - hat aber nichts gebracht.
VG ralhue
habe beim schreiben meines obigen Beitrags Eure beiden letzten noch nicht gesehen. Lese Sie mir zuhause in Ruhe durch.
Habe noch schnell den Haken bei "Static route filtering" gesetzt - hat aber nichts gebracht.
VG ralhue
Unter Windows wird ICMP doch lokal standardmäßig geblockt. Das betrifft dann auch die redirects, oder?
Vermutlich dann ja. 
Das müsste man mal genau checken in "Windows Firewall mit erweiterter Sicherheit".
Gibt es da überhaupt eine Lösung ohne Veränderung am Produktivnetz?
Lesen was man dir hier gepostet hat! 🧐Zusätzlich solltest du bei Regel Änderungen dann auch die State Table in der FW löschen sonst merkst du erst nach einem Timeout die Änderung!
Dein kardinaler Designfehler ist aber das falsche Default Gateway im 14er Netz. Das sollte immer die pfSense sein. Dazu kommt noch das im 14er Netz niemals Endgeräte sein sollten.
In deinem Design als Router Kaskade sollte das immer ein reines Punkt zu Punkt Koppelnetz sein ohne Endgeräte dadrin!!
An den beiden Punkten krankt dein Netzwerk Design.
All das funktioniert
Dann ist das Routing-Dreieck imo raus und es greifen die vom Kollegen @aqui angesprochenen redirects ein.Folgerichtig bringt dann auch der
Haken bei "Static route filtering"
keinen Effekt, weil es ja keinen invalid-Traffic gibt.Und ich bin etwas ratlos.
Banal: Kann es sein, dass der HDG-Master in den Einstellungen einen Haken hat, wo Zugriffe aus/in fremde/n Netze/n spezifisch erlaubt werden müssen?
Viele Grüße, commodity
Meinte ich auch - steht halt "Static route filtering:" davor.
Und jetzt mach ich folgendes:
Und schwupps: unser Sorgenkind ist da:
Umgekehrt:
Obwohl der HDG Client nicht im Master als aktiv/angeschaltet erscheint:
und in die andere Richtung sogar aus einer RDP-Verbindung heraus:
Der HDG-Master läuft als Dienst auf dem 14.134 und benutzt port 25652
Bei der Installation muss händisch ein Eintrag ins DNS gemacht werden
Der Client trägt sich ja automatisch ins DNS ein
Und alles mit default gateway 192.168.14.110 also die Fritte müsste raus sein?!
Noch eine Idee?
VG ralhue
Dein kardinaler Designfehler ist aber das falsche default Gateway im 14er Netz.
Ich habe auf dem 14.134 mal die default Gateway auf 14.110 gesetzt - bringt nichts.Banal: Kann es sein, dass der HDG-Master in den Einstellungen einen Haken hat, wo Zugriffe aus/in fremde/n Netze/n spezifisch erlaubt werden müssen?
Leider nein. Dann würde das ja auch bei deaktivierter Firewall nicht gehen. Zum Verdeutlichen mal ein paar Bilder von der Master-Konsole:- Der linke Rechner ist aus.
- Der rote ist an und HDG ist nicht scharf (kein Rücksetzen beim nächsten Start).
- Der grüne ist an und egal was der Schüler anstellt - beim nächsten Start ist alles wieder wie es war.
- Muster-Rechner ist an, der HDG ist nicht scharf - aber man sieht es nicht.
Und jetzt mach ich folgendes:
Und schwupps: unser Sorgenkind ist da:
Umgekehrt:
Der HDG-Master läuft als Dienst auf dem 14.134 und benutzt port 25652
Bei der Installation muss händisch ein Eintrag ins DNS gemacht werden
Der Client trägt sich ja automatisch ins DNS ein
Und alles mit default gateway 192.168.14.110 also die Fritte müsste raus sein?!
Noch eine Idee?
VG ralhue
Du hast sehr wahrscheinlich durch die Frickelei irgendwas an der Firewall vermurkst. Wenn die Kommunikation zw. Master und Clients wirklich nur einfache TCP Keepalives sind werden diese vom any any Regelwerk natürlich nicht geblockt.
Du hast ebenso noch keinerlei Aussagen gemacht wie überhaupt der Master die Clients erkennt oder ob andersrum die Clients sich beim Master registrieren. Sprich also WER initiiert eine Verbindung Master oder Client? Das ist essentiell wichtig zu wissen.
Daraus ergibt sich dann die Frage WIE der Aufbau so einer Master Client Beziehung aussieht. Niemals werden das nur simple TCP Keepalives sein, zumindestens nicht am Anfang.
Du wirst also nicht umhin kommen einmal strategisch vorzugehen.
Schneide mit dem Wireshark einmal dediziert einen vollständigen Sessionaufbau mit in einem Setup wo alles funktioniert. Als Capturefilter dann Source und/oder Destination IP so das du nur diesen dedizierten Traffic mitschneidest.
Je nachdem WER die Verbindung initiert startest du den neu um den gesamten Prozess mitzuschneiden wenn sich Client am Master oder umgekehrt anmeldet, je nachdem wer startet.
Dann hast du eine Blaupause WIE diese Verbindung korrekt aussehen muss.
Dann aktivierst du das Firewalling und wiederholst den Trace und vergleichst dann den Output.
Es MUSS dann ein Unterschied sichtbar sein in den Traces und damit ist dann auch klar was ggf. gefiltert wird oder durch deine Frickelei ggf. nicht mehr funktioniert.
Sinnvoll ist die Traces einmal an der Client und an der Masterseite auszuführen.
Eine Problematik ist auch das unglückliche Design das du im Koppelnetz zum Router, also am "heissen" WAN Port der Firewall aktive lokale Endgeräde hast. Kein gutes Design und keine gute Idee.
Idealerweise ist das ausschliesslich eine reine Punkt zu Punkt Verbindung zum Router. Ob mit oder ohne NAT ist dabei Geschmackssache.
Dort gehören keine produktiven Endgeräte rein sondern immer in ein separates lokales LAN Segment. Ob du das als VLAN oder mit dedizierten Interfaces realisierst spielt dabei keine Rolle.
Mit anderen Worten: Die Endgeräte im 14er IP Koppelnetz zum Router müssen da raus und in ein eigens separates Netz.
Eine reine IPv4 basierte klassische TCP Verbindung laut deinem Mitschnitt würde niemals bei einem any any Regelwerk blockiert werden.
Interessant wäre auch das Regelwerk auf der Client Seite. Dazu hast du noch gar nichts gesagt. Wenn die Clients die Session zum Mater aufbauen ist das ebenso wichtig.
Du hast ebenso noch keinerlei Aussagen gemacht wie überhaupt der Master die Clients erkennt oder ob andersrum die Clients sich beim Master registrieren. Sprich also WER initiiert eine Verbindung Master oder Client? Das ist essentiell wichtig zu wissen.
Daraus ergibt sich dann die Frage WIE der Aufbau so einer Master Client Beziehung aussieht. Niemals werden das nur simple TCP Keepalives sein, zumindestens nicht am Anfang.
Du wirst also nicht umhin kommen einmal strategisch vorzugehen.
Schneide mit dem Wireshark einmal dediziert einen vollständigen Sessionaufbau mit in einem Setup wo alles funktioniert. Als Capturefilter dann Source und/oder Destination IP so das du nur diesen dedizierten Traffic mitschneidest.
Je nachdem WER die Verbindung initiert startest du den neu um den gesamten Prozess mitzuschneiden wenn sich Client am Master oder umgekehrt anmeldet, je nachdem wer startet.
Dann hast du eine Blaupause WIE diese Verbindung korrekt aussehen muss.
Dann aktivierst du das Firewalling und wiederholst den Trace und vergleichst dann den Output.
Es MUSS dann ein Unterschied sichtbar sein in den Traces und damit ist dann auch klar was ggf. gefiltert wird oder durch deine Frickelei ggf. nicht mehr funktioniert.
Sinnvoll ist die Traces einmal an der Client und an der Masterseite auszuführen.
Eine Problematik ist auch das unglückliche Design das du im Koppelnetz zum Router, also am "heissen" WAN Port der Firewall aktive lokale Endgeräde hast. Kein gutes Design und keine gute Idee.
Idealerweise ist das ausschliesslich eine reine Punkt zu Punkt Verbindung zum Router. Ob mit oder ohne NAT ist dabei Geschmackssache.
Dort gehören keine produktiven Endgeräte rein sondern immer in ein separates lokales LAN Segment. Ob du das als VLAN oder mit dedizierten Interfaces realisierst spielt dabei keine Rolle.
Mit anderen Worten: Die Endgeräte im 14er IP Koppelnetz zum Router müssen da raus und in ein eigens separates Netz.
Eine reine IPv4 basierte klassische TCP Verbindung laut deinem Mitschnitt würde niemals bei einem any any Regelwerk blockiert werden.
Interessant wäre auch das Regelwerk auf der Client Seite. Dazu hast du noch gar nichts gesagt. Wenn die Clients die Session zum Mater aufbauen ist das ebenso wichtig.
Kann es sein, das auf einem Interface das Flag zum blocken von privaten IPs aktiv ist und somit alle RFC1918er Adressen bei aktiviert FW eingehend nicht erlaubt sind?
1
@aqui Ich kenne Deine vorzüglichen Tuts und weiß wie eigentlich ein optimales Netzdesign Deiner Meinung nach auzusehen hat. Damit rennst Du bei mir offene Scheunentore ein. Leider kann man im Alltag nicht immer alles gleich so umsetzen, wie man möchte und sollte. Das produktive Netz ist mometan "off limits" . Trotzallem möchte ich Dir aber mal ein Netzdesign zur Begutachtung vorlegen, bei dem Du dann sagst "fein macht Bub".
Dazu muss aber erst mal im Testnetz die leidige HDG-Geschichte laufen, damit ich dann einen Unterrichtsraum testweise im seperierten Netzsegment laufen lassen kann (und damit die Entscheidungsträger sehen "aha - das funktioniert ja - mach mal weiter").
Ich werde weiter mit Wireshark prüfen und mich mit dem Netgate-Handbuch auseinandersetzen.
Berichte folgen.
VG ralhue
Dazu muss aber erst mal im Testnetz die leidige HDG-Geschichte laufen, damit ich dann einen Unterrichtsraum testweise im seperierten Netzsegment laufen lassen kann (und damit die Entscheidungsträger sehen "aha - das funktioniert ja - mach mal weiter").
Ich werde weiter mit Wireshark prüfen und mich mit dem Netgate-Handbuch auseinandersetzen.
Berichte folgen.
VG ralhue
@Spirit-of-Eli
Ein schöner und einfacher Gedanke. +1
@ralhue sagt aber ja, das hier geht:
Das sollte bei RFC1918-Block ja nicht klappen.
Ich denke, Kollege @aqui sieht das richtig und nur der Trace wird mehr Aufklärung bringen. Insbesondere ein Trace des vom Client ausgehenden Traffics wäre hier interessant, denke ich.
@ralhue
Ach und noch was: Das ist doch eine teuer bezahlte Software. Lass uns doch mal daran teilhaben, was der Support dort über die Thematik denkt. Die Trennung von Verwaltungs- und Schülernetz sollte ja für die kein Ausnahmefall sein...
Edit:
Das hatte ich noch nicht auf dem Schirm: Ihr habt Schülerclients im 14er-Netz und der HDGuard soll nun auch noch gleichzeitg einen Client im 10er Netz bedienen, korrekt? Nur für den Hinterkopf.
Und: Ich habe irgendwie den Verdacht, dass der HDGuard ein eigenes Netz aufspannt. Kannst Du das am Master-PC vielleicht mal checken? Ipconfig /all sollte ja schon reichen.
Viele Grüße, commodity
Ein schöner und einfacher Gedanke. +1
@ralhue sagt aber ja, das hier geht:
- RDP-Verbindungen zum 10.101er vom 14.134er
- selbst ein banaler PING ... klappt aber
Ich denke, Kollege @aqui sieht das richtig und nur der Trace wird mehr Aufklärung bringen. Insbesondere ein Trace des vom Client ausgehenden Traffics wäre hier interessant, denke ich.
@ralhue
Berichte folgen.
ja, bitte ein Trace. Es bleibt spannend.Ach und noch was: Das ist doch eine teuer bezahlte Software. Lass uns doch mal daran teilhaben, was der Support dort über die Thematik denkt. Die Trennung von Verwaltungs- und Schülernetz sollte ja für die kein Ausnahmefall sein...
Edit:
Das hatte ich noch nicht auf dem Schirm: Ihr habt Schülerclients im 14er-Netz und der HDGuard soll nun auch noch gleichzeitg einen Client im 10er Netz bedienen, korrekt? Nur für den Hinterkopf.
Und: Ich habe irgendwie den Verdacht, dass der HDGuard ein eigenes Netz aufspannt. Kannst Du das am Master-PC vielleicht mal checken? Ipconfig /all sollte ja schon reichen.
Viele Grüße, commodity
Bin am tüfteln mit Wireshark und dabei fiel mir, beim pingen von 10.101 auf 14.134 also HDG-Client auf HDG-Master, folgendes auf:
Wireshark hört auf seine 14.134 und filtert ICMP dabei pfctl -d (FW aus)
als Source die 192.168.10.101 - für mich erstmal nicht verwunderlich.
Wireshark hört auf seine 14.134 und filtert ICMP dabei pfctl -e (FW ein)
nun aber als Source die 192.168.14.110 also das "Beinchen" der pfsense im VERW-Netz eigentlich ja auch nicht verwunderlich - aber hat der HDG-Master damit nicht ein Problem????
Es gibt ganz selten die Situation dass ein Client (ganz normal im 14er Netz) eine IP bekommt, die noch nicht im DNS registriert ist (wenn er z.B. lange nicht benutzt wurde). Ich konnte ihn dann mit seiner MAC per WoL aufwecken, sehe ihn aber in der Masterkonsole als ausgeschaltet. Passt dann die IP des Client zum DNS-Eintrag wieder, läuft alles normal.
Eigentlich ist das alles eine ganz simple Sache:
Der Dienst HDGmaster läuft auf dem 14.134er und hört auf Port 52234. Wird ein neuer Rechner aufgesetzt, in die Domäne eingeklinkt und schlussendlich der HDguard auf ihm installiert schaut der HDG-Client, ob es einen HDGmaster gibt der auf 52234 hört und wenn ja steht der Client in der Konsole. Wenn nicht muss er eben standalone administriert werden.
Hier mal ein Trace bei ausgeschalteter FW und einem HDG-Client Neustart:
Tutto va bene. Wenn aber die FW eingeschltet ist, kommt der ganze Schlontz unter (aus Sicht des HDGmasters) falscher oder nicht zuortbarer IP an.
Könnte es sein, dass das Problem eine ultrabanale Ursache hat?????
Viele Sonntagsgrüße Ralf
Wireshark hört auf seine 14.134 und filtert ICMP dabei pfctl -d (FW aus)
als Source die 192.168.10.101 - für mich erstmal nicht verwunderlich.
Wireshark hört auf seine 14.134 und filtert ICMP dabei pfctl -e (FW ein)
nun aber als Source die 192.168.14.110 also das "Beinchen" der pfsense im VERW-Netz eigentlich ja auch nicht verwunderlich - aber hat der HDG-Master damit nicht ein Problem????
Es gibt ganz selten die Situation dass ein Client (ganz normal im 14er Netz) eine IP bekommt, die noch nicht im DNS registriert ist (wenn er z.B. lange nicht benutzt wurde). Ich konnte ihn dann mit seiner MAC per WoL aufwecken, sehe ihn aber in der Masterkonsole als ausgeschaltet. Passt dann die IP des Client zum DNS-Eintrag wieder, läuft alles normal.
Eigentlich ist das alles eine ganz simple Sache:
Der Dienst HDGmaster läuft auf dem 14.134er und hört auf Port 52234. Wird ein neuer Rechner aufgesetzt, in die Domäne eingeklinkt und schlussendlich der HDguard auf ihm installiert schaut der HDG-Client, ob es einen HDGmaster gibt der auf 52234 hört und wenn ja steht der Client in der Konsole. Wenn nicht muss er eben standalone administriert werden.
Hier mal ein Trace bei ausgeschalteter FW und einem HDG-Client Neustart:
Tutto va bene. Wenn aber die FW eingeschltet ist, kommt der ganze Schlontz unter (aus Sicht des HDGmasters) falscher oder nicht zuortbarer IP an.
Könnte es sein, dass das Problem eine ultrabanale Ursache hat?????
Viele Sonntagsgrüße Ralf
schaut der HDG-Client, ob es einen HDGmaster gibt der auf 52234 hört
Und genau das ist die Frage: WIE macht der Client das??- Per Broadcast?
- Per Multicast mDNS etc.?
- Indem dem Client schlicht und einfach die IP des Masters konfiguriert wird?
Ein Test mit einem Paket Generator der TCP Frames auf TCP 52234 sendet zeigt das die Firewall fehlerfrei diese Pakete forwardet bei entsprechendem Regelwerk! Alternativ kann man das mit Telnet (z.B. PuTTY usw.) simulieren wenn man statt Port TCP 23 Port 52234 verwendet.
Die Redirects oben kommen übrigens daher weil Winblows generell das ICMP Protokoll in seiner lokalen Firewall blockiert. Damit sind die sinnvollerweise vom Router/Firewall gesendeten ICMP Redirects inaktiv und Windows sendet damit sinnloserweise den gesamten Traffic weiter immer über den Default Router als "Durchlauferhitzer" statt direkt über den Router der zum Ziel führt. Das verdoppelt dann sinnloserweise jeglichen Traffic in die Subnetze in deinem Netz.
Das liegt a. an deinem falschen Design im Koppelnetz zum Router Endgeräte zu betreiben und b. an der Tatsache das Windows die ICMP Steuerpakete in der Firewall filtert.
Das kannst du aber mit einer entsprechenden Regel in der Windows Firewall fixen wenn du dort Redirects erlaubst. Langfristig besser ist natürlich dein Design richtig zu machen statt die derzeitige Frickelei mit den Emdgeräten im Koppelnetz.
Der zweite Trace signalisiert doch, dass bei eingeschalteter Firewall NAT angewendet wird. Hattest Du nicht gesagt, das ist deaktiviert?
Viele Grüße, commodity
Viele Grüße, commodity
@commodity Halleluja!!!! Du bist mein Held. Genau das war´s. Das Layer 8 Problem ist gelöst! Ich hätte Stein und Bein schwören können, ich hätte NAT ausgeschaltet - war aber nicht so. Der HDG-Client erscheint in der Konsole, lässt sich damit komplett administrieren, RDP funktioniert, WSUS klappt, den Rest probier ich morgen vor Ort.
Jetzt aber erst mal vielen, vielen herzlichen Dank an Euch alle vor allem auch an aqui der mich, mit seiner strengen Art, zu neuen Ufern "geprügelt" hat. Und natürlich Dir commodity für das aufmerksame, kritische Mitlesen und Kommentieren - was schlußendlich zur Lösung geführt hat. Ich habe sehr viel dazugelernt.
Liebe Grüße, ralhue
Jetzt aber erst mal vielen, vielen herzlichen Dank an Euch alle vor allem auch an aqui der mich, mit seiner strengen Art, zu neuen Ufern "geprügelt" hat. Und natürlich Dir commodity für das aufmerksame, kritische Mitlesen und Kommentieren - was schlußendlich zur Lösung geführt hat. Ich habe sehr viel dazugelernt.
Liebe Grüße, ralhue
Na das ist doch mal ein erfolgreiches Wochenende
Entscheidend war aber, dass Kollege @aqui Dich vom Sinn des Tracens überzeugt hat - und Du das so schön hinbekommen hast.
Ich bin durchaus erfreut, dass die Mitdenkenden Freunde im Netgate-Forum das nicht so schnell gelöst haben
Dieser Thread hatte noch einen interessanten Nebennutzen, nämlich die oben schon von @aqui angesprochene Erkenntnis, dass die Windows-Firewall ICMP-Redirects blockt. Hat Spaß gemacht!
Viele Grüße, commodity
Entscheidend war aber, dass Kollege @aqui Dich vom Sinn des Tracens überzeugt hat - und Du das so schön hinbekommen hast.
Ich bin durchaus erfreut, dass die Mitdenkenden Freunde im Netgate-Forum das nicht so schnell gelöst haben
Dieser Thread hatte noch einen interessanten Nebennutzen, nämlich die oben schon von @aqui angesprochene Erkenntnis, dass die Windows-Firewall ICMP-Redirects blockt. Hat Spaß gemacht!
Viele Grüße, commodity
