@gtrdriver said in Fallback bei GW Groups ?: Wie kann ich denn erreichen dass Seite A regulär eine Verbindung zum WAN1 auf SeiteB aufbaut und wenn WAN1 auf Seite B offline ist dann Wan2 auf Seite nimmt ? Gibt es dafür irgendeinen Mechanismus ? Das hängt davon ab welches VPN man nutzt. :) 1a) IPsec: schwieriger. Multiple Phasen mit gleichen Settings sind nicht parallel nutzbar. Man müsste also zwei VTI (routed) IPsecs bauen und über deren Transfernetze dann sowas wie OSPF sprechen. Früher gabs das noch mit Failover Gateways + Static Routes aber statische Routen können nicht (mehr) auf GW Gruppen aufgelegt werden da das irgendwelche seltsamen Nebeneffekte hatte. Ginge also nur entweder mit OSPF oder vielleicht dann policy based rules mit nem Failover GW über beide VTI Gateways auf beiden Seiten. Müsste man mal testweise bauen um das zu bestätigen. Aber so richtig schön nicht. 1b) IPsec: fummliger. Andere Möglichkeit statt 2 Tunnel wäre ein Tunnel, der statt gegen statische IP stattdessen gegen einen FQDN aufgebaut ist. Den kann man auf einen DynDNS Namen legen und auf Seite B dann einen Job einrichten, der bei Ausfall WAN1 die Adresse von WAN2 in den DynDNS Namen pusht. Dann baut die andere Seite bei < DNS TTL die Verbindung gegen die neue IP auf. Haben wir so tatsächlich schon mal umgesetzt. Läuft, hat aber etwas verzug, weil der DNS Push natürlich laufen muss, sonst klappts nicht. Aber wenn beides Sensen sind und da beide Seiten den Tunnel ja aufbauen können, kann es auch sein, dass dann Seite B via WAN2 initiiert und die andere Seite nur abnicken muss. Das klappt dann relativ zeitnah. Nicht sofort instant, aber in vernünftiger Zeit. Ist eben nur fummliger aufzusetzen. OpenVPN: Da ist es easy was das Failover angeht. OpenVPN kann direkt mit mehreren remote statements konfiguriert werden, hat also Alternativwege schon eingebacken. Lediglich wenn auf Seite B WAN1 wiederkommt, gibt es kein automatisches Fallback. Dazu müsste der Tunnel kurz neugestartet werden. Das ist das einzige kleine Manko. Machen aber viele Firmen trotzdem so und monitoren einfach, mit welcher Gegenstelle verbunden ist und wenn WAN1 auf B wieder da ist wird kurz auf Seite A der Tunnelaufbau neu angestoßen. 1-2s und alles rennt wieder auf WAN1 statt 2. Wireguard. Wenn kein Cluster involviert ist macht WG ja eh was es will und spricht auf allen Interfaces. Wenn die Gegenseite nicht explizit auf WAN1 beschränkt ist und WAN1 ausfällt wird WG von sich aus via WAN2 weiterquatschen und sollte auf Seite A dann auch angenommen werden, weil Key/PSK und Co stimmen. Dann lernt die Seite dass sie jetzt mit WAN2 kommuniziert. Wenn WAN1 wiederkommt, switcht es ggf. sogar zurück. Sehr nett. Hat aber wie gesagt dann andere Problemchen wenn Cluster oder gezielte WAN Nutzung ins Spiel kommt. Overlay VPNs. Also Tailscale, Netbird und Co. Bei denen ist es stark abängig wo der Endpunkt auf beiden Seiten läuft und wie sie konfiguriert sind. Aber da hier die Endpunkte mit der Control Plane sprechen und das primär ne ausgehende Verbindung ist, klappt die Verbindung da eigentlich immer und sollte bei Failover auch korrekt via anderen IPs sprechen. Solange die Standorte Netz haben, kommen auch die Clients raus und können ne Verbindung bauen. Je nachdem wo diese laufen kann man das dann steuern welches WAN sie nutzen. Cheers :)

@paolo256 said in Hilfegesuch bei Telekom VDSL Anschluss mit VIGOR167 und pfSense: Ich nehm den MSS Wert mal raus und schau weiter. Aufgrund des Threads habe ich das mal gemacht und längere Zeit laufen lassen, es kommt wieder zu Problemen das manche Seiten sich per IPv6 überhaupt nicht, oder nur sehr langsam öffnen (z.B. ac-foto.de oder forum.qnapclub.de). Auch wenn es nicht logisch ist, bei mir muss der MSS Wert wieder rein, damit funktioniert der Zugriff per IPv6 reibungslos.

