3646038786
Mar 14, 2023
1827
13
1
Pfsense blockiert manchmal ausgehenden Traffic
Hallo,
ich habe eine pfsense-Firewall bei mir zu Hause und hin und wieder wird Traffic ins Internet blockiert.
Beispiel:
In den Regeln habe ich als erste Regel den Zugriff auf das Internet geregelt (siehe folgende Abbildung). Als letzte Regel habe ich eine "Deny all" Regel zum Testen eingebaut, dann sehe ich das schneller ohne Filtern zu müssen. Ansonsten gibts ja das Default Deny, was aber im Prinzip dasselbe macht.
Wie erwähnt kommt es vor, dass die Default Deny und auch meine Deny dann Traffic ins Internet blockiert. Die Internet-Regel nimmt jeden Traffic aus dem lokalen Netz, welcher nicht in einen privaten IP-Adressbereich geht (Class a,b,c) und erlaubt diesen. Der Rest sollte dann über Default Gateway funktionieren und das rausschicken. Da die pfsense ja stateful ist, gibts auch keine Probleme mit dem zurückkommenden Traffic.
Ich habe ansonsten keine Probleme im Netzwerk. Ich merke auch nichts davon, ich sehe es nur im Log.
Hat jemand eine Idee?
ich habe eine pfsense-Firewall bei mir zu Hause und hin und wieder wird Traffic ins Internet blockiert.
Beispiel:
In den Regeln habe ich als erste Regel den Zugriff auf das Internet geregelt (siehe folgende Abbildung). Als letzte Regel habe ich eine "Deny all" Regel zum Testen eingebaut, dann sehe ich das schneller ohne Filtern zu müssen. Ansonsten gibts ja das Default Deny, was aber im Prinzip dasselbe macht.
Wie erwähnt kommt es vor, dass die Default Deny und auch meine Deny dann Traffic ins Internet blockiert. Die Internet-Regel nimmt jeden Traffic aus dem lokalen Netz, welcher nicht in einen privaten IP-Adressbereich geht (Class a,b,c) und erlaubt diesen. Der Rest sollte dann über Default Gateway funktionieren und das rausschicken. Da die pfsense ja stateful ist, gibts auch keine Probleme mit dem zurückkommenden Traffic.
Ich habe ansonsten keine Probleme im Netzwerk. Ich merke auch nichts davon, ich sehe es nur im Log.
Hat jemand eine Idee?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 6369987765
Url: https://administrator.de/contentid/6369987765
Printed on: May 4, 2024 at 22:05 o'clock
13 Comments
Latest comment
Moin,
Schwer zu sagen mit der Übersicht. Zeig doch mal die richtige allow und deny Rule anstatt die Übersicht.
Gruß
Spirit
Schwer zu sagen mit der Übersicht. Zeig doch mal die richtige allow und deny Rule anstatt die Übersicht.
Gruß
Spirit
Hi,
gerne.
gerne.
Welche Adresse steht denn als Source in dem Block? Die wird wohl nicht zu den RFC1918er Adressen gehören.
Das, was ich maskiert habe, ist der Name meines Interfaces. In dem Log-Auszug ist die Quelle eine interne IP-Adresse (Bereich 10.0.0.0 - 10.255.255.255 -> Class A)
Welche IP steht denn nun in dem Block? Der Name des Interfaces spielt ja keine Rolle.
Was genau meinst du mit Block? Den Alias "PrivateIPs"?
Hallo,
Regeln und IP-Adresse sind hier völlig belanglos. Im ersten Bild sieht man im Log rechts "TCP:RA". Dies ist nach meinem Verständnis das ACK zu einer abgebrochenen, also bereits geschlossenen Verbindung und wird deshalb durch die (stateful-)Firewall weggefiltert.
https://www.elektronik-kompendium.de/sites/net/2009211.htm
https://serverfault.com/questions/1008268/what-do-the-following-mean-tcp ...
Viele Grüße, commodity
Regeln und IP-Adresse sind hier völlig belanglos. Im ersten Bild sieht man im Log rechts "TCP:RA". Dies ist nach meinem Verständnis das ACK zu einer abgebrochenen, also bereits geschlossenen Verbindung und wird deshalb durch die (stateful-)Firewall weggefiltert.
https://www.elektronik-kompendium.de/sites/net/2009211.htm
https://serverfault.com/questions/1008268/what-do-the-following-mean-tcp ...
Viele Grüße, commodity
Hi,
das würde Sinn ergeben, ich habe aber auch TCP:PA. Und das würde für mich bedeuten, dass der Client auf eine Anfrage antwortet, oder habe ich das falsch verstanden? Da müsste doch eine Verbindung bestehen, oder?
Danke und LG
das würde Sinn ergeben, ich habe aber auch TCP:PA. Und das würde für mich bedeuten, dass der Client auf eine Anfrage antwortet, oder habe ich das falsch verstanden? Da müsste doch eine Verbindung bestehen, oder?
Danke und LG
Da steht TCP:RA. Ich habs erst über sehen.
Das bedeute tatsächlich eine Antwort auf eine geachlossene session.
Das bedeute tatsächlich eine Antwort auf eine geachlossene session.
1ich habe aber auch TCP:PA
dem ACK geht immer ein Send-Befehl voraus. Wenn also das folgende ACK von der Firewall unterbunden wird, liegt das immer daran, dass die Verbindung weg (korrekt: nicht da) ist. Es ist dabei völlig egal, ob ein Push oder ein Reset, ein Fin oder ein Syn voraus geht. TCP:SA ist z.B. eine Folge von asymmetrischem Routing.Viele Grüße, commodity
2
Als letzte Regel habe ich eine "Deny all" Regel zum Testen eingebaut,
Sinnfrei, denn das ist wie du ja auch schon selber sagst immer Default bei einer Firewall und damit überflüssig zu definieren.welcher nicht in einen privaten IP-Adressbereich geht (Class a,b,c) und erlaubt diesen.
Nur nebenbei: Classes gibt es schon seit 25 Jahren nicht mehr das ist tiefstes Netzwerk Neandertal.https://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing
Wer macht denn bei dir DNS? Wenn das auch die Firewall ist musst du ja zumindestens TCP und UDP 53 auf die FW IP Adresse passieren lassen. Das "kann nicht aufgelöst werden" im Output oben ist ggf. ein Hinweis das dein Regelwerk hier nicht korrekt ist?!
Die geblockte IP ist HTTPS Traffik auf eine Google IP. Hast du ggf. sowas wie pfBlocker-NG am Werk das solche Blocking Rules dynamisch erzeugt?
Das die Firewall etwas wie von Geisterhand eigenhändig blockiert gehört sicher in den Bereich der Märchen.
1
Vielen Dank für die Infos.
Das mit den Google-IPs ist mir tatsächlich auch aufgefallen und dass es ein Gerät im WLAN ist - ein TV-Gerät mit GoogleTV - welcher eigentlich nicht läuft (Standby). Aber das erschien mir für das Problem nicht relevant und gut, eventuell sollte ich glücklich sein, dass der TV Probleme hat im Standby "nach Hause zu telefonieren" :D
Wie genau würdest Du denn die Regel bauen? Einfach lokal net zu wan allow any, weil das automatisch über das default gateway (wan) geht?
Ich lese mir heute Abend mal die Quellen durch
Das mit den Google-IPs ist mir tatsächlich auch aufgefallen und dass es ein Gerät im WLAN ist - ein TV-Gerät mit GoogleTV - welcher eigentlich nicht läuft (Standby). Aber das erschien mir für das Problem nicht relevant und gut, eventuell sollte ich glücklich sein, dass der TV Probleme hat im Standby "nach Hause zu telefonieren" :D
Sinnfrei, denn das ist wie du ja auch schon selber sagst immer Default bei einer Firewall und damit überflüssig zu definieren.
Ja, aber die pfsense zeigt daneben schön so ein "User-Symbol" an und dann sehe ich das sofort bei dem ganzen WAN-Traffic der blockiert wird.Nur nebenbei: Classes gibt es schon seit 25 Jahren nicht mehr das ist tiefstes Netzwerk Neandertal.
https://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing
Ich bin zwar gerade erst aus meinen 20ern raus, aber hier sieht man, dass ich beruflich kein Netzwerk-Spezialist bin :Dhttps://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing
Wie genau würdest Du denn die Regel bauen? Einfach lokal net zu wan allow any, weil das automatisch über das default gateway (wan) geht?
Wer macht denn bei dir DNS? Wenn das auch die Firewall ist musst du ja zumindestens TCP und UDP 53 auf die FW IP Adresse passieren lassen. Das "kann nicht aufgelöst werden" im Output oben ist ggf. ein Hinweis das dein Regelwerk hier nicht korrekt ist?!
Ja das ist eingestellt und funktioniert auch. Aber IP zu Domain ist ja reverse und kann die pfsense nen reverse lookup (korrigiere mich bitte, wenn ich hier mist schreibe, ich kenn nur aus dem Windows-DNS die Reverse-Lookup-Zone).Die geblockte IP ist HTTPS Traffik auf eine Google IP. Hast du ggf. sowas wie pfBlocker-NG am Werk das solche Blocking Rules dynamisch erzeugt?
Ne gar nichts in der Art.Das die Firewall etwas wie von Geisterhand eigenhändig blockiert gehört sicher in den Bereich der Märchen.
Ich glaube das ist bei mir ähnlich wie mit dem Glauben an ein höheres Wesen, welches die Welt erschaffen hat. Wenn man sich Dinge nicht erklären kann, dann muss da eine höhere Macht am Werke sein ;) (no hate)Ich lese mir heute Abend mal die Quellen durch
Es wird hier ja gar kein wirklicher Traffic blockiert. Blockiert werden nur die Antwortpakete zu (aus Sicht der Firewall) schon geschlossenen Verbindungen. Wenn die Firewall ein RST oder FIN+ACK sieht, macht sie halt zu.
Wobei ich nicht weiß, ob die Firewall schon beim ersten RST (oder einseitig erfolgreichem FIN+ACK) selbst schließt und bereits das folgende ACK nicht durchlässt (unwahrscheinlich) oder es sich um Folge-ACKs handelt, die wiederholt wurden (wahrscheinlicher).
Viele Grüße, commodity
Wobei ich nicht weiß, ob die Firewall schon beim ersten RST (oder einseitig erfolgreichem FIN+ACK) selbst schließt und bereits das folgende ACK nicht durchlässt (unwahrscheinlich) oder es sich um Folge-ACKs handelt, die wiederholt wurden (wahrscheinlicher).
Viele Grüße, commodity
