DHCP Fritzbox zu Cisco und Einbindung von Unifi Geräten

Wie ist das zu verstehen ?? Mit "Router" meinst du ja ganz sicher NICHT die FritzBox, oder ? Die kann das technisch gar nicht.
Dein VLAN Design und Konfig des SG350 sollte so aussehen:
Verständnissproblem Routing mit SG300-28

Ist dem so ??
Wenn nicht baue das Design genau so um wie im Thread beschrieben. Dort findest du auch eine Step by Step Anleitung.
Sinnvoll ist in der Tat die FritzBox als reines NUR Modem zu betreiben aber sehr wahrscheinlich wird sie das nicht supporten und du musst sie und die Firewall mit einer Router Kaskade mit doppeltem NAT und Firewalling betreiben. Technisch nicht die beste Lösung aber machbar.
Alle Details dazu findest du hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten

Reine NUR xDSL Hybrid NUR Modems sind z.B. Draytek Vigor 165 oder Zyxel VMG3006 oder du beschaffst dir über eBay eine preiswerte FritzBox 7412:
https://www.spiegel.de/netzwelt/gadgets/fritzbox-7412-als-dsl-modem-dect ...
https://www.heise.de/select/ct/2020/2/1578238295698254

Unverständlich ??
Du hast doch gar keinen Cisco Router laut deiner Beschreibung ?? Wo kommt der denn jetzt her ??
Gehe doch erstmal ganz strategisch vor.
Bevor wir ins Eingemachte gehen solltest du erstmal wasserdicht dein Design klären
Wenn man dich richtig versteht willst du ja zentral über den Layer 3 Switch routen wie es HIER beschrieben ist, oder ??

Oder willst du den Switch NICHT im Layer 3 (Routing) Modus betreiben sondern rein im Layer 2 und über die USG zentral routen ??
Wenn das der Fall ist dann gilt dieses_Tutorial hier.
Das sind 2 völlig verschiedene Routing Konzepte und daraus folgende Konfigs die du zwingend ZUERST klären solltest
Das ist es auch wenn du die FritzBox in einer simplen Router Kaskade mit der USG betreibst !
Dieses Design (VLAN Routing auf der USG) sähe dann so aus:


Solltest du doch die VLANs über den Switch routen wollen (Switch im L3 Mode "IP Routing") dann sähe das Design so aus:

Das ist auch genau richtig so ! Hast du vollkommen richtig verstanden.
Das ist per se auch richtig aber dennoch ist es immer sinnvoll und auch Standard festen Routern immer eine statische IP zu vergeben. Sollten sich dynamische IPs einmal ändern zeigt deine VLAN Route auf der FritzBox ins Nirwana und nix geht mehr. Dynamische IPs sind deshalb immer ein NoGo auf Routern.
Besser also dem Koppelport eine statische IP zu setzen die AUßERHALB des FritzBox DHCP Bereichs liegt also z.B.: 192.168.178.254
Deine statische VLAN Route auf der FritzBox sollte dann immer auf diese IP zeigen.
Via WAN kannst du auch vermutlich nicht zugreifen, denn dort ist die NAT Firewall aktiv.
Über das LAN sollte es aber immer klappen.

Wie du zugreifst ist aber eine generell eine Frage des grundsätzlichen Designs: VLAN Routing auf Switch oder VLAN Routing auf USG !!!
Wenn du dich jetzt fest fürs VLAN Routing auf dem Switch entschieden hast dann wird die USG am LAN Port NICHT Tagged über einen Trunk angeschlossen sondern über einen stinknormalen UNtagged Accessport. Logisch, denn das VLAN Routing macht ja dann der Switch und die USG manged rein nur noch abgehenden Traffic ins Internet. Siehe Design 2 oben !!
Über das LAN VLAN kannst du dann problemlos von allen Switchports auf die USG zugreifen !