@fireodo said in Hohe CPU Last seit Update auf Version 25.07: Die KEA Implementierung scheint noch etwas (Entwicklungs-) Zeit zu brauchen. Jein, da haperts eher an der Kea-Unbound Interop Geschichte, weniger an Kea. Als reiner DHCP Server ist das fein. Aber die "wir klappern alles in DNS" Sache ist nicht ganz sauber. Allerdings hatte ich subjektiv auch vorher nie den Bedarf, meine Clients in DHCP reinzuhobeln, wenn man den ganzen DNS Integrationskram raus lässt sollte das auch OK sein.

@gtrdriver said in VPN Performance bei S2S: 1: ist es korrekt dass es reicht die MTU mittels mssfix oder tun-mtu nur auf der client Seite anzupassen ? - Die Server Seite bleibt unberührt in der config ? Man kann es an beiden Seiten ändern, wenn der Server es ändert, dann gilt das aber gleich für alle Clients. Bei S2S Tunneln kein großes Thema wenn da ein Server pro Tunnel läuft, für Roadwarrior eher suboptimal, weil da jeder was anderes gern hat. Daher ändern wir das meist testweise auf Clientseite und arbeiten uns da Stück für Stück ran, ob es was bringt. @gtrdriver said in VPN Performance bei S2S: 2: Welche Durchsätze hast du in der Praxis mit OpenVPN erzielt wenn die MTU gut angepasst ist ? Wenn keine seltsamen Sachen am Start sind, die zwischen den zwei Providern Streß machen, haben wir je nach Hardware schon mehr als ordentliche multi-hundert-Megabit Strecken gehabt. Ja mit OpenVPN. Nein, kein Wireguard. Ja, das ist machbar :) Aber eben stark abhängig zwischen den Standorten und was da an Peering, Providern und sonstwas dazwischen quer hängt. Wie gesagt, wir hatten das schon, dass ein Providerwechsel auf Clientseite die ganze Tunnelperformance gekillt hat. Erst nach Switch auf TCP und kleinere MSS war das wieder halbwegs hinnehmbar. Da weiß man leider nicht, was die da treiben, ob die mit irgendwelcher BlackMagic(TM)-Detection-BS irgendwelches Shaping oder dePriorisierung machen oder oder oder. @gtrdriver said in VPN Performance bei S2S: 3: Spricht aus deiner Sicht irgendwas gegen oder für wireguard ? Hängt STARK vom Einsatzzweck ab. Zwei Seiten mit lediglich einer Sense am jeweiligen Ende? Hab Spaß :) Für Homelab/daheim? Hab Spaß oder versuchs ruhig, kein Ding. Für Cluster oder Business? Meh. Wireguard schwebt abgehoben irgendwo im Kernel über den Interfaces und lässt sich nur schwer auf eine bestimmte IP quetschen. Das ist räudig. Wenn man also gezielte Steuerung des Tunnels haben will auf einem bestimmten WAN oder mit einer bestimmten Adresse ist WG mitunter das Werkzeug aus dem 7. Kreis der Vorhölle. Wird dran gebastelt, aber aktuell gibts da nichts wirklich schönes außer mit vielen Regeln und Co den Empfang/Senden zu verbieten, eher nicht so geil. Oder wenn du eindeutige User-Auth machen möchtest von Benutzern bei der Einwahl in ein VPN. WG kennt keine User. Nur Peers. Gegenstellen. Geräte. Das ist KEINE User Authentifizierung, sondern Geräte die sich anmelden. Ob es der User ist - keine Ahnung. Das wäre äquivalent zu OpenVPN mit Zert ohne User+Pass mit Auto-Einwahl. Wird auch nur das Gerät authentifiziert, aber keine Details vom Benutzer. Anbindung an sowas wie LDAP, AD, Radius o.ä. ist auch nicht drin, daher nett, aber im Unternehmenskontext einfach schwierig bis nicht sinnvoll direkt einzusetzen. Neue ZeroTrustAccess VPNs die darauf aufsetzen, wie Netbird, Tailscale etc. sind dann wieder ne andere Sache, denn da übernimmt eben die ZTA Schicht drüber (Control Plane von NB/TS bspw.) die Auth und die Geräte IDs und kann damit dann direkt umgehen, MFA machen, etc. etc. Also als Technik: fein. Als VPN: in Maßen, je nach Einsatzzweck OK. Als Unterbau für ZTAs: sehr cool. Cheers

