Internet Zugang für Amazon Kindle blockieren

sohei

@mike69 Danke, die Einstellung funktioniert - der Kindle kommt nicht mehr ins Internet. Aber leider funktioniert auch die interne Nextcloud Server synchronisation nicht mehr. Aber ich denke das kann auch irgendwo anders liegen - wenn ich im Terminal den DNS Namen des NetCloud Servers pinge, dann kriege ich als IP Adresse 172.16.1.100 zurück. Das würde darauf hin deuten, dass die Netzwerk Kommunikation funktioniert :)

Vielen Dank - Ich suche nun mal weiter ... hauptsache der Kindle kommt nicht mehr ins Internet.

Gruss
Sohei

mike69

@sohei

Greift das Kindle den NC Server per IP zu?

Mit der Deny Rule hat das Kindle kein Zugriff mehr auf die Sense, weil die Sense hinter dem LAN Interface sitzt und die Rules direkt an der Schnittstelle abgearbeitet werden.
Falls das Kindle den Nextcloud per DNS Name zugreift, musst du die DNS Abfrage an die Sense erlauben.
Also ein "allow ipv4 udp kindle-ip * LAN Address DNS * none" vor der Block Rule erlaubt die DNS Abfragen, danach wird der Kindle geblockt.

So ungefähr:

sohei

@mike69 Vielen Dank - an das habe ich danach auch gedacht und habe folgende Konfiguration nun erfolgreich am Laufen:

alt text

mike69

@sohei said in Internet Zugang für Amazon Kindle blockieren:

@mike69 Vielen Dank - an das habe ich danach auch gedacht und habe folgende Konfiguration nun erfolgreich am Laufen:

Was ist 172.16.1.100, die Sense?

sohei

@mike69 Das ist der NC Server - der Kindle muss nur auf diesen zugreifen können.

mike69

@sohei said in Internet Zugang für Amazon Kindle blockieren:

@mike69 Das ist der NC Server - der Kindle muss nur auf diesen zugreifen können.

Rules greifen nicht im gleichen Subnet.
Kindle schickt über den AP --> Lankabel --> Switch --> Lankabel --> NC Server die Pakete und der NC Server seine auf der gleichen Strecke zurück. Deine erste Rule ist nicht nötig, weil die Sense die Pakete nicht sieht. :)

NOCling

Baue die Regel doch einfach wie folgt auf.

Wenn du die ganz RFC1918 nicht anlegen willst, reicht auch hier dein internes netz, wichtig ! für invertieren.

Dann kommt die Kiste an alles im LAN ran, aber an nix anderes.

JeGr

OK ich lese hier aber einige kritische Sachen, sorry daher fürs Einmischen, aber das muss mal ausgefiltert werden, damit sich das nicht erst irgendwo einprägt:

@fireodo said in Internet Zugang für Amazon Kindle blockieren:

Was passiert wenn hier anstelle von "any" als destination dein "wan" stehen würde?

@fireodo WAN ist NIEMALS das Internet. Bitte ganz dringend merken. WAN Interface ist die IP Adresse der pfSense auf WAN Seite. Macht sie PPPoE ist das ne Public IP. Wenn davor ein anderer Router hängt ist das eine private IP. Genauso WAN_network: Das ist NICHT das Internet (sonst würde es so heißen!), sondern NUR das Subnetz, in welchem pfSense' WAN IP liegt. Ist das PPPoE und eine Public IP, kann das irgendein öffentliches /22, /23 oder /24 Netz sein, je nach ISP. Hinter einer Fritzbox bspw. ist es normalerweise ein 192.168.178.0/24. Egal was davon zutrifft, WAN address oder WAN network braucht man im Normalfall NUR in spezifischen Regeln wenn man bspw. die externe IP der Sense blockieren möchte (von innen bspw.) o.ä.
Für Freigaben von "Internet" oder nicht, hat das aber keinerlei Relevanz :)
Nicht böse gemeint, aber der Fehler taucht immer und immer und immer wieder auf und es hält sich hartnäckig!

Bei den meisten anderen Punkten hat ja @mike69 schon korrekt interveniert ;) Wenn ein Gerät im gleichen Subnetz (wie der Kindle mit der Nextcloud oder einem PC o.ä.) spricht, ist die Sense nicht involviert da das nie geroutet wird. Routing ist wie Straßenschilder, wenn man von Ort A (LAN) nach Ort B (anderes Subnetz/WAN/Internet) fahren will. Dann brauchst du im Auto (das Paket) ein Straßenschild für die richtige Route. Solang du aber im gleichen Ort rumfährst, wird keine Route gebraucht, du bleibst ja im gleichen Netz. Erst wenn du woanders hin fährst, brauchts die Routenführung :)