Die FritzBox darf niemals an einem Trunk Port (Tagged Port) hängen, denn bekanntlich supportet die FritzBox keinereli VLAN Funktion und kann mit Tagging nichts anfangen. Klar das das in die Hose geht...
Die FritzBox darf immer nur an einen UNtagged Access Port angeschlossen werden eben wegen ihrer fehlenden VLAN Funktion !
Übrigens hätte eine Screeshot des Port Setups hier sicher geholfen...
So oder so ist es aber besser und sauberer du fängst mit einem Reset nochmal neu an. Also intuitiv alles richtig gemacht.
Etwas verwirrend... Wie meinst du das ? FritzBox: 192.168.178.1 /24 und Switch VLAN 1 IP: 192.168.178.254 /24 ? Das wäre dann OK aber kann niemals sein weil du die USG dazwischen vergessen hast !!!
Die FritzBox arbeitet doch mit der USG in einer Kaskade. Sprich also WAN Port der USG ist im FritzBox LAN z.B. .178.254 und der Switch hängt am LAN der USG. Das USG LAN muss logischerweise in einem anderen IP Netz liegen und damit dann auch die VLAN 1 IP des Switches.
FritzBox und Switch sind doch nicht direkt verbunden !!
Gleich darf die IP natürlich auch keinesfalls sein denn doppelte IP Adressen sind verboten. Weist du ja auch sicher selber ?!
Du baust im ersten Schritt einzig und allein erstmal nur die Kaskade auf und nur das Default VLAN 1 auf dem Switch.
So sieht das dann aus:


Denke dir in diesem ersten Schritt alle VLANs außer 1 weg. Das kommt im 2ten Schritt. Du setzt erstmal nur die Grundkonfig mit VLAN 1 auf !
Das ist das Grundsetup was wasserdicht funktionieren muss !! Sprich also ein Client an einem Access Switchport in VLAN 1 muss eine IP über den DHCP Server entweder in der USG oder Switch bekommen und über das USG und über die FritzBox ins Internet kommen und dort fröhlich surfen können. (Vorsicht: DHCP Server darf hier im VLAN 1 nur entweder der Switch oder die USG spielen. Niemals beide parallel !)
Rennt das alles, machen wir mit den VLANs im Switch weiter !

Tja, das war ja leider immer das Verwirrende bei dir. Mal so mal so... Oben schreibst du das du es so mit USG aufbauen willst redest aber vom FritzBox Netz was sich widerspricht. Dann ist nur die Lösung mit der FritzBox, dann wieder nicht....

Wenn du die USG GAR NICHT benutzen willst dann sieht das Design natürlich etwas anders aus:
Auch hier: Erstmal alles nur mit VLAN 1 aufbauen. Internet muss klappen. Dann kommen die restlichen VLANs.
Sorry, aber weisst du selber das das technischer Unsinn ist. Was hat denn ein DHCP Server mit der IP Erreichbarkeit eines Hosts im Netz zu tun. Es sei den natürlich die statische IP des Switches liegt mittem im DHCP Bereich.
Der Switch muss eine statische IP außerhalb jeglichen DHCP Bereiches haben !!! Idealerweise nimmt man bei 24er Prefixes immer die IPs ganz oben oder ganz unten und legt den DHCP Pool mit einem Sicherheits Abstand dazu an. Z.B. .1 bis .5 und .250 bis .254 und den Pool von .50 bis .230 oder sowas. Banale Adressierungs Grundlagen...

Vielleicht solltest du wirklich im stillen Kämmerlein zuerst einmal in dich gehen und in Ruhe klären WELCHEN Netzdesign Weg du denn nun gehen willst.
Ansonsten drehen wir uns hier wirklich alle sinnfrei im Kreis was bekanntlich wenig Spaß macht.

Das ist natürlich Unsinn. Bei jedem Switch kann man bzw. muss man die IP Adresse auf eine statische ändern können. Das geht natürlich auch beim Cisco egal ob GUI oder CLI.
Bei dir ist das essentiell und zwingend nötig, da du ja routen willst mit dem Switch und die VLAN IP Adressen die Router Interfaces darstellen. Muss man sicher nicht weiter erläutern warum dort dynamische DHCP Adressen Unsinn sind.
Wenn du es im GUI nicht hinbekommst ziehst du den Switch halt ab von USG oder FB und rebootest ihn isoliert. Dann hat der Switch eine feste statische Management IP 192.168.1.254
https://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbms/350xg/admin ...
Seite 9
Die connectest du dann via Browser im VLAN 1 und überschreibst sie im GUI mit einer statischen deiner Wahl. Den DHCP Client deaktivierst du natürlich !
Obwohl das Ziehen nicht wirklich erforderlich ist. In einem schnellen Test hier auf einem SG350X funktionierte das auch mit einem aktiven DHCP Client VLAN Interface ohne jegliche Probleme. Was du oben behauptest ist also de facto unrichtig ! Was immer geht ist auf "Add" klicken und ein neues VLAN 1 Interface anlegen mit deiner neuen IP und nachher mit "Delete" das ursprüngliche Interface zu löschen.