@gtrdriver Hallo, auf A braucht das erst mal die Route zu B (VPN Gateway). Dazu musst du erst der VPN Instanz ein Interface zuweisen. Damit erhältst du auch ein Gateway, auf das geroutet werden kann. Das Routing sollte wohl mit einer Policy-Routing Firewall Regel gemacht werden. Hier kannst du bspw. den Traffic eine bestimmten Quelle oder zu einem bestimmten Ziel (im Alias definiert) oder beides routen. In den Advanced Options der Regel kann das Gateway angegeben werden. Die Regel muss ganz nach oben geschoben werden, damit sie vor andren zutrifft, die ausgehenden Traffic erlauben. Auf B brauchst du eine Outbound NAT Regel am WAN für die Quelle-IP (od. bspw. das A LAN Subnetz). Dafür muss du den Hybriden Mode aktivieren. Grüße

Nachtrag 2 Stunden später.... Mir hat das alles keine Ruhe mehr gelassen - hab jetzt vor Ort (Client Seite) die Pfsense ausgetauscht gegen eine frisch installierte Variante - nur mal ganz schnell WAN, Lan DHCP und OpenVPN eingerichtet - und die Verbindung ist da und stabil.... Ich fress nen Besen Quer .... Entweder hats beim Update irgend eine Einstellung zerschossen die ich trotz 20 mal drüber schauen nicht gesehen habe oder es hat was am System zerlegt..... Pffffff - spannend ... Grüße GTR

@abt said in VLAN Firewall Rules: Wenn ich in einem pfsense Forum von einem VLAN rede, gehe ich für mich davon aus, dass das VLAN natürlich auf der pfSense angelegt ist. Und die Regeln (firewall rules) sind natürlich auf dem entsprechenden Interface angelegt. Ein VLAN ist auch gern mal auf Switchen vergessen. Oder auf Switchen angelegt aber nicht auf der Sense. Woher genau sollen wir dein Setup kennen, wenn du es nicht näher beschreibst? Und genau "das entsprechende Interface" war schon mehr als einmal Thema hier. Man kann bei Problemen ja auch mal nicht wissen, ob Regeln korrekt auf dem richtigen Interface angelegt wurden oder ob eben doch vielleicht einfach ein Verständnisproblem dazwischen kam und man das statt dessen auf dem falschen Interface angelegt hat. Eben weil von dir keinerlei Konfig oder Screenshot oder Netzbeschreibung außer der FritzBox und den Geräten kam. Ich kann mir dein Setup eben nicht so ganz vorstellen, welche Geräte jetzt hinter der pfSense wo (in welchem VLAN) stehen und wohin wollen und was weswegen konfiguriert wurde. Das kann man mit ner kleinen Skizze, AsciiArt oder was auch immer eben helfen, damit jemand anderes versteht was ich gebaut habe. Aber "Ich habe alles richtig gemacht aber es geht nicht" - ja nun? Wo soll ich da ansetzen was das Problem ist? Darum frage ich eben nach bevor ich Dinge falsch annehme und deshalb denke, dass dort das Problem liegt. Und Regellogik kann ich nur erklären, wenn ich verstehe, was wo angelegt wurde und was wo verortet ist, sonst ist das schwerlich möglich, wenn ich alles erraten muss, dass ich nicht weiß. @abt said in VLAN Firewall Rules: Nun hatte ich aus versehen die Ablehnregel vor die Erlaubnisregel gesetzt und gespeichert. Und das funktioniert jetzt so. Ich komme ins Internet und kann keinen Rechner aus dem WAN erreichen. Die Ablehnregel besagt, dass alles IPV4* aus dem VLAN in das WAN geblockt werden soll. Trotzdem funktionieren DNS und NAT. Wer kann mir diese Logik erklären? Niemand, wenn du keinem verrätst, was du überhaupt als DNS konfiguriert hast, wohin NAT wie definiert ist und wie deine Regel zum Verbieten/Erlauben von irgendwelchem Zugriff auf "WAN" Seite aussieht. Ohne konkrete Details kann man nur raten oder rückfragen. Meine Glaskugel-Vermutung wäre WAN ist auf 192.168.178.0/24, das wurde per Regel verboten DNS ist auf VLAN Geräte IP der Sense gesetzt und das ist natürlich nach wie vor erlaubt, pfSense macht via Unbound selbst DNS, darum geht DNS NTP wird via DNS auf irgendwelche NTP Pools im Netz aufgelöst, darum geht NTP Internet geht, weil Internet nicht WAN ist. Also wahrscheinlich alles genauso wie es soll. Nur gehst du wahrscheinlich von ein paar falschen Annahmen aus (aka WAN=Internet oder WAN geblockt = Internet geblockt etc.) Von Freigaben ist keine rede gewesen. Wenn ich Traffic freigebe, mach ich eben eine Freigabe für Daten von a nach b. Dazu leg ich ne Regel an. Entschuldige, dass ich das so lax mal umgangssprachlich geschrieben habe und nicht Firewall Policies o.ä. Aber wenn die Antworten schon so potentiell ablehnend zurück kommen, ist vielleicht keine Hilfe gewünscht. Dann halte ich mich auch gerne raus, kein Problem. Cheers