@mike69 Vielen Dank - an das habe ich danach auch gedacht und habe folgende Konfiguration nun erfolgreich am Laufen:

Was Mike schon richtig geschrieben hat: die erste Regel ist wegen obiger Erklärung überflüssig. EINZIGE Ausnahme dafür wäre, wenn der NC Server über einen DNS Namen angesprochen wird, der auf die externe IP der Sense auflöst und dann via NAT Reflection wieder auf die lokale 172er IP umgebogen wird. DANN und nur dann kommt die Situation zustande, dass man Regeln hat/braucht, die vom Netz ins gleiche Netz Traffic erlauben, weil das Paket erstmal zur pfSense geht in Suche nach der ext. IP, dort umgeschrieben wird auf die interne und wieder rausgeht in das Netz wo es herkam. Das ist höchst ungewöhnlich für einen Router, daher gibt dafür extra Settings in Systems/Advanced bzgl. NAT Reflection und passthrough von Traffic auf dem gleichen Interface wo er reinkam.

Anyway es wird wohl eine Kombination sein aus DNS war/ist nicht erreichbar (da keine Regel jetzt dem Kindle erlaubt, dass er die pfSense via DNS/NTP ansprechen darf) und etwas von der Nextcloud was noch schief liegt.

Korrekt wäre statt der ersten Regel eine <kindle_ip> zu <lan_address> Port DNS (für Typ TCP/UDP, nicht any), dann darf der Kindle DNS machen und ggf. klappts dann auch mit der Nextcloud :)

@sohei
Eine Frage aus Neugier: was ist das für ein Kindle und warum darf der auf KEINEN Fall ins Internet und nur Lokal irgendwelche Daten abrufen?

sohei

@jegr Hallöchen

Vielen Dank für Deine ausfürhliche Antwort. Ich habe jetzt die egel folgendermassen geändert, denke aber das es noch nicht die von Dir vorgeschlagene Lösung ist.

alt text

Vielleicht ist es auch gut, wenn ich meinen kompletten Aufbau und mein Ziel beschreibe - das erklärt auch, warum der Kindle nicht ins Internet darf/soll.

Also, ich betreibe einen NextCloud Server, welcher per öffentlicher IP Adresse erreichbar ist. Die pfSense hat dabei mehrere fixe IP Adresse hinterlegt und leitet mit Regeln den Internetzugriff auf die diversen Server weiter (Mail, Web, NextCloud usw).

Die pfSense ist gleichzeitig der DNS Server in dieser Konstellation - heisst wenn ich von ausserhalb meinen Nextcloud Server anpinge, dann erhalte ich Antwort von der öffentlichen IP Adresse, wenn ich von intern anpinge, dann erhalte ich die 172.16.1.100 Adresse. Auf diesem Nextcloud Server sind unter anderem mein Kalender, meine Kontakte, Notizen usw gespeichert. Der Kindle selbst hat bei mir nicht die primäre Aufgabe das ich darauf lesen will, sondern wurde von mir softwaretechnisch so verändert, dass er mir als Tablet dient um Kalender und Notizen darzustellen und zu erfassen. Da der Kindel zu dem Zeitpunkt wo ich ihn erworben habe das günstigste Andorid Tablet war (knapp 50,- EUR) und ich den ganzen anderen Mist nicht brauche, will ich verhindern das Amazon im Hintergrund a) Daten absaugt welche sie nichts angehen und b) nicht klangheimlich irgendwelche Dienste wieder aktiviert. (Was leider vorkommt).

Deswegen will ich den Kindle nur bei mir zuhause im Netz LAN betreiben, da alle Daten die ich auf dem Dinge benötige ausschliesslich von meinem Nextcloud Server kommen.

Werde heute Nachmittag mal versuschen die DNS Regel umzusetzen.

Gruss
Sohei

mike69

@sohei

Siehst ja am Screenshot, das Kindle will raus. :)
Zum Verständniss, das "LAN net" ist dein Subnet, wo sich alle tummeln. LAN address ist die IP der pfSense in deinem Subnet, normalerweise wäre das bei Dir die 172.16.1.1.
Um einige Dienste wie DHCP, DNS oder einen Zeitserver, welches die Sense ja bereitstellt, zu nutzen, muss vor der deny rule noch eine allow rule mit "LAN address" als destination inkl. den gewünschten Ports erstellt werden. Zumindest die Zeit würde ich ihm erlauben, von der Sense zu holen. Ohne eine korrekte Zeit laufen einige Apps nicht.
pfSense klappert die Rules von oben ab, First Match Wins eben. :)