Solltest du das wider Erwarten per GUI dennoch nicht schaffen, dann gehst du eben per Telnet oder SSH (z.B. mit PuTTY) auf den Switch und machst das über das CLI. Auch das klappt sofort:
Switch#conf t
Switch(config)#int vlan 1
Switch(config-if)#no ip address dhcp
Switch(config-if)#ip address 192.168.1.254 255.255.255.0
Switch(config-if)#exit
Switch(config)#exit
Switch#write mem

Fertisch !
Gibst du ein show run ein sieht das dann so aus:

interface vlan 1
name "Lokales VLAN-1"
no ip address dhcp
ip address 192.168.1.254 255.255.255.0

Und schon hat dein VLAN die gewünschte statische IP Adresse !

Wenn du bei den eingebetteten Bilder auch mal das "+" Zeichen an die richtige Stelle klickst wie es in der Beschreibung steht, dann erscheint das Bild auch im richtigen Kontext deines Threads und nicht ohne Bezug, verwirrend irgendwo am Ende... Kann man übrigens noch nachträglich mit "Bearbeiten" (rechts unter "Mehr") anpassen...
Perfekt !
Dann kannst du jetzt auch weitere VLANs mit VLAN IP einrichten auf dem Switch. Default Route 0.0.0.0/0 dann via VLAN 1 IP auf die USG und in der USG eine statische Route der VLAN IP Netze auf die VLAN 1 IP des Switches. Und schon rennt dein oben gepostetes Wunschdesign !
Wir sind gespannt...!

Netzwerk Klassen gibt es schon seit 1993 mit der Einführung des CIDR_Standards nicht mehr. Das sollte eigentlich auch langsam bei dir angekommen sein ?!
Ja, das ist korrekt !
Was meinst du mit "Reglementierung" ??
Wenn du aus allen deinen VLANs mit einem Testrechner fehlerlos eine Internet IP wie z.B. ping 9.9.9.9 UND auch einen Hostnamen wie ping www.heise.de anpingen kannst hast du ja nachweislich einen sauber Internet Zugang und korrekte DNS Auflösung aus allen deinen VLANs.
Netztechnisch ist dann alles erledigt, denn Switch und Router arbeiten ja rein nur auf Layer 3.
Was dann ggf. noch für Firewall Regeln und Einstellungen auf deiner Firewall greifen ist eine ganz andere Geschichte. Nur die kann dann noch weitere Traffic Reglementierungen machen. Zu diesem Regelwerk sagst du leider rein gar nichts so das man da nur im freien Fall raten kann.
Indem du stattdessen einen lokalen Timeserver nutzt:
https://www.heise.de/ct/hotline/Oeffentliche-Zeitquellen-322978.html
Vermutlich kann deine USG auch NTP Zeitserver spielen.
Erklärung ist eigentlich ganz logisch und leicht....
Da lag der Fehler etas zwischen den Kopfhörern (PEBKAC Problem) !
Das funktioniert natürlich auch im "Auto" Mode allerdings hättest du oben die Netzwerk Adresse dafür setzen müssen was du nicht getan hast. Generell ist das schon ein Konfig Fauxpass im DHCP !!
Unter Subnet IP Address gehört natürlich 172.16.1.0 hin damit das für den Pool eindeutig ist.
Du hast das aber letztlich aber intuitiv richtig gemacht, denn "Auto" würde die VLAN IP Adresse des Switches vergeben. Das VLAN 1 ist aber ein Sonderfall, da dies ja das Koppelnetz zur USG ist indem sich normal ja gar keine Clients befinden. Hier macht es natürlich wenig Sinn die Switch IP den Endgeräten (die eigentlich da gar nicht sein sollten) zu geben sondern das kann dann sinnvollerweise direkt die USG IP sein, denn warum sollte lokaler VLAN 1 Traffic der Clients nochmal als "Durchlauferhitzer" über die Switch IP im gleichen VLAN gehen bevor es zur USG IP im gleichen VLAN geht.
Insofern ist das richtig, gilt aber NICHT für alle anderen VLANs !! Dort muss das Gateway für die Endgeräte immer die Switch IP sein, denn der Switch routet da ja zw. den VLANs. DNS ist dann dort auch die USG IP 172.16.1.1.