@sub2010 Idee ja, jedoch keine Lösung, und letzteres ist ja, was du suchst laut Titel. Und mit Plex habe ich keinerlei Erfahrung. Daher weiß ich auch nicht, wie der Stream vom Server zum Plexamp Client kommen soll. Streamt da die App am Smartphone zum Client, oder wird das nur benötig, um die Verbindung herzustellen und den Client zu steuern? Wenn nicht bekannt, könntest du das mal austesten. Wäre ggf. hilfreich. Ich würde vermuten, dass die App in den Stream eingebunden ist. Und dafür könnte ein weiteres Protokoll erforderlich sein, vielleicht UPnP / DLNA. Um herauszufinden, was die Geräte benötigen, könntest du ein Packet Capture an beiden Interfaces jeweils mit einem IP Filter auf Smartphone bzw. Plexamp Client und UDP laufen lassen. Schau dir an, was so auf Broadcast u. Multicast IPs geht. Dann ist mir nicht klar, was genau ist diese Unify Zeugs? Ist das tatsächlich nur ein AP und das Subnetz der Clients liegt an der pfSense an? Ist es nicht eine Mesh-Konstrukt?

Update auf 2.8 hat jetzt auch funktioniert, danke Gruß

@Markus4210 said in Lokale IP über Virtuelle IP "Umleiten": 9981 http abfrage m3u , stream dann über 9982 htsp. Würde es nicht reichen, nur m3u über HAproxy laufen zu lassen? Wenn da nicht kommt bzw. "Wartung" kommt, wird es ohnehin keinen Versuch geben, den Stream zu kontaktieren, oder? Ja und habe gesehen das PFSense Files im HA Proxy bereitstellen kann. Wärs da nicht noch klüger gleich bei Ausfall die "wartungs m3u" in der PFSense bereit zu halten. Damit habe ich leider keine Erfahrung. Wenn es möglich ist, das File als "Backup Backend" auszuliefern, wäre das eine Option.

@esquire1968-0 Puh, war jetzt mal davon ausgegangen, dass der Host bei dir in der Wihnung, der Firma steht. Viel kann man bei dem was das in deinem Bild zu sehen ist an virtueller Hardware auch nicht konfigurieren. 1 GB empfinde ich an RAM inzwischen aber als recht wenig. Konkrete Ideen habe ich da jetzt keine, außer mal mind. 2GB RAM zu testen. Meine virtualiesierte pfsense hat 6GB. Ich würde mich mal an den Support von Netcup wenden.

@Nico-Borsch Ist zwar Off-Toppic, aber du kannst alle LAN-Regeln unterhalb der IPv6 Default rule löschen, da diese eh niemals greifen, solange die Alles-erlauben-Regeln aktiv sind. ;-) Sieht so aus als würdest du ADS nutzen? Die Sense kennt somit die Domain-Clients nicht. Damit das funktioniert, musst du im DNS-Fowarder oder Resolver auf der Sense Domain-Overrides für deine ADS-Domain einstellen. xmodus.local 192.168.150.27 ADS DNS 1 150.168.192.in-addr.arpa 192.168.150.27 ADS DNS PTR 1 xmodus.local 192.168.150.28 ADS DNS 2 150.168.192.in-addr.arpa 192.168.150.28 ADS DNS PTR 2 Jeweils pro Server einen forward und einen reverse-lookup Eintrag. Dass deine Clients andere lokale Clients im Netzwerk auflösen können, liegt daran, dass sie nicht über die pfSense gehen.

