Firewalling und DNS via Pi-hole

Es gibt 17 Antworten in diesem Thema, welches 6.794 mal aufgerufen wurde. Der letzte Beitrag () ist von razor.

  • Moin zusammen,


    ich stecke bei einem Firewall-Problem mit meinem Unifi-Setup fest und hoffe hier in der Community findet sich Hilfe :smiling_face:


    Ich habe intern einen Pi-hole als DNS-Server stehen ( eigenes VLAN, statische IP ). Dieser DNS-Server wird per DHCP an alle WiFi-Clients verteilt - bis hierher funktioniert das einwandfrei. Der Pi-hole bekommt alle Anfragen der Clients, löst diese auf und die Clients können die Zielhosts erreichen.


    Ich habe nun Firewallregeln implementiert, welche nur dem Pi-hole auf den beiden DNS-Ports erlauben zu kommunizieren und die WiFi-Clients dürfen sich ausschliesslich mit dem Pi-hole als DNS-Server verbinden, um eben nicht irgend einen beliebigen DNS-Server im Internet direkt ansprechen zu können:


    - LAN in: allow -> Pi-hole -> Port 53/853 -> Internet ( extern, WAN )

    - LAN in: allow -> WiFi-Clients -> Port 53/853 -> Pi-hole ( intern, LAN )

    - LAN in: deny -> all -> Port 53/853 -> all ( intern und extern )


    Die Regeln eben so ( in dieser Reihenfolge ) eingetragen und der Pi-hole kann auch seinen eingetragenen, autoritativen DNS-Server im Internet erreichen. Weiterhin sehe ich im Pi-hole Logfile auch die WiFi-Clients anfragen. Soweit scheinbar auch noch alles okay :smiling_face_with_sunglasses:


    Jetzt aber das Problem. Mein iPhone und iPad verweigern die Nutzung aller Internet-Services ( z.B. Mail, iMessage, Browsing, ... ) mit dem Hinweis darauf, dass angeblich das WLAN nicht mit dem Internet verbunden wäre. Nehme ich die deny-Regel auf der USG wieder raus ( alles andere bleibt unangetastet ), funktioniert sofort wieder alles bestens.


    Ich kann mir darauf keinen Reim machen und hoffe auf kreative Vorschläge :smiling_face:


    Danke Euch schon mal ...

  • Du schreibst: "Ich habe intern einen Pi-hole als DNS-Server stehen ( eigenes VLAN, statische IP ). "


    Welche Switche sind im Einsatz für die APs?

    Wurden die Switche der Ports bzgl. VLANs richtig konfiguriert?

    ------

    vg

    Franky

  • Es ist ein US-8-60W im Einsatz.


    Die Switchports der APs ( drei Stück, AP AC Pro ) sind mit VLAN1 als nativem und VLAN20 als getaggtem VLAN konfiguriert. Der Pi-hole hängt an einem anderen Switchport, welcher mit VLAN1 als nativem und VLAN10 als getaggtem VLAN konfiguriert ist. Da sich die Devices dank unterschiedlicher Netze ja nicht "sehen" könnten, habe ich eben die "allow DNS"-Regel eingetragen - was ja auch grundlegend klappt :smiling_face:


    Wie gesagt sehe ich im Pi-hole Logfile ja die DNS-Requests von iPhone und iPad, das heisst die "grundlegende Kommunikation" findet statt :thinking_face:

  • Mir fehlt leider noch immer die Information WER mit mit WEM kommunizieren soll.


    Alleine die Firewall Regeln reichen da nicht.


    Warum ist der PiHole in einem eigenen VLAN?


    Meine Empfehlung wäre den PiHole im Admin LAN zu platzieren.

    ------

    vg

    Franky

  • Moin,

    Der Pi-hole hängt an einem anderen Switchport, welcher mit VLAN1 als nativem und VLAN10 als getaggtem VLAN konfiguriert ist.


    Kann sein, dass ich ein Denkfehler habe aber:


    Wenn an dem Port nur das PiHole hängt ist er doch im VLAN1 - der Pi tagged doch nicht oder irre ich mich ?


    evtl funktioniert daher deine Regel nicht weil die auf VLAN 10 ziehlt der aber im VLAN 1 ist


    Korrigiert mich gern wenn ich falsch liege

    Mein Projekt

  • WER mit WEM ... meine WiFi-Clients ( alle per DHCP in VLAN20 ) sollen einen DNS-Namen auflösen. Deren eingetragener DNS-Server ist mein Pi-hole ( statische IP in VLAN10 ). Somit Client will auf z.B. google.de fragt beim Pi-hole an, dieser geht an seinen authoritativen Server im Internet ( hier: 1.1.1.1 ), löst den Namen auf und gibt die IP zurück zum Pi-hole und dieser wieder zurück zum Client ( klassisch rekursives DNS ).


    Intern dann also etwas detaillierter: Client ( 192.168.20.10 ) fragt beim Pi-hole ( 192.168.10.10 ), der im Internet ( 1.1.1.1 ) und wieder zurück. Das Routing geht dann wohl über das Gateway des VLAN20 ( 192.168.20.1/24 ) ins VLAN10 ( 192.168.10.1/24 ) und raus ins Internet ( via USG, eth0 ). Um das zu ermöglichen eben die Regel allow VLAN20 -> VLAN10 ( Ports DNS ). Da in der Regel established, new und related Sessions aktiviert sind, ist doch eigentlich der "Rückweg" der Pakete per Definition ebenfalls offen !?


    Der Pi-hole steht in VLAN10, da ich im nativen VLAN1 wirklich nur die Unifi-Devices haben möchte, nichts Anderes :smiling_face:


    Alleine die Firewall Regeln reichen da nicht ? Okay, einverstanden, aber was habe ich dann vergessen ? :fearful_face:

  • Sorry mein Fehler in der Beschreibung, natürlich ist der Switchport mit VLAN10 als nativem VLAN gesetzt ... VLAN1 ist dort aussen vor

  • Das ganze klingt irgendwie stark nach iOS problem - denke er meckert weil er einen Apple DNS nicht erreicht.


    Ich würde mal versuchen den DNS manuell am iPhone einzustellen

    Mein Projekt

  • Das ganze klingt irgendwie stark nach iOS problem - denke er meckert weil er einen Apple DNS nicht erreicht.


    Ich würde mal versuchen den DNS manuell am iPhone einzustellen

    Einen manuellen Eintrag des Pi-hole als DNS-Server im iOS hatte ich bereits versucht, ergab keine Änderung.


    Es sind auch nicht nur iPhone und iPad, habe auch meinen Windows 10 Desktop ( ebenfalls per WLAN im VLAN20 ) eben versucht, er zeigt das identische Verhalten: Ist die deny-Regel aktiv findet keine Kommunikation Richtung Internet mehr statt ( DNS-Seitig ).


    Ich habe langsam den üblen Verdacht, ich muss mich wohl mit tcpdumps dransetzen :thinking_face::face_with_rolling_eyes:

  • Es sind auch nicht nur iPhone und iPad, habe auch meinen Windows 10 Desktop ( ebenfalls per WLAN im VLAN20 ) eben versucht, er zeigt das identische Verhalten: Ist die deny-Regel aktiv findet keine Kommunikation Richtung Internet mehr statt ( DNS-Seitig ).

    Sitzt die deny regel richtig ? nicht, dass du dir deinen Pi Hole auch nach extern wegblockst

    Mein Projekt

  • Sitzt die deny regel richtig ? nicht, dass du dir deinen Pi Hole auch nach extern wegblockst

    Ja, die Regel sitzt richtig:


    ID2002 - allow pihole wan

    ID2003 - allow wifi-clients-pihole

    ID2004 - deny wifi-clients-dns-wan


    Die Regeln werden doch von "oben nach unten" abgearbeitet - matcht eine Regel, sind folgende für den gleichen Host nicht mehr relevant - oder irre ich mich da ?!

  • Alleine die Firewall Regeln reichen da nicht ? Okay, einverstanden, aber was habe ich dann vergessen ? :fearful_face:

    und an welchen Switchen werden die VLANs getagged bzw. wie sind die jeweiligen Switchports konfiguriert? (All oder wie?)

    ------

    vg

    Franky

  • ... Die Switchports der APs ( drei Stück, AP AC Pro ) sind mit VLAN1 als nativem und VLAN20 als getaggtem VLAN konfiguriert. Der Pi-hole hängt an einem anderen Switchport, welcher mit VLAN10 als nativem VLAN konfiguriert ist. ...

    Die Switchports hatte ich schon beschrieben :smiling_face_with_sunglasses:


    Gerne noch mal etwas detaillierter - siehe auch unten die Screenshots:

    • Pi-hole: Switchport 4/5 ( als LACP konfiguriert ) mit nativem VLAN10 ( Profile: 10-system-lan ) - keine weiteren getaggten VLANs
    • USG: Switchport 1 mit einem Trunk ( Profile: All )
    • Clients via AP: Switchports 6,7,8 mit nativem VLAN1 und getagten VLAN20 ( Profile: 20-home-lan )


    Hier die Screenshots dazu


    Die APs sind entsprechend dem LAN ( VLAN20 ) zugordnet, also taggen die eingehenden Pakete der WiFi-Clients mit VLAN20 :smiling_face: Es ist weiterhin auch keine Port-Isolation aktiviert.

  • Ich bin bei Dir mit der Argumentation, dass WiFi Clients VLAN20 taggen, aber wie erreichen sie ihren DNS (der steht ja in VLAN10)?


    ... wenn das so weiter geht, dann male ich mir selbst ein Bild :face_with_tongue:


    Könntest Du zur Fehlereingrenzung mal den beiden Switchports des PiHole "All" geben?

    ------

    vg

    Franky

  • Das Thema hat sich erledigt, danke für die "hinweisgebenden Tipps" :smiling_face_with_halo:


    Es lag letzlich an einem Fehler der USG ( ich hatte mal den Unifi Support bemüht ). Die USG hatte einen Fehler bei der Provisionierung der allow-Regel, wo einfach der Source-Port in der GUI zwar richtig angezeigt, nicht aber sauber auf die USG geschrieben wurde. Regel komplett gelöscht mit allen zugehörigen Gruppen, neu angelegt - alles rennt wie es soll.


    Danke für Euren Support !


    close

    • Offizieller Beitrag

    Hallo khyrell ,

    habe ich das richtig verstanden, dass Du alles richtig konfiguriert hast und nur das USG nicht sauber provisioniert wurde?


    Dann würde ich das gern als Anleitung im #wiki sehen - schaue ich mir an.


    Bitte um eine kurze Rückmledung, danke.

  • das hast du richtig verstanden :smiling_face: was sollte ich dazu im wiki schreiben - regel gelöscht, neu eingetragen, provisioniert, fertig :thinking_face:


    unabhängig zu diesem thread, zu meiner usg - die gute scheint allerdings noch anderweitige probleme zu haben, da diese kurz nach dieser aktion hier bei einer erneuten provisionierung "komplett abgeraucht" ist. meldung "provisionierung fehlgeschlagen", restart, komplett neu adaptiert und vom uck neu provisioniert. ich bin dazu aktuell auch mit dem unifi-support zu gange :smiling_face_with_halo:

    • Offizieller Beitrag

    das hast du richtig verstanden :smiling_face: was sollte ich dazu im wiki schreiben - regel gelöscht, neu eingetragen, provisioniert, fertig :thinking_face:


    unabhängig zu diesem thread, zu meiner usg - die gute scheint allerdings noch anderweitige probleme zu haben, da diese kurz nach dieser aktion hier bei einer erneuten provisionierung "komplett abgeraucht" ist. meldung "provisionierung fehlgeschlagen", restart, komplett neu adaptiert und vom uck neu provisioniert. ich bin dazu aktuell auch mit dem unifi-support zu gange :smiling_face_with_halo:

    Da habe ich mich nicht deutlich genug ausgedrückt: Nicht Du sollst einen eintrag im #wiki machen, ich hatte das als Task für mich gesehen - im Rahmen des Pi-Hole. Das wurde schon an einer anderen Stelle als Thema angedacht.


    Danke für die Bestätigung.