Firewall Inter VLAN einzelner port

[2ramiro]

Hallo
Ich habe in meiner Firewall fuer VLAN 20 zugriffe auf die IP 192.168.178.32 und Port 1883 in einem anderem VLAN zugelassen, die Verbindung funktioniert auch nur sind in dem LOG viele Meldungen das die Verbindung blockiert wurde.

Habe ich die Rule falsch erstellt weil die Meldungen sollten doch eigentlich nicht da sein?

Danke
Ramiro

[meyergru]

Schau Dir mal die Details der geloggten Pakete an, es könnte sein, dass die TCP-Flags nicht passen, speziell, wenn die MQTT-Devices fehlerhaft implementierte Stacks haben. Dann könnte man mit advanced options diese Pakete auch durchlassen (oder filtern und ohne Logging wegwerfen).

[2ramiro]

Bei tcpflags steht PA und RA , sollte das Flag nicht egal sein wenn man unter Advanced nichts definiert hat ?

[meyergru]

Ich würde mal mit "state type" spielen...

[2ramiro]

Habe jetzt einfach das Protokoll auf TCP umgestellt und bei TCP flags Any flags angekreuzt jetzt sind die melden weg und die Geraete zeigen auch nicht mehr an das sie sich dauernd neu verbinden , hat das irgendwelche nachteile Any flags zu setzen ?

[meyergru]

In der Theorie könnte jemand jetzt TCP-Pakete vom VLAN 20 (vermutlich IoT-Netz?) ins LAN außer der Reihe senden, aber wie wahrscheinlich ist das schon?

Man könnte durch Paket-Traces nachvollziehen, was die MQTT-Clients genau falsch machen und nur dies zulassen, um das weiter einzugrenzen, aber das Risiko ist doch sehr begrenzt.

[JeGr]

Bei tcpflags steht PA und RA , sollte das Flag nicht egal sein wenn man unter Advanced nichts definiert hat ?

Das ruft eher nach entweder asym. Routing oder out of state Traffic. Also Netzwerk/Switch falsch konfiguriert oder lahmer/getimeouteter Verbindung die nicht mitbekam, dass die Verbindung schon zu ist.

Wenn Pakete mit RA/PA/FA oder Kombination FPA/RPA auftauchen, dann allermeistens wegen asymmetrischem Routing. Heißt das Paket kommt auf ner anderen Strecke wieder zurück wie es losgeschickt wird.

Und nein, die Flags sind nicht egal. Die Sense filtert nach S - also SYN - einer Verbindung. Bei SYN match wird ein State erzeugt und danach wird nach State (stateful) gefiltert und erst dann wenn kein State vorhanden ist nach den Regeln geschaut. Deine Pakete matchen aber nicht auf einen State (was schon ein Signal für ist, dass was schief läuft) und kommen mit gesetztem A an - sind also Antworten von etwas, was die Firewall nicht oder nicht mehr kennt.

Wenn sie es nicht oder nicht mehr kennt gibts zwei Möglichkeiten:

* Sie kannte es nie -> asym. Routing -> Netzwerk falsch gebaut
* Sie kannte es aber es ist out of state Traffic - der State wurde also schon beendet und die Pakete hingen irgendwo noch hinterher oder waren Nachzügler -> dann passen sie nicht mehr auf den State und werden verworfen. Aber dann stört es im Normalfall auch nicht.

Der zweite Fall taucht gern mal bei HTTPS oder trägen Verbindungen auf, wenn die Firewall einfach zu "schnell" war das "Fin" zu sehen und den State abgebaut hat, aber irgendwelche WebApps o.ä. Kram noch Keepalives oder Verbindungen versuchen am Leben zu halten die schon abgelaufen sind. Dann taucht mal sowas auf.

Faustregel: Wenn der normale Betrieb sauber läuft, ist es eher #2, wenn statt dessen (fast) nichts ordentlich läuft und man auch SA oder nur A Pakete sieht, dann ist es eher #1 und das Routing "kaputt" bzw. nicht korrekt.

Cheers

[meyergru]

An die Geschichte mit dem Routing hatte ich noch gar nicht gedacht, mein Verdacht für den out-of-state traffic war eher eine fehlerhafte/unvollständige Implementierung des TCP-Stacks auf Embedded Hardware, so was kommt bei MQTT ja schon mal vor.

Könnte es sein, dass da eine zu weit greifende NAT-Regel feuert und die Absenderadressen vom VLAN 20 ins LAN verbiegt?