Ich habs mittlerweile hinbekommen. Falls es jemandem hilft: Hier das config Snipped für telegraf.conf [[inputs.tail]] files = ["/var/log/filter.log"] from_beginning = false pipe = false watch_method = "inotify" # Data Format Configuration data_format = "grok" # Simple pattern that captures the syslog header and comma-separated filterlog data grok_patterns = [ #IPv4 "%{SYSLOGTIMESTAMP:timestamp} %{DATA:hostname} %{WORD:process}\\[%{INT:pid}\\]: %{INT:rule_number},%{DATA:sub_rule},%{DATA:anchor},%{DATA:tracking_id},%{DATA:interface},%{DATA:reason},%{DATA:action},%{DATA:direction},%{INT:ip_version},%{DATA:TOS},%{DATA:ECN},%{DATA:TTL},%{DATA:ID},%{DATA:offset},%{DATA:Flags},%{DATA:protocol_id},%{DATA:protocol},%{INT:length},%{DATA:source_ip},%{DATA:destination_ip},%{INT:source_port},%{INT:destination_port},%{INT:data_length}" , #IPv6 "%{SYSLOGTIMESTAMP:timestamp} %{DATA:hostname} %{WORD:process}\\[%{INT:pid}\\]: %{INT:rule_number},%{DATA:sub_rule},%{DATA:anchor},%{DATA:tracking_id},%{DATA:interface},%{DATA:reason},%{DATA:action},%{DATA:direction},%{INT:ip_version},%{DATA:class},%{DATA:flow_level},%{DATA:hop_limit},%{DATA:protocol_id},%{DATA:protocol},%{INT:length},%{DATA:source_ip},%{DATA:destination_ip},%{INT:source_port},%{INT:destination_port},%{INT:data_length}"] # Custom measurement name name_override = "pfsense_filterlog" # Static Tags [inputs.tail.tags] log_type = "pfsense_firewall" Hab noch nen Spalten-Dreher im IPv6 Pattern drinnen und das Grafana-Output muss ich noch etwas hübsch machen. Aber im Groben tuts was ich wollte. [image: 1750060313758-1e05e1f5-536c-490f-af9f-93d40c974229-image-resized.png]

@Wischi83 said in Problem mit Next Server Adress Weitergabe durch DHCP: @Wischi83 said in Problem mit Next Server Adress Weitergabe durch DHCP: Das. Wenn manuell 32 geschickt wird und trotzdem auf 9 gebootet wird, kommt das nicht von der Sense. Dann sucht man sich da zu Tode, weil es nicht der Grund ist :) Cheers Dagegen spricht @Wischi83 said in Problem mit Next Server Adress Weitergabe durch DHCP: @JeGr gegen die Theorie stimmt ja das eine Hardware Maschine ebenfalls den 1.9 anfrägt. Ich werd deine Ideen aber selbstverständlich bei Zeit durchspielen. Wir drehn uns im Kreis, das führt alles zu nix. Ich werd die pfsense bei Zeit neu aufsetzen, bzw das nächste Update abwarten, eventuell wird das Problem durch eine der beiden Massnahmen gefixt Das spricht nicht dagegen, dass es durchaus sein kann, dass die Info NICHT von der Sense kommt. Rogue DHCP sind ein Ding. Falsche Bootserver sind ein Ding. Switche, die L2-smart/L3 können und dazwischengrätschen sind ein Ding. Ich habe keine Ahnung was in deinem Setup alles involviert ist. Es muss nicht alles immer ein Firewall Problem sein. Und wenn noch dazu nicht einmal ein TCPdump zeigt, dass die Sense hier falsche Werte vergibt, tue ich mir sehr schwer, hier mit dem Finger auf die Sense zu zeigen und zu sagen "Ha! Genau, der DHCP/Kea macht da Mist!". Das klingt dann eher nach "irgendwas/wer merkt sich alte Werte". Und was und warum sind schwer zu debuggen. Aber es wäre ja einfach, mal den DHCP der Sense einfach komplett abzuschalten und dann das ganze nochmal durchzuspielen. Denn wenn dann immer noch falsch gebootet wird, wie soll dann die Firewall schuld sein? Cheers :)