fireodo

@jegr said in Internet Zugang für Amazon Kindle blockieren:

@fireodo WAN ist NIEMALS das Internet. Bitte ganz dringend merken.

Hab ich jetzt auch gecheckt! Bin genauso wie andere diesem Trugschluss anheim gefallen.

Nicht böse gemeint, aber der Fehler taucht immer und immer und immer wieder auf und es hält sich hartnäckig!

Ja, das kann ich JETZT verstehen ... Aber zum Lernen ist bekanntlich niemand zu alt

Ein gutes Neues übrigends,
fireodo

NOCling

@mike69 said in Internet Zugang für Amazon Kindle blockieren:

Um einige Dienste wie DHCP, DNS oder einen Zeitserver, welches die Sense ja bereitstellt, zu nutzen, muss vor der deny rule noch eine allow rule mit "LAN address" als destination inkl. den gewünschten Ports erstellt werden.

Nein, das geht mit eine einzigen Regel, indem man eine Deny Regel mit der Quell IP auf !Lan-Netz anlegt.

Dann darf diese IP nur mit den LAN IPs sprechen, aber mit keiner anderen.
Da alle anderen hinter der Sense im WAN liegen, kein internet.
Zugleich ist aber alles intern erlaubt, wenn man das sauber mit RFC1918 aufbaut, kann das Ding dann auch mit anderen privaten IPs in anderen VLANs sprechen, sollte man diese haben.

Zudem sind dann DNS, NTP usw. von der Sense gleich mit erlaubt. Und das mit einer einzigen Regel.

Aber warum simpel wenn man es doch auch kompliziert aufbauen kann.

mike69

@nocling said in Internet Zugang für Amazon Kindle blockieren:

Nein, das geht mit eine einzigen Regel, indem man eine Deny Regel mit der Quell IP auf !Lan-Netz anlegt.

Dann darf diese IP nur mit den LAN IPs sprechen, aber mit keiner anderen.
Da alle anderen hinter der Sense im WAN liegen, kein internet.
Zugleich ist aber alles intern erlaubt, wenn man das sauber mit RFC1918 aufbaut, kann das Ding dann auch mit anderen privaten IPs in anderen VLANs sprechen, sollte man diese haben.

Zudem sind dann DNS, NTP usw. von der Sense gleich mit erlaubt. Und das mit einer einzigen Regel.

Stimmt.

Sobald mehrere interne Netze vorhanden sind, war es das mit einer Regel. Ob dann 6 oder 5 Rules da stehen, ist egal.

@nocling said in Internet Zugang für Amazon Kindle blockieren:

Aber warum simpel wenn man es doch auch kompliziert aufbauen kann.

Fehlt da ein Smiley am Ende?

Wie dem auch sei, liegt es im Auge des Betrachters. Wer mit den invertierten Regeln klar kommt, soll sie nutzen. Persönlich komme sehr gut ohne damit aus. Aber das kann jeder selber entscheiden.

sohei

@mike69 @NOCling Vielen Dank

Ich habe die Regel jetzt folgendermassen geändert:

alt text

Soll/Muss jetzt bei IPv4 TCP/UDP stehen oder Any? Bin jetzt leide rkomplett durcheinander gekommen ... :)

NOCling

Das sollte reichen, weil DNS und NTP sind meist UDP, erstes ist aber teilweise auch über TCP nutzbar, wird aber selten eingesetzt.

Oder brauchst du noch andere spezielle Protokolle Richtung Sense?

Kannst aber auch any verwenden, viel Unterschied sollte das nicht machen bei deinem Einsatz von Split DNS und NTP.

sohei

@nocling danke schön - Nein, ich brauch keine spezielle Routings, mir ist nur wichtig das alle ins Internet kommen, ausser der Kindle ;)

JeGr

@sohei said in Internet Zugang für Amazon Kindle blockieren:

Vielen Dank für Deine ausfürhliche Antwort. Ich habe jetzt die egel folgendermassen geändert, denke aber das es noch nicht die von Dir vorgeschlagene Lösung ist.

Vielleicht ist es auch gut, wenn ich meinen kompletten Aufbau und mein Ziel beschreibe - das erklärt auch, warum der Kindle nicht ins Internet darf/soll.

Hallö :)

Nein, ich meinte in meiner Erklärung ganz obendrüber (über den Block) noch eine Regel mit

erlaube TCP/UDP, 172.16.1.77 Port * nach LAN_address (pfSense) Port DNS (53)
dann den Block (aber mit block any, nicht nur tcp/udp)