10 Tage Leasetime ist keine intelligente Idee. Das belastet den Pool stark mit geblockten IPs. Hier solltest du maximal auf 3 Tage gehen. Normal ist ein Tag. Aktive Geräte machen so oder so immer ein Renewal bei Ablauf der Leasetime und behalten ihre IP.

In Firmennetzen ist das auch schon aus gesetzlichen Gründen (Fernmeldegeheimnis) immer Pflicht aber in privaten Netzen ist das Geschmackssache.
Das ist auch ganz klar warum das nicht geht ! Denke mal selber etwas nach...
Im VLAN 1 hast du als Cleint Gateway die USG und die USG hat ganz sicher keine statische Route auf die Switch IP Adresse. (Sceenshots dieser Route fehlen oben !)
Sprich also Traffic der aus einem der nicht VLAN 1 VLANs auf dem USG ankommt hat keine Rückroute mehr und scheitert so.
Folglich schlägt also jeglicher Zugriff aus den VLANs via Internet also auch Traffic der vom VLAN 1 in die Switch VLANs geht sofort fehl wegen dieser fehlenden VLAN Route.
In den Switch VLANs haben die Clients ja immer die Switch IP als Gateway und deshalb können so alle anderen VLANs problemlos erreicht werden. Außer VLAN 1 natürlich. Dort haben die Clients als Gateway nicht die Switch IP sondern die USG IP, würden deshalb also Rücktraffic in die anderen VLANs erst ans USG schicken, dort fehlt aber, wie bereits gesagt, die Rückroute und dann scheitert die Verbindung.
Es ist alles alles logisch das es nicht geht...

Der Screenshot der USG VLAN Route ist natürlich Blödsinn, denn die 172.16er Netze dürfen ja niemals auf die Schnittestelle "default" geroutet werden denn dann landen sie logischerweise beim Provider im Nirwana.
Das das falsch ist sagt einem eigentlich schon der gesunde Menschenverstand.
Richtig wäre dort Folgendes anzugeben beim Erstellen einer neuen statischen Route:

• Name: VLANs
• Haken: Route aktivieren
• statisch
• Zielnetz: 172.16.0.0 /16
• Typ: Nächster Hop

Danach sollte sich ein IP Adress Eingabefeld aufmachen in dem man die IP Adresse der VLAN 1 IP des Switches einträgt ! Schnittstelle müsste logisch auf "VLAN1" stehen aber vermutlich kann das dieser gruselige Ubiquity Müll nicht ?!
Eine statische Route im Cisco außer der Default Route ist in der Tat Unsinn. Die Default Route im Cisco routet ja alles was der Cisco lokal nicht kennt an die USG VLAN 1 IP und das reicht ja denn. Die USG sollte ja wissen wo alles hingeht...sollte...wenn denn Routing und Regelwerk stimmen ?!
Das ist richtig und einen Gefahr, denn das Gastnetz darf natürlich niemals auf dem Cisco enden und dort geroutet werden.
Die Lösung ist aber kinderleicht.
Du entfernst einfach die Gast VLAN IP Adresse auf dem Cisco. Damit ist ein Routing dort physisch unmöglich.
Du musst das Gast VLAN dann auf die USG "durchschleifen" und dort auf einem VLAN Interface terminieren genau wie du es mit dem VLAN 1 gemacht hast.
Das setzt dann voraus das du den Switch Uplink zur USG in den Mode: "Trunk" ändern musst und das Gast VLAN dort tagged übertragen musst.
Auf der USG dann analog. Der physische Port muss auch ein Trunk (tagged) Uplink sein über das dann das VLAN 1 und das Gast VLAN auf der USG mit VLAN Ports terminiert wird. DHCP fürs Gast VLAN kommt dann auch von der USG.
So hast du beide VLANs auf der USG liegen und kannst hier mit einem entsprechenden Regelwewrk und einem Gäste Captive Portal das Gastnetz entsprechend steuern.
Wie so ein Tagged Uplink (Trunk) auf einer Firewall terminiert wird kannst du dir am pfSense_Beispiel_im_VLAN-Tutorial ansehen. Das dürfte auf der USG Gurke mehr oder minder identisch sein.
Immer gerne und danke für die weihnachtlichen Blumen !
Dein Setup sieht dann so aus (Auszug)

