Firewall blocks in die falsche Richtung?!
-
Hallo zusammen,
ich bin nun soweit und habe nun beinahe mein neues VLAN Konzept umgesetzt.
Leider habe ich mit einem speziellen Thema ganz seltsame Firewall Probleme.Das wird jetzt etwas kompliziert zu erklären. Ich hoffe ihr könnt mir folgen
Ich habe einen HomeServer. Ist ne QNAP TVS-672X. Hier laufen diverse Docker Container in internen Docker Netzen direkt am Host. Zusätzlich laufen noch 2-3 VMs. Eine davon ein Win2022er Server als VeeamBackupRepo und Management Server. Mein Plan wäre gewesen diese VM direkt im Client VLAN (102) laufen zu lassen damit ich den Backuptraffic nicht durch die FW verwurschten muss. Also auf QNAP nen eigenen vSwitch samt eigenem Interface angelegt und die VM dorthin angebunden. Am Managed Switch den QNAP-Switchport als Untagged VLAN (native) auf das entsprechende VLAN 102 eingestellt.
Grundsätzlich funktioniert es auch. Die VM bekommt über den pfSense DHCP die von mir reservierte IP.Nun aber das wirklich Seltsame. Der Veeam Server braucht ne SQL-Verbindung zum Homeserver, welcher auf TCP 1433 anliegt (Docker container mit entsprechendem Hostport mapping). Von meinem PC aus komm ich da auch hin.
Doch sobald die VM nicht mehr im selben Netz wie der HomeServer ist bekomm ich keine SQL-Verbindung mehr zu Stande.Die FW-Logs ergeben für mich mehrfach keinen Sinn.
- Bin ich es gewohnt, dass ich die FW-Rules basierend des Session Initiators einrichten muss. Hat bis jetzt auch überall so funktioniert. Aber warum schaut es dann hier so aus, also ob der Retourweg von SQL-Server (1433) zum Client Highport blockiert wird.
- Selbst wenn dem so wäre. Am LAN Interface ist ne IPv4 Any Any Pass Rule (Die netgate default Rule für LAN). Da dürfte die default deny IPv4 überhaupt nicht anspringen.
Hier noch mal mein LAN Konzept. Einfach dem dicken roten Pfeil folgen. Das will ich...
Bitte nicht schimpfen. Ich bin echt unfähig beim Zeichnen dieser Diagramme
-
Folge den Paketen mit einem Traceroute, du hast hier asymmetrische Routen und das mag eine Firewall gar nicht.
-
@n300 said in Firewall blocks in die falsche Richtung?!:
Die FW-Logs ergeben für mich mehrfach keinen Sinn.
Es werden Pakete mit Flags "SA" geblockt, SYN+ACK. Also Antworten von einem Dienst der angefragt wird. Die kommen nicht korrekt auf der Firewall an, weil irgendwo was gehörig schief läuft. Daher mal ganz genau das Routing prüfen, hier geht eine Verbindung definitiv nicht den gleichen Weg hin wie zurück, dadurch kommen Pakete außerhalb ihres normalen States auf der Firewall an - die dann keine aktive Verbindung / State dazu erkennt (stateful inpsection) und die dann blockt, weil sie keine NEUE Verbindung aufmachen, sondern auf eine antworten, die nicht von ihr genehmigt wurde. Daher sind das keine Regelprobleme sondern Routingprobleme dass du hier nicht die korrekten Gateways an den entsprechenden Rechnern nutzt.
Cheers
-
Ok, das erklärt es. Ich verdächtige hier ganz stark den Netzwerkstack von QNAP. Habe es gestern schon 2x geschafft mich netzwerktechnisch komplett aus der QNAP auszusperren, weil es leider ein echter Krampf ist das Ding für multiple VLANs zu konfigurieren.
Die "Problem"-VM läuft auf der QNAP, der SQL Server ist ein Docker-Container auf derselben QNAP. Dazwischen wäre auf Grund der unterschiedlichen Netzsegmente die pfsense. Aber ich habe den Verdacht, dass die VM warum auch immer irgendwie Intern im QNAP Netzwerkstack abbiegt anstatt über die Firewall zu gehen. Lustigerweise schaut der traceroute aber sauber aus. Auch pingen kann.
Auf großen Hypervisoren wie ESXi, wie wir sie in der Firma haben ist das alles kein Problem (multi VLAN) und konzepttechnisch hätte ich mich auch daran angelehnt. Aber der vSwitch im QTS ist da anscheinend hald doch eher Spielzeug. -
@n300 said in Firewall blocks in die falsche Richtung?!:
Aber ich habe den Verdacht, dass die VM warum auch immer irgendwie Intern im QNAP Netzwerkstack abbiegt anstatt über die Firewall zu gehen
Sieht so aus. Die Paket von der VM zum SQL-Server scheinen direkt am QNAP zu laufen (oder über den erwähnten Managed Switch, der nicht Teil der Grafik ist), in die anderes Richtung gehen sie aber über die Firewall, wie es sein sollte. Die weiß aber nichts von dem SYN Paket und lässt den Rest der Verbindung auch nicht zu.
Die Ursache des Problem wäre also für mich am QNAP oder am Managed Switch zu suchen. Du könntest die Pakete an den beteiligten Interfaces sniffen, um es rauszufinden.
Ansonsten gäbe es vielleicht Workarounds:
- Am LAN einen Firewall Pass Regel für Source IP QNAP und Port 1433 und Ziel any (oder nach Bedarf) anlegen und in den Advanced Options "Sloppy" State type einstellen. (kenn ich nur aus der Theorie, hatte ich noch nie benötigt )
- Den SQL Traffic über die Firewall natten. Also die pfSense IP als Ziel für den SQL Client einrichten und auf der pfSense ein Port Forwaring zum SQL-Server setzen.
-
Nun hab ich's glaub ich. Die Config auf QNAP Seite war Murks.
Hab nun den LACP Trunk wieder aufgehoben und die Interfaces aufgeteilt. Eines der beiden 1Gbit IFs ist nun im sogenannten Management Netz (192.168.178.0/24). Das war bis jetzt mein Netz für Alles. Nur die QNAP selbst und die Management-IPs der Switches usw. sollen im Endausbau dort bleiben.
Das 10Gbit Interface der QNAP hab ich nun als DMZ-NIC deklariert. Mit derzeit einem Tag für VLAN102. Das soll mein internes LAN/WLAN werden. Man kann bei der QNAP pro Interface angeben, welche Dienste darüber erlaubt werden. Hab hier zum einen meinen VeeamServer wieder angebunden und werde auch CIFS, SFTP usw. freischalten. Auf die ganzen Management Dienst (QTS-Desktop, SSH, ...) wird man über diese IP nicht kommen.So schaut das im QTS jetzt aus:
Übrigens stimmts, die Switches hab ich im Netzwerkdiagram gar nicht eingezeichnet. Sind 2 Ubiquiti Edgemax (24 Port + 8 Port PoE).
Derzeit ist die Firewall partiell für bestimmte IPs noch recht offen zwischen den VLANs. Aber das werde ich nach und nach noch nachschärfen. Will mich ja nicht gleich von Vornherein aussperren
Die beiden großen Performance-Posten CIFS u. Veeam Backup Traffic fahre ich bewusst zumindest für mein internes (trusted) LAN an der pfSense (netgate 2100 Appliance) vorbei.
Leider hab ich noch keine 10Gbit Infrastruktur, somit verschenke ich beim 10Gb Port der QNAP. Aber ordentliche L3 10G Switches sind leider noch teuer und was mich noch mehr stört, haben die meistens gleich mehrere dieser äußerst lästigen Quirl-Lüfter. Das Zeug steht genau neben mir. Das ist mir zu laut
Hoffe da tut sich in Zukunft noch was. -
@n300 said in Firewall blocks in die falsche Richtung?!:
weil es leider ein echter Krampf ist das Ding für multiple VLANs zu konfigurieren.
Stimmt leider.
@n300 said in Firewall blocks in die falsche Richtung?!:
Auf großen Hypervisoren wie ESXi, wie wir sie in der Firma haben ist das alles kein Problem (multi VLAN) und konzepttechnisch hätte ich mich auch daran angelehnt. Aber der vSwitch im QTS ist da anscheinend hald doch eher Spielzeug.
Ich hatte mich daran auch versucht und im Endeffekt gesehen/in Videos mitbekommen, dass die meisten dann doch alles irgendwie per Hand auf der Konsole konfigurieren weil über die UI nicht richtig machbar und echtes "bridging" in VLANs nicht sauber geht. War mir dann ein zu großes Gefrickel und ich hab einfach TrueNAS auf dem Ding ausprobiert und seither nicht bereut. Gut, habe jetzt dadurch keine "echte VM" Möglichkeit drauf aber hatte eh nur Container und LXC in der Planung. Das klappt dafür bislang sehr fein und wie erwartet auch im Routing.
@n300 said in Firewall blocks in die falsche Richtung?!:
Aber ordentliche L3 10G Switches sind leider noch teuer und was mich noch mehr stört, haben die meistens gleich mehrere dieser äußerst lästigen Quirl-Lüfter. Das Zeug steht genau neben mir. Das ist mir zu laut
Hoffe da tut sich in Zukunft noch was.Oh I feel you so bad ;)
Aber nettes Setup :)
-
Ich musste nun doch dem DMZ-Switch (QNAP) wieder die IP-Adresse wegnehmen. Das hat schon wieder zu asymetrischem Routing geführt. Spricht man die IP hinter der Firewall an, kommt die Antwort gerne mal über die VIP am DMZ-Switch (an der Firewall vorbei) und schon flapped es wieder. Schade eigentlich.
Aber nur halb so wild. Mit CIFS über die netgate bekomm ich das GBit recht gut ausgelastet, dabei geht einer der beiden CPU-Cores auf ca. 75% load. Der 2. Core bleibt wo er war.
Vielleicht bekomm ich das mit der QNAP noch hin. Über "ip rules" auf der CLI sollte da vielleicht noch was gehen. Hab mich aber noch nicht hinreichend dazu eingelesen.
-
@n300 Hatte da irgendwie ein Video zu gefunden mit VLAN setup für Container/Docker etc. auf der CLI, dort wurde das ganz gut abgehandelt, dass die UI da einfach Murks macht und die Dinge, die man braucht nicht zulässt und wie derjenige es dann auf der Console hinkonfiguriert. Vielleicht findest du das auch - war eigentlich recht gut gemacht, kam aber erst so bei ca. 2/3 des Videos.