Alternativ statt nur DNS erlauben zu "LAN Address" eben alle Ports erlauben, dann kannst du vom Kindle Tablet auch noch die Sense UI aufrufen oder auch NTP machen statt nur DNS. Und wenn man mal ggf. mit HAproxy spielt, klappt auch das. :)

Ah verstehe, den Kindle ggf. sogar mit Ads billig gekauft, gerootet oder neu geflasht und soll jetzt nicht mehr raus. OK, wenn das der usecase ist, völlig legitim. Hab sowas ähnliches mit einem alten Nexus 6 mit neuer Firmware, weils da nichts "aktuelles" gibt, darf das auch nicht wirklich ins Netz, sondern spielt quasi nur inhouse Fernbedienung, Sonos Controller und Tasmota Steuerpult :)

@fireodo said in Internet Zugang für Amazon Kindle blockieren:

Ja, das kann ich JETZT verstehen ... Aber zum Lernen ist bekanntlich niemand zu alt

Nö nie, darum auch mein "bitte nicht falsch verstehen", denn ich wollte nur versuchen den langlebigen Irrtum zu kontern, der sich immer wieder einschleicht
Und euch auch allen ein gutes Neues

@nocling said in Internet Zugang für Amazon Kindle blockieren:

Nein, das geht mit eine einzigen Regel, indem man eine Deny Regel mit der Quell IP auf !Lan-Netz anlegt.

Nope, das behandle ich immer wieder in meinen Workshops. Sowas klappt in EINEM gezielten Ausnahmefall gerne. Sobald das Szenario aber ein klein wenig zur Seite abweicht, ist mit dem "NOT" (also !LAN_address) ganz schnell Feierabend und man verleitet die Leute dazu zu denken, dass man mehrere dieser Reglen stacken kann, was natürlich NIE funktioniert!

Mit einem NOT und damit indirekt mit einem logischen ODER zu arbeiten ist immer wesentlich schwerer und undurchsichtiger als einfach eine Regel mehr zu erstellen und SICHER zu sein, dass GENAU das gemacht wird, was da steht.

Zugleich ist aber alles intern erlaubt, wenn man das sauber mit RFC1918 aufbaut, kann das Ding dann auch mit anderen privaten IPs in anderen VLANs sprechen, sollte man diese haben.

Ich kann dann aber ebenfalls nicht den Zugriff auf die Sense auf DNS o.ä. begrenzen, sonst gilt das nämlich dank dem NOT und OR für alle Geräte im LAN was ich nicht will. Und nicht nur für den Kindle.

Aber warum simpel wenn man es doch auch kompliziert aufbauen kann.

Im Gegenteil, dein NOT Beispiel ist das volle Gegenteil von simpel.

Nein, das geht mit eine einzigen Regel, indem man eine Deny Regel mit der Quell IP auf !Lan-Netz anlegt.

Das würde aber eine völlig andere Konstellation ergeben: Ein Deny mit Quelle !LAN_network würde hier gar nichts auslösen. Nicht LAN Netzwerk wären alle IPs außer dem LAN Netz, in dem auch der Kindle ist. Somit wird gar nichts geblockt.

Wenn das schlecht formuliert und du Quelle Kindle IP auf !lan_netzwerk gemeint hattest, wird damit alles was nicht LAN ist geblockt. OK schön, damit ist aber dann die pfSense auch komplett offen. Will man aber vielleicht nicht, sondern ggf. nur DNS, NTP und sonst nix. Soll ja nicht jeder auf die UI. Wenn man zudem mal später noch andere Netze auf der pfSense bekommt gehen die auch nicht mehr. Auch doof.

Nur weil es jetzt gerade im Augenblick vielleicht mit einer "not" Regel funktioniert, heißt das IMHO nicht, dass das a) einfacher und b) simpler ist. Simpel ist an Not/Or/XOr/And Logik für den normalen User nämlich gar nichts. Und da genügt schon wieder eine zweite Regel mit einem NOT, die dann eben NICHT einfach dazu"addiert" wird, sondern die eine die andere Regel aussticht. Das verstehen aber ganz viele nicht. Das ist genauso wie mit Floating Regeln. Ihr könnt das wenn ihr 100% wisst was ihr tut gern nutzen, ich werde es weder empfehlen noch sagen "es ist einfacher". Weil es eben einfach ganz spezifische Anwendungsfälle gibt, wo das passen kann/gut ist, aber in allen anderen Fällen mag es vielleicht eine Regel oder zwei mehr kosten, es "normal" zu machen, dafür ist es effektiv wirklich einfacher und lesbarer, denn man kann 1:1 runterlesen was erlaubt ist und wann. Keine komischen Überraschungen, dass plötzlich Traffic erlaubt ist, weil da eine "Not Destinaton X" Regel drin ist und da plötzlich ganz anderer Traffic drauf matcht.