Nein !
Wie kommst du jetzt auf den wirren Unsinn ??
VLAN 1 ist weiterhin das zentrale Koppelnetz auf deine Switch VLANs. Muss es ja, denn du routest ja alle VLANs zentral am Switch. Jedenfalls hast du gesagt das du das tun willst...
Das Gast VLAN darf aber keinesfalls eine IP Adresse am Switch haben denn das willst du ja zu Recht aus Security Gründen da nicht routen. Folglich also schleift man es schlicht und einfach im Layer 2 durch und legt es IP Routing seitig mit seiner IP auf die USG. Fertisch...
Nichts anderes wird oben gemacht und zeigt auch noch einmal das Übersichstbild was du scheinbar übersehen hast ?!

Rein technisch gesehen kannst du natürlich auch das Gast VLAN L3 seitig am Switch terminieren aber dann musst du zwingend dort mit Access Listen arbeiten um das Gast Netzwerk von den anderen zu isolieren. Der L3 Switch ist ja keine Firewall....
Das wäre aber designtechnischer Unsinn, denn

• ACL sind nicht Stateful
• Du hast doppeltes Security Management
• Wozu hast du eine Firewall die das besser kann

3 triftige Gründe also das Gastnetz NICHT L3 seitig auf den Switch zu legen sondern auf die USG.

Das kann natürlich sein !! Leider fehlt ein entsprechender Screenshot dazu von dir.
Du solltest also erstmal das Setup Menü oben rechts auf Advanced klicken.
Dann findest du unter IP Setup den entscheidenden Haken:


Ist der gesetzt dann ist auch IP Routing, sprich L3 Switching aktiv wenn du den VLANs unten in der "Interface Table" entsprechende IPs auf dem Switch gegeben hast.

Du machst hier einen gehörigen Denkfehler. VLANs sind eine reine Layer 2 Funktion !!!
Mit IP Adressen hat das rein gar nichts zu tun. Der VLAN Tag liegt am Layer 2 Ethernet Frame also auf Mac Ebene und niemals am IP Header wie du oben behauptest: Guckst du hier:
https://de.wikipedia.org/wiki/IEEE_802.1Q

Mit dem Gast geht das grob erklärt so:

• Gast connected sich mit der Gast SSID und AP tagged damit alle Paket die von der Gast SSID kommen
• Connecteter Client schickt einen DHCP Request Broadcast um eine IP zu erlangen
• Der Broadcast wird vom MSSID AP mit dem Gast VLAN Tag am Frame via Layer 2 über die Trunk Links an die USG durchgereicht denn da ist ja jetzt statt Switch das L3 Interface fürs Gastnetz.
• USG empfängt den Frame und weiss anhand des VLAN Tags auf welches VLAN IP Interfaces es diesen Frame zu forwarden hat.
• USG beantwortet den DHCP mit einem Offer von seinem DHCP Server, hängt den Gast VLAN Tag wieder ans Frame der dann via Layer 2 zurück über die Tagged Uplinks zum AP kommt.
• Der AP strippt die Tags ab und sendet auf der WLAN Schnittstelle in der Gast SSID den Offer an den Client

Et voila...so gehts.
Fazit:
Nochmal genau die VLAN Funktion nachlesen und verstehen...
Das liegt sehr wahrscheinlich daran das du keine statische Route in deine VLAN Netze auf dem USG definiert hast. Damit scheitert die Rückroute und damit die Internet Verbindung !
Was passiert denn wenn du aus diesen VLANs mal eine Traceroute auf die 8.8.8.8 machst. tracert 8.8.8.8 unter Winblows.
Wo kommt das Paket nicht mehr weiter ?? Genau da liegt der Fehler !
Hilfreich wäre auch mal die Routing Tabelle des USG zu posten um dein Routing dort zu checken.

Du kannst ja auch einfach mal einen Client im VLAN 1 als Gateway die Switch IP Adresse im VLAN 1 setzen. Dann wirst du sehen das das Routing innerhalb der Switch VLANs sauber funktioniert.
Du kannst vermutlich auch die VLAN 1 IP Adresse des USG 172.16.1.1 nicht pingen aus den anderen VLANs, richtig ??
Das spricht dann für die fehlende Route auf dem USG.
Kannst du sie pingen aber 8.8.8.8 nicht dann spricht das für ein falsches oder fehlendes Regelwerk oder NAT für diese IP Netze in der USG und damit einer Fehlkonfig.

