12
PfSense default deny rule IPv4
Hallo 
1. Ich beschäftige mich gerade mit meinen Reolink-Kameras.
2. Diese haben einen Push-Service (P2P via UDP), der nach Firmware-Updates nicht mehr funktioniert. Das war abzusehen, da dieser Service ohne UID seitens Reolink angekündigt wurde.
3. Auf den folgenden Bildern seht ihr meine Regeln für das Kamera-VLAN und einen Auszug aus dem Logfile.
- Info zu Alias "Reolink_P2P_Server": enthält nur die IP: 15.188.197.53 (die geblockt wird).
- Zusätzlich habe ich pfBlocker mit einigen Filtern und Geo-Blocks aktiv.
4. Da aber die Regel "Default deny rule IPv4 (1000000103)" blockiert, wollte ich kurz höflich fragen, wo ich diese Regel finde beziehungsweise wo ich das ändere.
5. Danke für jeden Tipp.
1. Ich beschäftige mich gerade mit meinen Reolink-Kameras.
2. Diese haben einen Push-Service (P2P via UDP), der nach Firmware-Updates nicht mehr funktioniert. Das war abzusehen, da dieser Service ohne UID seitens Reolink angekündigt wurde.
3. Auf den folgenden Bildern seht ihr meine Regeln für das Kamera-VLAN und einen Auszug aus dem Logfile.
- Info zu Alias "Reolink_P2P_Server": enthält nur die IP: 15.188.197.53 (die geblockt wird).
- Zusätzlich habe ich pfBlocker mit einigen Filtern und Geo-Blocks aktiv.
4. Da aber die Regel "Default deny rule IPv4 (1000000103)" blockiert, wollte ich kurz höflich fragen, wo ich diese Regel finde beziehungsweise wo ich das ändere.
5. Danke für jeden Tipp.
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: 11267625483
Url: https://administrator.de/contentid/11267625483
Printed on: April 29, 2024 at 23:04 o'clock
12 Comments
Latest comment
Moin,
6. Deine Anhänge (Bilder und Logfiles fehlen)
7. Eine "Default deny Rule" ist ein sog. implizites deny, d.h. eine Regel die dann greift, wenn vorher keine andere Regel den Traffic erlaubt hat. Bei "anständigen" Firewalls ist das immer die letzte Regel in der Chain und nicht veränder-/deaktivierbar.
lg,
Slainte
6. Deine Anhänge (Bilder und Logfiles fehlen)
7. Eine "Default deny Rule" ist ein sog. implizites deny, d.h. eine Regel die dann greift, wenn vorher keine andere Regel den Traffic erlaubt hat. Bei "anständigen" Firewalls ist das immer die letzte Regel in der Chain und nicht veränder-/deaktivierbar.
lg,
Slainte
Klassiker :D
Als ich die Fotos gepostet habe, hab ich es bemerkt :/
das kleine ! bei Reolink_P2P_Server íst weg....
Ich habe unabsichtlich "Invert match" aktiviert gehabt...
Habe jetzt keinen Block in der Logfile mehr, aber der Push Dienst funktioniert noch immer nicht
das kleine ! bei Reolink_P2P_Server íst weg....
Ich habe unabsichtlich "Invert match" aktiviert gehabt...
Habe jetzt keinen Block in der Logfile mehr, aber der Push Dienst funktioniert noch immer nicht
Mahlzeit.
Was sagt denn ein Paket-Mitschnitt auf der PFSense und anschließender Analyse in Wireshark?
Gruß
Marc
Was sagt denn ein Paket-Mitschnitt auf der PFSense und anschließender Analyse in Wireshark?
Gruß
Marc
Zitat von @hell.wien:
Habe jetzt keinen Block in der Logfile mehr, aber der Push Dienst funktioniert noch immer nicht
Der Push Dienst verwendet eine andere Domain pushx.reolink.comHabe jetzt keinen Block in der Logfile mehr, aber der Push Dienst funktioniert noch immer nicht
Und für PnP mehrere Domains
p2p(1-15).reolink.com Port 9999 UDP
1
Nur nebenbei: mDNS zu blocken ist unsinnig, denn das sind bekanntlich Link Local Multicast Adressen mit einem TTL von 1 die so oder unroutebar sind.
Abgesehen davon wird Multicast Traffic generell durch die Firewall geblockt sofern die "IP Options" in den Advanced Settings des Ruleset nicht aktiviert sind was im Default nicht der Fall ist.
Diese überflüssige Regel kannst du also getrost löschen.
OT: Wie man mDNS handhabt auf der pfSense erklärt dieser Thread.
Abgesehen davon wird Multicast Traffic generell durch die Firewall geblockt sofern die "IP Options" in den Advanced Settings des Ruleset nicht aktiviert sind was im Default nicht der Fall ist.
OT: Wie man mDNS handhabt auf der pfSense erklärt dieser Thread.
Anfangs war nur die 15.188.197.53 in der Log, kurz darauf die 35.180.44.63, also dachte ich das sind die P2P Push Server.
Also müsste es ausreichen wenn ich in der Aliases Liste pushx.reolink.com eintrage ausreichen oder?
@aqui. Dich würde ich mal am liebsten einen Tag einladen das du dir meine Firewall/Netzwerk ansiehst :D
Ich glaub ich hab damals diese Regel erstellt weil in diesem VLAN die Chinesen Hausen... Aber so ganz genau weiss ich das nicht mehr warum es diese gibt
Also müsste es ausreichen wenn ich in der Aliases Liste pushx.reolink.com eintrage ausreichen oder?
@aqui. Dich würde ich mal am liebsten einen Tag einladen das du dir meine Firewall/Netzwerk ansiehst :D
Ich glaub ich hab damals diese Regel erstellt weil in diesem VLAN die Chinesen Hausen... Aber so ganz genau weiss ich das nicht mehr warum es diese gibt
Guten Morgen,
ich muss mich leider nochmal an euch melden.
Habe vorhin mal eine Allow Any Regel erstellt, trotzdem greift noch immer die Default deny rule IPv4 (1000000103) Regel und Blockt.
Hat das vielleicht mit der folgenden Error zu tun?
Danke und einen schönen Sonntag
ich muss mich leider nochmal an euch melden.
Habe vorhin mal eine Allow Any Regel erstellt, trotzdem greift noch immer die Default deny rule IPv4 (1000000103) Regel und Blockt.
Hat das vielleicht mit der folgenden Error zu tun?
Danke und einen schönen Sonntag
Was bitte sehr ist eine "(1000000103) Regel"??? 🤔
Und die Fehlermeldungen lassen nichts Gutes erahnen.
Memory Allocation Error klingt eher nach was deutlich Gravierendem im Backend....
Flash löschen und FW neu aufsetzen...
Und die Fehlermeldungen lassen nichts Gutes erahnen.
Memory Allocation Error klingt eher nach was deutlich Gravierendem im Backend....Flash löschen und FW neu aufsetzen...
Damit meine ich das oben genannte Problem…
Durch die Scheunentor Rule dürfte ja eigentlich nichts mehr geblockt werden. Kommt mir komisch vor.
Das klingt gar nicht gut 🫨 (im Moment nicht machbar, bin in Ausland)
Was könnte so einen Fehler verursachen? Kann pfBlocker Ng der Grund sein?
Durch die Scheunentor Rule dürfte ja eigentlich nichts mehr geblockt werden. Kommt mir komisch vor.
Das klingt gar nicht gut 🫨 (im Moment nicht machbar, bin in Ausland)
Was könnte so einen Fehler verursachen? Kann pfBlocker Ng der Grund sein?
Scheunentor Rule hast du ja nicht, das wäre "any any". Du erlaubst lediglich alles was an IP Traffic von 192.168.30.13 kommt. Gut, wenn das dein einziger Host in dem Segment ist hat das natürlich den gleichen Effekt.
Geblockt kann dann nur noch etwas werden was der pfBlocker im Hintergrund dynamisch adaptiert. Somit könnte das in der Tat ggf. der Fehler sein.
Was sagt denn das Blocking Log?
Dennoch sollten dir die Memory Allocation Fehler schwer zu denken geben. Normal ist sowas nicht.
Geblockt kann dann nur noch etwas werden was der pfBlocker im Hintergrund dynamisch adaptiert. Somit könnte das in der Tat ggf. der Fehler sein.
Was sagt denn das Blocking Log?
Dennoch sollten dir die Memory Allocation Fehler schwer zu denken geben. Normal ist sowas nicht.
@aqui: Da hast du recht, ich wollte damit ausdrücken das ich für "Debug" Zwecke den Host (Kamera) alles erlaube...
Welche Blocking Log meinst du jetzt? Status/System/Logs/Firewall/Normal View (filter: 192.168.30.13)?? oder Allgemein?
Die bleibt mit gesetzten Filter leer. Dürfte also nichts mehr Blocken.
In den Rules sehe ich das es einen State gibt:
VIDEOUEBERWACHUNG udp 192.168.30.13:38547 -> 35.180.44.63:58200 MULTIPLE:MULTIPLE 15 / 3 3 KiB / 507 B
aber Funktionieren tut es trotzdem nicht
Hab schon etwas länger immer wieder diesen Memory Allocation Fehler, vl drehe ich mal pfBlocker NG komplett aus. Um es einzugrenzen, dann sehen wir weiter.
Reicht es dazu aus unter Firewall/pfBlockerNG/ pfBlockerNG Enable auf OFF stelle?
Eigenartigerweise kann ich meine Fw nicht auf die neuerste Version Updaten:
Des weiteren habe ich zu diesem Wert eine frage? Würde es helfen den FW Maximum Table Entries zu verändern?
Welche Blocking Log meinst du jetzt? Status/System/Logs/Firewall/Normal View (filter: 192.168.30.13)?? oder Allgemein?
Die bleibt mit gesetzten Filter leer. Dürfte also nichts mehr Blocken.
In den Rules sehe ich das es einen State gibt:
VIDEOUEBERWACHUNG udp 192.168.30.13:38547 -> 35.180.44.63:58200 MULTIPLE:MULTIPLE 15 / 3 3 KiB / 507 B
aber Funktionieren tut es trotzdem nicht
Hab schon etwas länger immer wieder diesen Memory Allocation Fehler, vl drehe ich mal pfBlocker NG komplett aus. Um es einzugrenzen, dann sehen wir weiter.
Reicht es dazu aus unter Firewall/pfBlockerNG/ pfBlockerNG Enable auf OFF stelle?
Eigenartigerweise kann ich meine Fw nicht auf die neuerste Version Updaten:
Des weiteren habe ich zu diesem Wert eine frage? Würde es helfen den FW Maximum Table Entries zu verändern?
