default deny rule blockt trotz any any Regel
-
@ralhue
Hallo,da möchten die beiden Geräte weitere Pakete innerhalb einer vermeintlich bestehenden Verbindung senden, die pfSense hat diese aber bereits geschlossen. Möglicherweise ein Timeout, also ewig lang kein Nachfolgepaket durch gekommen.
Oder es wurde ein Paket verworfen aus irgendeinem Grund.Passiert das mit unterschiedlichen Clients?
Lösungen gibt es dafür mehrere, aber man sollte erst die Anforderungen der Applikation kennen, wenn man es gezielt lösen möchte. Vielleicht gibt es da Angaben, wie lange ein Timeout sein müsste.
Ansonsten kannst du nur probieren.Bspw. System > Advanced > Firewall & NAT > Firewall Optimization Options auf "Conservative" stellen.
Eine spezielle Regel für die Verbindung erstellen und darin den Timeout entsprechend hochsetzen,
oder eine "Sloppy State" Regel erstellen,
oder eine Regel, die speziell die ACK Pakete erlaubt, wenn das immer nur diese trifft.
Die letzte funktioniert, wenn die Bedingung zutrifft, der vorletzte müsste sicher funktionieren, ist halt mehr offen.
-
@viragomann said in default deny rule blockt trotz any any Regel:
oder eine "Sloppy State" Regel erstellen,
oder eine Regel, die speziell die ACK Pakete erlaubt, wenn das immer nur diese trifft.Das würde ich vermeiden. Dass hier ACK Pakete geblockt werden deutet auf unsauberes (oder ein Fehler im) Routing hin. Das zu umgehen indem man an den Regeln dann so lange rummurkst dass es geht führt zu unsauberem Regelwerk und dann hin zu irgendwelchen dubiosen Floating Regeln mit denen ich mich im Support dann wieder rumschlagen darf.
Da ist irgendwas im Netz nicht sauber konfiguriert oder hier wird ohne VLAN Trennung in der gleichen Broadcast Zone mit mehreren Netzen gearbeitet. Andere Alternative wäre ein Brückenschlag der nicht stattfinden soll/darf, irgendein Gerät also mit Beinen in mehreren Netzen o.ä.
Prinzipiell halte ich ja das Konstrukt ohne outbound NAT für unschön, aber das ist dann noch ein anderes Thema.
Wie sind denn die beiden Netze 14 und 10 wo angeschlossen an der pfSense und wie sind die auf Switchen etc. rausgeführt? Ich denke da sitzt die Problemquelle bevor wir unnötig an der Sense schrauben, denn wenn auf jedem der beiden IFs eine allow any rule drin ist, IST das ungefähr wie "kein Filter" - nur dass eben Fehler oder Probleme auffallen wie dieses. :)
Cheers
\jens -
@jegr said in default deny rule blockt trotz any any Regel:
@viragomann said in default deny rule blockt trotz any any Regel:
oder eine "Sloppy State" Regel erstellen,
oder eine Regel, die speziell die ACK Pakete erlaubt, wenn das immer nur diese trifft.Das würde ich vermeiden.
Wenn du darin ein Empfehlung gesehen hast, hast du es missverstanden.
Dass die letzten beiden Optionen nicht das Gelbe vom Ei sind, hätte mein letzter Satz ausdrücken sollen. -
@viragomann Dann hab ich das mißverstanden, sorry
-
Hier mal mein Testaufbau:
-
@ralhue
Was ist die Kiste links oben mit den statischen Routen? Der Upstream Router? -
@viragomann Fritzbox
-
@ralhue
Verstehe. Da hatte @JeGr den richtigen Riecher, da ist asymmetrisches Routing vorprogrammiert.Die FB ist das Standardgateway und soll es vermutlich auch bleiben, nachdem sich die pfSense in einem "Probiernetz" befindet.
Aber so funktioniert das nicht mit den Routen auf der FB. Entweder du musst auf allen Geräten statische Routen für das jeweils andere Subnetz einrichten oder die pfSense muss das Default Gateway in beiden Subnetzen werden.
Letzteres ist natürlich die schönere und wohl einfachere Lösung.
Zwischen FB und pfSense musst du dann ein zusätzliches Netz einrichten, wenn das Outbound NAT ausgeschaltet bleiben soll, und die Routen auf der FB eben auf die neue pfSense IP richten. -
@viragomann Alternativ mal das NAT auf der pfSense wieder anmachen. Auto sollte zum Test reichen. Dann müsste alles von LAN, CLIENTS und DEV automatisch abgehend auf die VERW Adresse geNATtet werden, damit sollten die Geräte im 14er Netz dann kein Problem mit dem Traffic mehr haben, zumindest was den Master angeht. Aber die Zugriffe von Master auf Clients wird dann tricky...
Problematisch könnte eben die Fritte sein. Die hat zwar die Routen, aber WIE sie dann die Anfragen wirklich handelt ist ein "?", denn wenn dein HDguard Client mit dem Master reden will, geht der Zugriff an pfSense, dann an den Master. Der antwortet aber dann nicht der Sense, sondern der Fritte und die schickts an die pfSense weiter. OFT funktioniert das irgendwie, manchmal aber eben nicht, und dann hat man genau diese asymmetrischen Effekte, dass Antwort Pakete nicht von da kommen, von wo sie erwartet werden und das erzeugt dann Probleme.
Man könnte da in beide Richtungen NATten um das zu umgehen oder auch einfach mal zum Test auf dem HDguard Master die Routen für .10 und .30 direkt hinzufügen auf die .14.110 damit der Master schon direkt die Pakete richtig zustellt. Eventuell löst das schon den Knoten für das Testsetup und wenn es tatsächlich produktiv werden soll, kann man das ja dann wie @viragomann schrieb umbauen, dass wirklich NUR noch die Fritte mit der Sense im gleichen Transfernetz ist und alles andere dann in versch. VLANs hinter der Sense eingepackt.
Cheers
-
@jegr said in default deny rule blockt trotz any any Regel:
Man könnte da in beide Richtungen NATten um das zu umgehen
Ein S-NAT? Das müsste aber die FB machen, dann da schicken zumindest die Geräte im 14er Netz ihre Pakete hin, wenn sie ins 10er möchten.
-
Ich habe auf dem HDG-Master 14.134 das default gateway auf 14.110 gesetzt. Damit dürfte die Fritte doch eigentlich außen vor sein?!
Bringt aber nichts. Die Frage ist doch warum läuft-
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 etc. -
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.
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:
wieder weg
Obwohl der HDG Client nicht im Master als aktiv/angeschaltet erscheint:
und in die andere Richtung sogar aus einer RDP-Verbindung vom HDG-Master 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 -
-
@ralhue
Möglicherweise gibt es ein "Leck" auf einem der Switche. Vielleicht mal mit pcap untersuchen, wo die Pakete genau hingehen.Der Ping sagt leider sehr wenig über das korrekte Routing aus. Der Ping klappt auch, wenn der FB das Default Gateway ist und die Pakete weiterleitet.
Mit TCP Paketen geht das aber nicht. Die würden nur in die eine Richtung über die FB gehen, die Antwortpakete gingen direkt zum Zielgerät. > Asymmetrischen Routing.Oder dieses HDG nutzt irgendein abnormes Protokoll. Ich kenne es leider nicht. Allgemeine Lösungsmöglichkeiten dafür habe ich schon angeführt. Ohne zu wissen, was tatsächlich mit den Paketen schief läuft, kann ich nichts besseres liefern.
-
Das ist asym. routing, der Filter killt so was, da es keinen State gibt.
Ohne Filter ist die Sense ein reiner Router und dem ist es egal ob die Antwort von einer anderen IP kommt, als die an die die Anfrage eigentlich raus ging.Genau um so was zu vermeiden, immer ein Transfernetz verwenden.
-
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
-
Das Problem ist gelöst! Ich hatte versehentlich das NAT auf der pfsense eingeschaltet. Ausgeschaltet und alles funktioniert wie es soll.
Danke für Eure Mühe und Unterstützung!Viele Grüsse, ralhue
