default deny rule blockt trotz any any Regel

[JeGr]

@viragomann Dann hab ich das mißverstanden, sorry

[ralhue]

Hier mal mein Testaufbau:

[viragomann]

@ralhue
Was ist die Kiste links oben mit den statischen Routen? Der Upstream Router?

[ralhue]

@viragomann Fritzbox

[viragomann]

@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.

[JeGr]

@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

[viragomann]

@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.

[ralhue]

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

[viragomann]

@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.

[NOCling]

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.

[ralhue]

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

[ralhue]

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