Seltsame Einträge im Live View

[kosta]

Hallo,
seit einem der letzten Updates scheint so als ob ich seltsame Sachen im Live View habe...
Innerhalb eines Netzwerks (VLAN), ich sehe geblockte Pakete, angeblich ausgehend von der NAS zu den anderen Servern im selben Netzwerk.

Das erste ist, dass die Pakete wiederholende Ports haben:
796, 798, 979 und 302.
Das zweite eben, warum sollen die Pakete innerhalb eines Netzwerks überhaupt über die Firewall gehen wollen?

Im anderen VLAN (Management), habe ich meine Geräte wie Switches und Unifi... hier sehe ich auch seltsame Sachen wie Access Point versucht auf Controller zuzugreifen, obwohl ein Rule existiert der sagt eben TCP/UDP Alias Unifi_Devices Source->Dest. Port ist 8080, allerdings im Rule ist eben Any.

Firewall Optimization ist "normal" und "Firewall Rules Optimization" basic, aber es spielt keine Rolle was dort ausgewählt ist...

Was man so sieht wenn man auf "i" klickt:
Detailed rule info
__timestamp__   Jun 6 20:35:37
ack   3176213742
action    [block]
anchorname   
datalen   84
dir    [in]
dst   server-ip
dstport   979
ecn   
id   21465
interface   igb0_vlan110
interface_name   V110_Servers
ipflags   DF
label   Default deny rule
length   136
offset   0
proto   6
protoname   tcp
reason   match
rid   02f4bab031b57d1e30553ce08e0ec131
ridentifier   0
rulenr   22
seq   2968604717:2968604801
src   nas-ip
srcport   2049
subrulenr   
tcpflags   PA
tcpopts   
tos   0x0
ttl   64
urp   155
version   4

Kann man wissen was das ist?

[kosta]

Mittlerweile habe ich herausgefunden dass der NAS ausgehende Port 2049 auf NFS hinweist...
Allerdings verstehe ich noch immer nicht, warum die Firewall das blockt (oder false positive?) innerhalb des gleichen Netzwerks.

Ideen?

[JeGr]

Da unnötigerweise potentiell private IPs die eh keine Aussagekraft haben zensiert wurden, kann man den Kram nicht wirklich analysieren weil man nicht sieht, wer mit wem versucht zu reden. Bei TCP Flags mit PA sieht das nicht so aus, als wären das Verbindungsversuche, sondern eher laufende Kommunikation die fehl geht oder via/an Adressen, wo sie nicht hin soll. Routing o.ä.

So kann man eben nicht viel dazu sagen.

[kosta]

Ist irgendwie öd... hast nen Live View die man aber nicht wirklich sauber verwenden kann. Oder sehe ich das falsch?
Vor allem, warum passiert es jetzt ausgerechnet, und nie früher?

OK, also was soll ich deines Erachtens nach damit machen? Ist es ein Bug?

[lfirewall1243]

Ist irgendwie öd... hast nen Live View die man aber nicht wirklich sauber verwenden kann. Oder sehe ich das falsch?
Vor allem, warum passiert es jetzt ausgerechnet, und nie früher?

OK, also was soll ich deines Erachtens nach damit machen? Ist es ein Bug?

Liegt daran, dass du mit Aliasen arbeitest.

Mach doch mal ein Scrennshot der Liveview übersicht sowie von den Details des gleichen Eintrages. Dann haben wir wenigstens die IPs schonmal

[kosta]

Liegt daran, dass du mit Aliasen arbeitest.

Wie das? Was hat das mit Aliasen zu tun?

Screenshot ist da. Bemerke nur dass ich ein Logging Rule "Final Deny Rule" da hab, dieser an ist. Das Verhalten ist gleich mit oder ohne dem Rule.

[lfirewall1243]

Liegt daran, dass du mit Aliasen arbeitest.

Wie das? Was hat das mit Aliasen zu tun?

Screenshot ist da. Bemerke nur dass ich ein Logging Rule "Final Deny Rule" da hab, dieser an ist. Das Verhalten ist gleich mit oder ohne dem Rule.

Jetzt passt es. Kann es sein das du beim ersten Screenshot oder den Infos den Haken "Lookup Hostnames" gesetzt hattest?

Jetzt bitte noch einen Netzwerkplan damit man auch versteht wie das was angeschlossen ist. Scheint ja VLAN Traffic zu sein.

[kosta]

Ich hab's manchmal an, aber spielt doch keine Rolle... ich habe im Eröffnungsthread nas-ip server-ip "anonymisiert"... ist aber egal...

Was meinst du mit jetzt passt es?

[lfirewall1243]

Ich hab's manchmal an, aber spielt doch keine Rolle... ich habe im Eröffnungsthread nas-ip server-ip "anonymisiert"... ist aber egal...

Was meinst du mit jetzt passt es?

Jetzt sehen wir die IPs
Und wenn du es an schaltest und uns einen Screenshot schickst spielt es eine Rolle, da wir nix daraus lesen können.

[kosta]

Passt, würde eh keine FQDNs wollen, IP reicht ;-)

PA ist doch Push/ACK, korrekt?

[franco]

Ich vermute mal es ist das gleiche Thema wie immer: Pakete die nicht auf die Firewall gehören werden von einer "Default" Regel abgewiesen weil diese keinen Eintrag in der Statustabelle haben als gültige Sequenzpakete.


Grüsse
Franco

[kosta]

Pakete die nicht auf die Firewall gehören

Kannst du mir das bitte kurz mal erklären, welche Pakete bzw. wann gehören diese nicht auf eine Firewall?

[franco]

Das zweite eben, warum sollen die Pakete innerhalb eines Netzwerks überhaupt über die Firewall gehen wollen?

Ich bin verwirrt über die letzte Frage nach dem Lesen des Beitrages.


Grüsse
Franco

[kosta]

Soweit ich weiß, gehen die Pakete über eine Firewall nur dann, wenn sie auch in das andere Netz geschickt werden... bspw. aus dem 192.168.110.0/24 ins 192.168.120.0/24, über Gateway 192.168.110.254 in meinem Fall.
Da aber die Pakete offensichtlich gar nicht das Netz verlassen:
192.168.110.101 -> 192.168.110.6, gehen sie gar nicht an die Firewall, sondern direkt über dem Switch.
Daher wundert es mich auch, warum die Pakete auf der Firewall überhaupt ersichtlich werden??

[franco]

Also gut, dafür kann die Firewall erstmal nichts wenn die Pakete dahin gesendet werden. Richtig?

Falls ja dann ist das ja genau das Problem: die Firewall merkt dies und gibt dir die Log Ausgabe.

Ist irgendwie öd... hast nen Live View die man aber nicht wirklich sauber verwenden kann. Oder sehe ich das falsch?

Wie gesagt, der Live View merkt es und zeigt es dir. Verstehe nicht wie das als unbrauchbar gemünzt werden kann.

Vor allem, warum passiert es jetzt ausgerechnet, und nie früher?

Falsches Kabel, Switch Config versemmelt oder ARP Tabelle vollgelaufen. Die Ursache ist letztlich abseits der Firewall zu suchen.

OK, also was soll ich deines Erachtens nach damit machen? Ist es ein Bug?

Schwierige Frage...


Grüsse
Franco