FW Regel blockiert 98% des Traffic und 2% nicht

[AndreK]

Hallo zusammen,

Leider ist mir keine bessere Überschrift eingefallen, aber sie beschreibt das Problem zu 100%.

Kurz zum Aufbau:
Accesspoint -> Standort B -> Routed IPsec VPN -> Standort A -> Accesspointserver

Beim Attachment Regel-ausgehend erlaube ich dem Paket den Weg über den IPSec VPN.
Im Live View ausgehende sehe ich das die Pakete durchgelassen werden.
Ich sehe die Pakete auch auf dem Interface vom IPSec.

Nun kommen die Pakete im Standort A rein und sollen zum Server (Attachment Regel-eingehend).

Allerdings dropt er mir ca 98% der Pakete (Attachment Live View).

Ich verstehe nur nicht warum 
Wenn ich auf der Serverseite mitsniffe sieht der Traffic (auch im Anhang) auch sehr mehrkwürdig aus.
Ich verstehe aber nicht warum.
Aller Traffic den ich sonst durch diesen Tunnel jage funktioniert normal.

Ich habe die Regel auf beiden Seiten auch schon mal gelöscht und neu angelegt.
Hat aber leider nicht geholfen.
Vom Server kann ich den AP auch pingen und ein tracert geht auch sauber durch.

Hatt jemand noch eine Idee?

Gruß Andre

[AndreK]

Hallo zusammen,

Ich habe die Lösung inzwischen selbst gefunden und wollte es kurz mitteilen falls jemand das gleiche Problem hat/bekommt.

Die Accesspoint sind von Ubiquiti UniFi AC PRO. Diese sollen sie am Unifi Controller melden.

Das machen sie über:
a) Broadcast
b) Über einen DHCP Option 43 Eintrag
c) Wenn man auf die AP IP per SSH geht mit set-inform http://ip.of.the.controller:8080/inform

Leider schicken diese APs für das Keepalive und die Verbindungsprüfung einfach nur ACK Pakete.

Dies verwirft die Fiewall natülich, da die Pakete so keinen Sinn ergeben.

Ich habe um das Problem zu beheben in der Regel den State Type auf None gesetzt. Soomit gehen die Pakete durch und die doofen APs und der Controller sind glücklich.

Wer sowas programmiert gehört geprügelt 

Gruß Andre

[JeGr]

Sorry aber stimmt so nicht. Ich hab das als Setup selbst gehabt. In dem Fall als OVPN Tunnel aber Netzwerk Equip im Ausland via VPN an Controller in Zentrale. Die APs senden definitiv nicht einfach Acks. So funktioniert kein TCP Handshake und kein Service nimmt sowas dann einfach an.

Kann ich - da mitgesnifft mit tcpdump - definitiv verneinen. Controller und AP kommunizieren völlig regulär über TCP/IP

Cheers

[AndreK]

Hi,

Kannst du dir gerne live anschauen.
Ist definitiv so. Es war und ist das einzigste Gerät in dem Vlan was Daten senden könnte.

Darum hab ich ja geschrieben wer sowas programmiert gehört geschlagen.
Das dies kein kompletter Handshake ist ist mir wohl bewußt. Darum ging es ja auch.

Darum auch das pcap dabei.

[JeGr]

> Ist definitiv so. Es war und ist das einzigste Gerät in dem Vlan was Daten senden könnte.

Dann hast du IMHO andere Probleme in deinem Netz. Aber ein Gerät sendet TCP(!) NICHT einfach so mal eben als Verbindungsaufbau ein "ACK". Wie gesagt, so funktioniert TCP/IP nicht. Dann hast du ggf. asymmetrisches Routing und der Syn geht irgendwo anders hin und verloren etc. pp. Aber nope, kein Gerät fängt mit Ack zu senden an. Das ist kein TCP und würde nie einen Verbindungsaufbau hinbekommen. Wir reden hier ja nicht von UDP, sondern von einem Protokoll mit 3-Wege-Handshake. Und wenn der nicht zustande kommt, dann gibts auch keine Verbindung. Ergo: Syn, Syn Ack, Ack. Ohne die Reihenfolge passiert nichts. Wenn das nicht passiert würde ich dringend mal weiter untersuchen wo die ursprünglichen Pakete hingehen bzw. was beim Controller ankommt. Denn irgendwas läuft da definitiv falsch.

Daher wie gesagt der Hinweis: suche die anderen Pakete. Wenn die Kisten sich finden, dann müssen die irgendwo sein. Nur mit Ack läufts nicht also müssen beim Con ja irgendwo die Syns angekommen sein, die Frage ist nur woher und warum laufen sie falsch.

Cheers
\jens

[AndreK]

Hi,

Wie TCP/IP funktioniert ist mir wohl bewusst ich betreibe das in nem 5000 Mann Betrieb mit etwas mehr Schnickschnack als meine Sense Bastelei. Die pcaps sind alle von einem Mirror direkt mit dem AP da kann kein Packet wegkommen aus es fällt aus der Leitung 

Um es kurz zu machen. Auch bei einem lokalem Test zeigt der AP das Verhalten (sinnlose ACKs).
Neuen aus der Packung geholt, angeschlossen geht. Ergo defekte Hardware.
Firmware kann ich auschließen, da ich die letzten 10 Firmware's durchgegangen bin.
Mein Verdacht lag erst dort.

Gruß Andre

[JeGr]

Was dann im Endeffekt unterstreicht, was ich gesagt habe - kann nicht sein
Da ich die Dinger hier im Homelab wie auch bei Kunden rumliegen habe, konnte ich da eben klar sagen, dass dem nicht so ist/sein kann. Daher die Nachfrage ob da was falsch abbiegt. Oder wenn alle Stränge reißen eben die HW checken. Oft unwahrscheinlich aber kommt nun wie man sieht doch eben mal vor. Hätte ich jetzt auch nicht gedacht, aber wie man sieht gibt's immer was, was man noch nicht gesehen hat

Aber zur ursprünglichen Frage/Aussage sei nochmals bestätigt: Via Tunnel AP und Switche vor Ort in anderem Land connecten sich ganz brav und legitim via Sense, Tunnel und anderer Sense zum Controller im Mgmt Subnetz und schütteln brav Hände. Die Inform-URL ist zwar manchmal Banane - da geb ich dir recht - weil unklar in den Dokus, aber wenn der Kram sich mal findet, lüppts eigentlich

Aber fein dass es sich gelöst hat