Das ist auch richtig so und die richtige Route. Damit würde sämtlicher Traffic der in alle 172.16.x.y Netze geht an die VLAN 1 IP Adresse des Switches geroutet. Der routet sie dann wieder auf die dedizierten VLANs.
Da die lokalen 172.16er IP Netze an der USG einen kleineren Prefix haben werden die dort lokal geroutet.
Eine einzige Route auf der USG mit dem /16er Prefix reicht also vollkommen aus um die Rückrouten aller 172.16er VLAN Netze auf den Cisco zu routen.
Es ist also völlig unsinnig alle /24er Netze auf der USG einzeln einzugeben.
Wenn sich die Switch Subnetze im Bereich .0 bis .63 bewegen würde auch ein 18er Prefix reichen. Es gilt:

• /18 = 255.255.192.0 = 172.16.0.0 bis 172.16.63.254
• /17 = 255.255.128.0 = 172.16.0.0 bis 172.16.127.254

Man kann hier also beliebig mit der Maske spielen...eine einzige Route reicht.
Fazit: Du bist also schon vom richtigen und logischen ausgegangen und hast richtig gedacht: Wie bereits gesagt: Eine Route mit größerem Prefix reicht völlig.
Wenn dann Glühweinkasse Nee alles gut, ist ja Weihnachten.

Das geht natürlich nicht, da hast du Recht.
Der Witz ist ja aber das du dieses Gast VLAN ja eben nur ohne IP rein im Layer 2 zur USB "durchschleifst". Logischerweise hat die USG dann mit ihrem Bein in diesem VLAN eine IP Adresse ! Die musst du ihr dann natürlich konfigurieren und auch den DHCP Server dazu.
So bekommen dann alle Gäste IP usw. vom USG ohne das sie irgendeine Verbindung zu den anderen IP Netzen haben. Genau das war ja die Intention !
OK, das ist die gerechte Strafe wenn man so einen Ubiquity Müll kauft aber muss dann einer der UBQT Gurus hier benantworten. Oder du musst doch nochmal Handbuch lesen oder googeln.
Ja, logisch weil du schlicht und einfach vergessen hast im NTP Time Setup des Switches diese US NTP Server zu deaktivieren und nur einen hiesigen aktiv zu halten. Typisches PEBKAC Problem.
https://www.heise.de/ct/hotline/Oeffentliche-Zeitquellen-322978.html

Hier kannst du sehen wie man problemlos ein Gastnetz mit Captive Portal auf der pfSense einrichtet:
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)
Das sollte mit der OPNsense absolut identisch sein.
Ansonsten kannst du hier nachlesen wie man Gastnetze z.B. mit einem Mikrotik einrichtet. Das dynamische VLAN kannst du dir wegdenken.

Was man dann noch so drumherum an Einmalpasswort Verwaltung machen kann siehst du hier:
Voucher für pfSense online verwalten und optional Voucher per SMS verschicken
Captive Portal Plus: pfSense Voucher PDF in der WebGUI von pfSense erzeugen oder an einen Netzwerk Bon Drucker senden

Im Grunde ist das alles kein Hexenwerk und mit ein paar Mausklicks im Setup erledigt.

Das wäre in der Tat essentiell um die Funktion sicherzustellen.
Ooops, warum das ?? Das klappt doch schon im Default Setup der FW ohne das man überhaupt irgend eine Konfiguration machen muss ! Sieht dann eher nach einem grundsätzlichen IP Adressierungsproblem aus, kann das sein ?!
Mmmhhhh...da kann schonmal irgendwas nicht stimmen.... Das Default VLAN 1 liegt ja immer untagged am Uplink (Trunk) von der Firewall zum Switch an und das physische LAN Interface (bei dir also das x.x.1.0 /24 Netz, Paren Interface) IST dann immer das Default VLAN, denn das physische Interface wird immer UNtagged gesendet. Nur die VLAN Interfaces sind immer Tagged mit der VLAN ID. In sofern ist deine Einrichtung falsch, denn du bräuchtest ja nur ein VLAN:

• LAN Interface (physisch, Parent) = UNtagged = .x.x.1.0 /24
• VLAN Interface 40 = Tagged mit ID 40 = x.x.40.0 /24