Nee sorry, schon viel zu oft bei Kunden gesehen, dass genau DAS voll nach hinten losgehen kann!

Cheers
\jens

Edit: und ja, wie @mike69 schreibt, ich hab genug Beispiele wo diese NOT Nutzung nach hinten losging, weil die Leute ganz schnell vergessen, dass das nicht funktioniert wie gesprochenes Wort, sondern nach Ablauf- und Programmlogik. Und nicht jeder kennt sich toll mit Logik-Gates oder entsprechenden Softwarekonstrukten so super aus, um alle Auswirkungen im Griff zu haben. Es funktioniert dann einfach irgendwie und hinterher findet man plötzlich raus, dass man durch doofe Kombination von 2-3 NOTs oder Floatings dann quasi alles freigegeben hat.

sohei

@jegr

Nein, ich meinte in meiner Erklärung ganz obendrüber (über den Block) noch eine Regel mit

erlaube TCP/UDP, 172.16.1.77 Port * nach LAN_address (pfSense) Port DNS (53)

dann den Block (aber mit block any, nicht nur tcp/udp)

Ich habe jetzt die in meinem letzten Post gezeigt Konfiguration gelassen. Der Internet Zugang für den Kindle ist nicht mehr möglich (habe ich getestet) und alle anderen LAN Zugriffe kann er durchführen.

Alternativ statt nur DNS erlauben zu "LAN Address" eben alle Ports erlauben, dann kannst du vom Kindle Tablet auch noch die Sense UI aufrufen oder auch NTP machen statt nur DNS. Und wenn man mal ggf. mit HAproxy spielt, klappt auch das. :)

Das problem daran ist, dass der Kindle nicht nur auf den NextCloud Server zugreifen muss, sondern auch auf andere "Server" und "Dienste" welche (derzeit) alle im LAN Segment stehen. Das würde bedeuten, dass ich für jeden Dienst eine Regel erstellen müsste. Da diese ganze Konfiguration noch maximal dieses Jahr halten muss, ist mir diese Quick-and-Dirty Lösung ganz recht. Wenn wir dann im neuen Haus sind, wird sowieso richtig umgebaut und alle Server in eine DMZ verschoben.

Ah verstehe, den Kindle ggf. sogar mit Ads billig gekauft, gerootet oder neu geflasht und soll jetzt nicht mehr raus. OK, wenn das der usecase ist, völlig legitim. Hab sowas ähnliches mit einem alten Nexus 6 mit neuer Firmware, weils da nichts "aktuelles" gibt, darf das auch nicht wirklich ins Netz, sondern spielt quasi nur inhouse Fernbedienung, Sonos Controller und Tasmota Steuerpult :)

Nun ja, schuldig im Sinne der Anklage ;) ...

Aber vielen Dank für die guten Erläuterungen, hoffe das ich demnächst auch mal diese Wissenschaft der Layer begreifen werde :)

bon-go

@sohei said in Internet Zugang für Amazon Kindle blockieren:

Alternativ statt nur DNS erlauben zu "LAN Address" eben alle Ports erlauben, dann kannst du vom Kindle Tablet auch noch die Sense UI aufrufen oder auch NTP machen statt nur DNS. Und wenn man mal ggf. mit HAproxy spielt, klappt auch das. :)

Das problem daran ist, dass der Kindle nicht nur auf den NextCloud Server zugreifen muss, sondern auch auf andere "Server" und "Dienste" welche (derzeit) alle im LAN Segment stehen. Das würde bedeuten, dass ich für jeden Dienst eine Regel erstellen müsste. Da diese ganze Konfiguration noch maximal dieses Jahr halten muss, ist mir diese Quick-and-Dirty Lösung ganz recht. Wenn wir dann im neuen Haus sind, wird sowieso richtig umgebaut und alle Server in eine DMZ verschoben.

Wie weiter oben schon mehrfach erwähnt: wenn der Kindle und 'die ganzen anderen Geräte im gleichen LAN' letzten Endes an einem Switch vor bzw. hinter der pfSense hängen dann sieht die pfSense das (an ihrem LAN) nicht und man braucht auch keine separaten Firewallregeln dafür. Das ist unnütz. Die Geräte reden über den Switch direkt miteinander.

Die Firewallregeln für den Kindle sind nur dazu da:

um DNS, DHCP und NTP der pfSense zu nutzen
den gesamten restlichen Traffic zur pfSense und ausserhalb des LAN (eben auch den kompletten Internetverkehr) zu blockieren