@JeGr ich gebe Ihnen Recht, was die Einfachheit einer pfsense/OPNsense angeht, um "Regelsalat" zu verhindern. Und auch verstehe ich Ihren Einwand, das dadurch viele Support-Abfragen reinkommen können. Seinen Sie gewiss, ich habe lang genug Level 1 bis Level 3 Support gemacht. Es sollte sich grundsätzlich die Frage gestellt werden, für was benötige ich eine Firewall, und was sollte mir die Firewall liefern bzw. schützen. Und natürlich ist für mich eine Firewall keine Spielwiese, sondern ich weiß was für ein Regelwerk ich benötige und haben möchte, und was nicht. Gut das ich mit der Meinung von vorgefertigten Floating Rules bei pfsense/OPNsense nicht alleine stehe, und Foren genau mit dem Thema gut gefüllt sind. Zudem sollten man sich fragen, warum etablierte Firewalls wie Fortinet/Juniper, Check Points keine Standard Allow/Floating Rules haben (DENY ALL first), und explizite Management Ports. Zudem ist eine Standard Rule mit DNS/HTTP(s) schnell von LAN to WAN erstellt, und erzeugt kein "Regelwerksalat". Eine DENY ANY ANY Rule am Ende des Regelwerks, die zuerst LOGs erstellt, um zu sehen warum ein Client nicht funktioniert, und die dazu gehörigen Ports dann öffnet (wenn gewünscht), ein Standard Prozedere. Aber nochmals, ich gehe konform mit Ihnen, das es für den Home User, einfach wie möglich gemacht werden sollte, trotzdem sollte man für erfahrene User die Freiheit geben werden, eine pfsense/OPNsense selbst zu kontrollieren und zu managen. Auch ich sehe kein Problem, eine Abfrage beim Setup einzubringen, ob ich Standard allow floating Rules haben möchte oder nicht und dann eben nur die Management Ports Rule erstellt. Ich verstehe Ihre Support Sichtweise und wünsche Ihnen und Ihrem Team noch stressfreie Support-Tage.

@heiko3001 Stell das doch mal ins englische Forum hier. General pfSense Questions oder IPv6.

@heiko3001 said in Kein Zugriff auf Dienste trotz Portweiterleitung: @Bob-Dig Ich könnte dich knutschen, das ist die Lösung. Leider wurde es in 2.8 nicht gefixt, aber jetzt weiß ich Bescheid. Genial! Ich hatte so ein bisschen die Patches in Verdacht, aber explizit darauf wäre ich nicht gekommen. Wenn die State Policy das Problem ist gibt es aus irgendeinem Grund an einer Stelle asymmetrisches Routing, was ein Netzwerk-Designfehler ist. Das liegt nicht an "das ist kaputt", sondern meistens an einem Problem im Netz. Darum hat @viragomann da völlig recht, dass man dazu erstmal die Details zum Netz un den betreffenden Regeln bräuchte um das genau zu verstehen. Kaputt oder ein Fehler ist das aber nicht. Das Verhalten ist schon seit 24.03 in Plus drin und funktioniert dort genau wie es soll. Wenn es Probleme gibt, dann liegen die zu >90% an einem Problem beim Routing, nicht an "das neue Feature/Setting ist kaputt" :) Cheers

Feedback nach fast 24h. Es hat geholfen und ich habe keine Crashreports mehr und eine DNS Registrierung benötige ich nicht, daher top zufrieden nun mit 2.8.0. Grüße

Hallo Bob.Dig, danke für die Antwort. Ich gehe leider auch entsprechend davon aus, dass es mit den Einstellungen nicht möglich ist. Zu deiner Lösung mit dem DNS Forwarder muss ich mal testen ob der DNS Forwarder dann alle DNS-Features unterstützt / weiterreicht, die für den SIP-Trunk benötigt werden. Lieber wäre mir eine unmittelbare DNS Auflösung der (unterstützen) Endgeräte wie die TK-Anlage: https://hilfe.companyflex.de/de/grundlagen/systemvoraussetzungen Ich dachte vielleicht kennt jemand einen "Trick" wie ich z.B. für ein Subnet z.B. eine Variable von DNS-Server per DHCP vergeben könnte, bei der die Variable zuvor von den PPPoe DNS-Servern ausgelesen / bestimmt wird, o.ä.