VLAN 1 ist also immer das physische LAN Interface. Vermutlich ist das der Denbkfehler den du gemacht hast ?! Das Tutorial spricht das auch mit dem Thema "PVID" explizit an.
Bahnhof, Ägypten ?? Welches IP Segment/VLAN soll das sein ??
Da gibt es 3 Optionen:

• Du packst ihn ins Private LAN und erlaubst über das FW Regelwerk rein nur TCP und UDP 53 (DNS) Zugriff aus dem Gastnetz auf den PiHole
• Du packst ihn in ein separates VLAN getrennt von beidem
• Du packst ihn schlicht und einfach in dein Koppelnetz zwischen Firewall und Internet Router. Gut, das geht nur wenn du eine Router_Kaskade betreibst.

Im Falle einer Router Kaskade ist Option 3 das Beste.
Du richtest den DNS Proxy in der Firewall entsprechend richtig ein mit der Weiterleitung auf die PiHole IP im WAN Koppelnetz:
PfSense - web.de wird trotz aktiver "Scheunentor-Regel" blockiert
Das ist die eleganteste Lösung. Ein 2ter DNS Server wäre natürlich Unsinn.

Weit gefehlt...!!! Lesen und verstehen:
Warum gibt es PVID bei VLANs?
Was meinst du genau mit "Internet" ??? Geht das IP technisch nicht, sprich also ein Ping auf eine öffentliche IP wie 8.8.8.8 schlägt auch fehl oder ist "das Internet" für dich lediglich bloß ein nicht funktionierendes DNS ??
Das wäre ja zum Troubleshooting mal wichtig zu wissen !
Ist es nur das bloße Scheitern von DNS Hostauflösungen, ist es ja nicht das IP Routing ins Internet an sich. Hier solltest du in einem Administrator Forum also schon etwas präziser werden. Übrigens nslookup ist hier auch dein bester Freund.
Scheitern nur die DNS Auflösung kann man wohl von einer falschen DNS Einrichtung oder von einem falschen Regelwerk an der Firewall ausgehen. Hier hilft dann, wie immer, das Firewall Log !
Einsicht ist der erste Weg.... Das wird es vermutlich sein.
Was dann natürlich logischerweise fatal und falsch wäre !!!
Die Firewall muss als DNS Server statisch die PiHole IP 172.16.2.2 konfiguriert haben und im General Setup darf NICHT "PPPoE and DHCP can override DNS Settings" angehakt sein !!
Zudem muss es eine FW Regel geben die den Zugang vom .1.0er Netz (und auch anderen Netzen) in das .2.0er Netz regelt ! Ganz besonders was DNS Anfragen betrifft.
Wäre ja Quatsch. Es reicht das Default Gateway des PiHole auf die FW IP 172.16.2.1 einzutragen wie es ja generell für alle Endgeräte üblich ist.
Möglicherweise hast du eine Firewall Regel am neunen PiHole VLAN vergessen ?! Fehlt die, blockt die Firewall wie es bei FW's ja üblich ist dann alles !
Etwas mehr intelligentes Troubleshooting mit Ping und nslookup hilft hier.

Sorry für die harten Worte aber was du da oben machst ist doch Schwachsinn. Weisst du auch selber wenn du dir das mal genau ansiehst !!!
Du kannst doch im nslookup Tool nicht nach einem Hostnamen suchen der "ping 8.8.8.8" lautet. Das ist doch völliger Quatsch.
Wenn, dann gibt man das doch immer in einer Zeile an !! nslookup www.heise.de z.B. und ein Ping hat mit nslookup so viel zu tun wie ein Fisch mit einem Fahrrad. Das ist ein separates Tool um die reine IP Connectivity zu testen und gibt man auch immer direkt am Kommando Prompt ein.
Wenn also dann bitte richtig und sinnvoll nutzen diese Tools !

Desweiteren ist der PiHole Screenshot ebensolcher Unsinn. Diese Settings dort gelten doch nur dann wenn der PiHole selber als DHCP Server arbeitet. Dann gibt er diese IP Range und das dort konfigurierte Gateway raus. Da der Haken oben nicht gesetzt ist und du ja auch den PiHole logischerweise NICHT als DHCP Server benutzt ist das inaktiv. Sorry, aber wenn's...schon an solchen Banalitäten scheitert drehen wir uns im Kreis hier...
Die IP Adresse des PiHole selber konfigurierst du nicht im GUI sondern per SSH (PuTTY, TeraTerm) in der Datei /etc/dhcpcd.conf Dazu benutzt du den nano Editor mit nano /etc/dhcpcd.conf
....
#Example static IP configuration:
interface eth0
static ip_address=172.16.2.53/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
static routers=172.16.2.1
static domain_name_servers=<IP_Provider_DNS>
#.
Wenn du das änderst rebootest du den PiHole danach mit shutdown -r now.
Dann solltest du aus dem Firewall "Diagnostics" Menü mit dem dortigen Ping Tool den PiHole per Ping erreichen können was dann verifiziert das er IP technisch erreichbar ist. Idealerweise testet man das auch einmal mit einer anderen Absender IP eines der anderen Firewall LAN Interfaces um die geroutete erreichbarkeit zu verifizieren.
Das wiederholt man dann auch nochmal mit einem Ping und einen Traceroute von einem Client.
Ist der Ping positiv testet man das dann mal vom Client mit nslookup www.heise.de
Ist das auch positiv rennt der PiHole fehlerfrei.
Wichtig ist das die Firewall den PiHole als DNS Server konfiguriert hat:
Dazu muss die Firewall selber noch korrekt als Resolver eingerichtet sein:
PfSense - web.de wird trotz aktiver "Scheunentor-Regel" blockiert
Sie selber ist dann Proxy DNS zu den Clients und leitet alles an den PiHole weiter der es dann final zu einem deiner auf dem PiHole ausgewählten Upload DNS Dienstleister oder zum Provider DNS schickt.
Das DNS System ist ein simples Baum System.
Du kannst es auch anders machen und im Firewall DHCP Server den Clients direkt die PiHole IP geben. Dann fragen sie statt der Firewall gleich direkt den PiHole, das bedingt dann aber das du zumindesten in den Firewall Regeln immer TCP und UDP 53 für die PiHole IP freigeben musst damit diese Clients den PiHole DNS erreichen können.
Das ping 8.8.8.8 checkt immer nur die eigentliche IP Connectivity um ganz sicher zu sein ob Problematiken reine DNS Problematiken sind oder IP Routing Dinge... So einfach ist das !

He he der war gut ! 🤣
Jupp, was ist denn die 127.0.0.1 für eine IP Adresse ??? Erinnere dich ! .....Richtig... die lokale Loopback Adresse.
Das ist die Firewall selber (Proxy DNS). Sie fragt sich also selber und du hast ja im General Setup dort dann hoffentlich die PiHole IP als DNS angegeben. (Sieh Screenshots oben zum DNS Setup !) Dann leitet die Firewall alles an den PiHole weiter.
Haken entfernen das der DHCP oder PPPOE nicht die DNS IP überschreiben darf !
Zu 99% eine fehlende oder auch falsche Firewall Regel in der Firewall ! Checke das Firewall Log ob dort TCP/UDP 53 Pakete gefiltert werden !
Oder....fehlende Default Route /Default Gateway des Switches auf die Firewall IP !
Oder...falsches Tagging Setup des Switch Uplink Ports
3 Fallen und in eine von denen bist du ganz sicher getappt.
Oh man...und auch noch das Firewall Uplink Interface auf den Switch falsch konfiguriert so das falsche VLAN IDs falschen Ports zugewiesen werden !

Bedenke das das physische Interface immer UNtagged gesendet wird von der Firewall. Die IP die du also auf dem LAN Interface direkt hast wird immer UNtagged gesendet und landet beim Cisco dann bei einer Standard Trunk Konfig in VLAN 1 ! VLAN 1 ist bei einem Cisco Trunk Port mit Default Settings immer das Native VLAN (PVID 1). Es sei denn du setzt es anders im Switch Setup.
Nur die VLANs die in der Firewall unter VLANs gesetzt sind werden mit einer entrechenden VLAN ID die dort eingegeben wurde Tagged gesendet. Wegen der Default 1 VLAN Problematik und möglichen Doppelbelegung am Switch sollte man die ID 1 in der Firewall tunlichst NICHT verwenden sofern man das Native VLAN am Switchport nicht umgeändert hast.
Das nur das du das auch immer auf dem Radar hast !
Langsam kostet das aber "Erschwerniszulage" mit dir hier ! Kontrolliere doch bitte vorab immer einmal die simplen Baiscs eines solchen Setups. Das erleichtert uns allen das Troubleshooting.