09.02.2025, aktualisiert um 12:06:13 Uhr

1764

OPNsense DNS "halb tot" - Keine Auflösung nach längerer Zeit

Ich habe ein merkwürdiges Problem, ich bilde mir ein, dass es erst mit dem Update auf Version 25.1 von OPNsense so richtig schlimm wurde, kann mich aber auch irren...

Nach einem Reboot der OPNsense läuft alles super, schneller Seitenaufbau, alle Seiten werden geladen.
Es laufen Unbound und AdGuard.

Nach längerer Zeit, beispielsweise über Nacht geht fast nichts mehr. Ich komme mit viel Geduld auf die ein oder andere Website, aber dann auf einmal auch nicht mehr. Ich wollte beispielsweise hier schreiben, dann was googlen (ging auch) aber die Treffer von Google laden alle nicht mehr, wenn man sie dann öffnen will.

Selbst wenn ich dann Unbound und AdGuard deaktviere und manuell z.B. 8.8.8.8 eintrage geht trotzdem nichts.

Ping auf die 8.8.8.8 läuft aber noch.

Wie gehe ich denn hier systematisch vor, wenn das Problem wieder auftritt, was soll ich sammeln?
Kann ich irgendwelche Logs anschalten?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 671234

Url: https://administrator.de/forum/opnsense-dns-halb-tot-keine-aufloesung-nach-laengerer-zeit-671234.html

Ausgedruckt am: 12.03.2025 um 21:03 Uhr

51 Kommentare

Neuester Kommentar

Moin,

mach DNS Abfragen und schau, welcher Server welche Antworten liefert, um einzugrenzen, ob es an DNS liegt.

Gruß

DivideByZero

Moin,

was sagen die Logs der einzelnen Geschichten?
Hast du schon getestet den AppGuard zu deaktivieren und danach einen Neustart durchzuführen? Ggf. hängt dort etwas schief.

Gibt es im Forum ähnliche Berichte? Ich habe mich noch nicht ans Upgrade getraut.

Gruß
Spirit

Zitat von @DivideByZero:
mach DNS Abfragen und schau, welcher Server welche Antworten liefert, um einzugrenzen, ob es an DNS liegt.

Also einfach ein paar nslookups wenn das Problem wieder auftaucht und hier posten?

Zitat von @Spirit-of-Eli:
was sagen die Logs der einzelnen Geschichten?
Hast du schon getestet den AppGuard zu deaktivieren und danach einen Neustart durchzuführen? Ggf. hängt dort etwas schief.

Gibt es im Forum ähnliche Berichte? Ich habe mich noch nicht ans Upgrade getraut.

Welche logs meinst du?
Welche Logs meinst du genau? Irgendwas, das ich speziell aktivieren müsste?

Firewall Traffic Logs, Logs des Unbound, Logs von deinem AppGuard.
Wenn du keinen Syslog Server verwendest, dann solltest du hier just in time drauf schauen.

Zitat von @gruenhorn:

Zitat von @DivideByZero:
mach DNS Abfragen und schau, welcher Server welche Antworten liefert, um einzugrenzen, ob es an DNS liegt.

Also einfach ein paar nslookups wenn das Problem wieder auftaucht und hier posten?

Grundsätzlich ja, aber eigentlich brauchst Du das hier nicht zu posten, es soll Dir zeigen, wo beim Ausfall welcher Nameserver antwortet oder eben auch nicht. Also nachverfolgen, ob DNS läuft (ggf. ist da eben ein anderer Dienst, der quer schießt, was Du anhand der rückübermittelten IP-Adressen (wenn denn welche kommen) sehen solltest).
Was ist das eigentlich für ein AppGuard, den Du da mit im Spiel hast?

Sorry, irgendein Autocorrect hat aus AdGuard AppGuard gemacht

Ich korrigier das mal oben, sonst verwirrt das nur noch mehr

Was helfen würde wären zielgerichtete Informationen (Screenshots etc.) WIE deine DNS Konfig auf der Firewall (Resolver, Forwarder etc.) überhaupt aussieht um nicht wirr im Trüben stochern und raten zu müssen.

Da gehts ja schon los, was ist denn da alles relevant?

System Settings General

Unbound Settings:

Was aus AdGuard hilft?

Crazy, wieso läuft dein Unbound auf Port 53053?
Wie hast du das deinen Clients mitgeteilt? Ich hätte gesagt, die greifen hier im Fallback auf die ISP DNS Server zurück welche per DHCP an der Firewall landen.

Moin,
kurz am Rande.
Ich hatte das neulich bei einem vServer von mir, dass 8.8.8.8 keiner seiner DNS-Anfragen beantwortet hatte.
Probiert mal ein nslookup administrator.de 8.8.8.8 ob da überhaupt was zurückkommt.

Stefan

Zitat von @Spirit-of-Eli:

Crazy, wieso läuft dein Unbound auf Port 53053?
Wie hast du das deinen Clients mitgeteilt? Ich hätte gesagt, die greifen hier im Fallback auf die ISP DNS Server zurück welche per DHCP an der Firewall landen.

AdGuard braucht 53 und man soll daher Unbound auf irgendwas anderes legen, so die Anleitungen im Netz.
Standardmäßig wird 5353 erwähnt, aber das kann mit mDNS kollidieren (?)

Zitat von @StefanKittel:

Moin,
kurz am Rande.
Ich hatte das neulich bei einem vServer von mir, dass 8.8.8.8 keiner seiner DNS-Anfragen beantwortet hatte.
Probiert mal ein nslookup administrator.de 8.8.8.8 ob da überhaupt was zurückkommt.

Teste ich wenns das nächste mal zickt

gruenhorn 09.02.2025 aktualisiert um 12:46:26 Uhr

Zitat von @Spirit-of-Eli:

Crazy, wieso läuft dein Unbound auf Port 53053?
Wie hast du das deinen Clients mitgeteilt? Ich hätte gesagt, die greifen hier im Fallback auf die ISP DNS Server zurück welche per DHCP an der Firewall landen.

AdGuard braucht 53 und man soll daher Unbound auf irgendwas anderes legen, so die Anleitungen im Netz.
Standardmäßig wird 5353 erwähnt, aber das kann mit mDNS kollidieren (?)

Achsoo okay, das ergibt Sinn. Was passiert wenn du DNS Anfragen direkt an den Unbound stellst?
Ich finde gerade allerdings keine Option beim nslookup einen Port mitzugeben.

Ok, mutmasslich ist der AdGuard dann für Dein Netz der zentrale Nameserver, der über DHCP verteilt wird? wenn ja, dann würden die Anfragen an AdGuard und von da an den Upstream Server gehen. Wo genau ist denn dann Unbound eingebunden?
Du solltest ggf. erst einmal diese Konfigurationen prüfen und - wenn dort, vermutlich, Fehler zu finden sind, anhand eines Tutorials etc. von Grund auf neu einrichten.

Kann ich Dir gleich sagen ob das auch auf der 25.1er läuft. Mache gerade das Upgrade ;)

Ok, mutmasslich ist der AdGuard dann für Dein Netz der zentrale Nameserver, der über DHCP verteilt wird?

Zeigt eigentlich wie unstrukturiert und wirr der TO vorgeht.

Keiner weiss ob der Adguard in das Firewall OS reingefrickelt wurde oder als separater Server rennt. Bei Letzterem ist ein unsinniges "Verbiegen" der DNS Standardports völlig überflüssig und auch kontraproduktiv!
So oder so ist die gesamte Vorgehensweise laienhaft und unstrukturiert.
Intelligent würde man vorgehen indem man zuallererst eine saubere Firewall VLAN Infrastruktur aufsetzt an einem Dual Stack Provider ohne alle diese Frickelei Sonderlocken.
Dann testet man alles auf Herz und Nieren und weiss das man eine sauberes, nach allen Regeln funktionierendes Setup hat. Erst dann "verschlimmbessert" man schrittweise mit Frickelei das was man möchte.
So hat man dann immer Gewissheit das die Frickelei die Ursache ist und nicht die Infrastruktur selber.

Ein klassisches Firewall VLAN Setup mit der FW als Caching DNS ist in max. 1 Stunde aufgesetzt. Man benötigt keinerlei Regel oder NAT Frickeleien für VoIP oder DNS denn alles rennt "out of the box" bei der OPNsense mit den Standard Settings.
Der TO zäumt das Pferd (Firewall) von hinten auf. Verfrickelt DNS, NAT und Regelwerk und sucht dann 3 Tage mit Forenhilfe nach dem Fehler.

Also ganz grundsätzlich läuft Adguard auch mit 25.1. Ich habe sowohl meine Anfragen darüber laufen, als auch die Blocks laufen problemlos nach dem Update.

Mh okay sorry sorry, unbound läuft gar nicht...
Ich dachte ich hätte Unbound als Upstream Server eben dann über den 53053 Port definiert, aber die Einstellung hab ich scheinbar nie gespeichert in AdGuard...

Jetzt steht in AdGuard https://dns10.quad9.net/dns-query als Upstream Server.

Also, Unbound wird aktuell nicht verwendet!

Aber: Ich deaktiviere AdGuard wenn ich Probleme habe und trage dann entweder keinen oder halt irgendeinen anderen, meinetwegen 8.8.8.8, händisch in System Settings General ein.

Was ist daran jetzt Gefrickel? Das Troubleshooting findet ja quasi auf einer Serieneinstellung statt.

Gefrickel muss da sein, das zeigen die vielen Symptome aus Deinen verschiedenen Threads.
Die ehrliche Empfehlung für Dich lautet also: keep it simple!
Lass alles weg, wovon Du offensichtlich nicht ausreichend Ahnung hast. Also kein Adguard, kein Unbound, kein eigener Upstream-Server. Einfach nur die vom Provider übermittelten DNS nutzen (automatisch, nichts eintragen), und dann erst einmal schauen, dass alles so läuft und stabil läuft, wie Du es wünschst.

Erst dann, wenn das der Fall ist, beginne mit den weiteren Steps, wie z.b. den Adguard dazwischen zu hängen. Und auch den mit Standard-Einstellungen. Dann wieder testen, dass alles so läuft und stabil läuft, wie Du es wünschst.
Erst danach individuelle Anpassungen.

Denn das hier macht keinen Sinn: uns halb gare Informationen liefern, mit denen wir rumraten und nicht sinnvoll helfen können und wo erst Stück für Stück heraus kommt, dass die Grundlage eine ganz andere ist, als anhand Deiner Informationen gedacht.

Ja, Message ist angekommen.

Dennoch meine ich, dass ich doch gar nichts an den DNS Einstellungen großartig "verkacke"

Unbound ist nicht auf Port 53, also läuft da nichts drüber.

Im System trage ich entweder keinen DNS ein oder eben Google.

Und AdGaurd deaktiviere ich, dann gehts da auch nicht mehr über den eingestellten Upstream Server (der übrigens auch Standard Einstellung von AdGuard ist, der sollte ja prinzipiell funktionieren, oder?)

Sonst habe ich gar nichts gemacht. ist die Serieneinstellung nicht sogar mit Unbound aktiviert?

Der ganze Firewall Regel-Kram: Ich hab da zwar viel drin stehen, aber ich deaktiviere das alles wieder wenn es nichts bringt. Ich erinner mich damit nur gerne daran, was ich bisher ausporbiert habe...

Sonst habe ich gar nichts gemacht.

Hmm, siehe auch Internet auf Interfaces (+ VLAN) sauber durchschleifen.

Daher der Rat, es so simpel wie möglich zu machen. Steck Deine "alte" Fritz!Box ab, nimm die Voip-Fritz!Box raus (wenn ich bei Deinem Aufbau noch richtig durchblicke), stöpsel jedes Gerät ab, was irgendwie noch Serverdienste laufen lassen könnte (Unraid, Synology), und konzentriere Dich dann auf Deine Firewall ohne Unbound und Adguard. Wenn dann das ganze stabil läuft, Stück für Stück wieder dazu nehmen.
Und nicht anders. Denn es sieht so aus - sieh mir die offenen Worte nach -, als wenn Du ohne große Ahnung immer dann gleich an ganz vielen Schrauben drehst und nur neue Folgeprobleme schaffst. So wird das nichts.

Du solltest wohl auch testen, ob die Internetprobleme in allen VLANs auftreten, oder nur in einem bestimmten.

Na, wenn Du adguard deaktivierst und der unbound das managed, müsstest Du doch beim unbound mind. auch wieder die 53 reinpacken?! Außerdem nutzt man nicht Google als DNS, sondern quad9 oder quad1 als DNS-Uplink. Die behaupten wenigstens, dass sie Dich nicht tracken – Google dagegen wirbt damit, Profile anzulegen und zu verkaufen.

Daher der Rat, es so simpel wie möglich zu machen. Steck Deine "alte" Fritz!Box ab, nimm die Voip-Fritz!Box raus (wenn ich bei Deinem Aufbau noch richtig durchblicke), stöpsel jedes Gerät ab, was irgendwie noch Serverdienste laufen lassen könnte (Unraid, Synology), und konzentriere Dich dann auf Deine Firewall ohne Unbound und Adguard. Wenn dann das ganze stabil läuft, Stück für Stück wieder dazu nehmen.

Die alte Fritz ist schon ab, es steckt nichts anderes dran, nur noch der AP und zwei Clients(einer davon Gast)
Unraid und Synology hatte ich beide noch nicht an seit ich die OPNsense dran gebaut hab. Adguard lass ich jetzt weg, passt, Unbound ist dann ja eh übergangen und kann deaktiviert werden.

Das nervigste ist nur, dass es halt mal ins Stocken kommt und nach nem Neustart ist das meiste erledigt...

Ich beobachte das jetzt mal, kann ja nicht sein...

Zitat von @Visucius:

Na, wenn Du adguard deaktivierst und der unbound das managed, müsstest Du doch beim unbound mind. auch wieder die 53 reinpacken?! Außerdem nutzt man nicht Google als DNS, sondern quad9 oder quad1 als DNS-Uplink. Die behaupten wenigstens, dass sie Dich nicht tracken – Google dagegen wirbt damit, Profile anzulegen und zu verkaufen.

Ja, wie oben erwähnt, ich dachte ja, dass ich den Unbound Port wieder beim Upstream Server reingeschrieben hatte, aber danach hab ich wohl nie auf speichern geklickt und es dann auch nie wieder angeschaut. Dann bin ich mit AdGuard auf Quad9 gelandet, ist ja prinzipiell nicht schlecht. Ich lass der Einfachheit halter aber dann den Systemeintrag leer, vorher hat es mit o2 ja funktioniert, ist vielleicht auch leichter für meine VoIP Einrichtung...

Ich habe so mittlerweile die Vermutung, dass mein Modem mir da einen Streich spielt.
Ziemlich zuverlässig habe ich morgens Probleme...
Könnte das die automatische Zwangstrennung durch den Anbieter sein, an der sich das Modem verschluckt?
Heute habe ich wieder keine ordentliche DNS Auflösung gehabt und als ich dann z.B. einen Ping auf Google versucht habe fiel mir auf, dass ich gar keine IP mehr auf dem WAN Interface habe.

Habe jetzt einen Zeitplan eingerichtet, dass der Router jeden morgen um 4 Uhr rebootet.
Bin gespannt, ob es dann besser wird.

edit: ich glaube das geht eleganter und ohne eine Trennung des DSLs, nur mit einer Neueinwahl des PPPoE Interfaces...

So far so good...

Ist da irgendwas bekannt, dass die Anbietertrennung die Einwahl aus dem Takt bringen kann?

Was willste wissen?! Ob Mio. von Fritzboxen ein Problem mit der Zwangstrennung haben? Oder die OPNsense? Im Gegensatz zu Deiner hängt meine OPNsense direkt an der Telekom Glasfaserleitung. Da ist mir nix aufgefallen, das läuft "rockstable"

Und Dein Modem? Keine Ahnung. Vielleicht konkret ein neuer Thread mit Nennung des Modems im Titel?

A la: Modem xyz - Probleme mit Zwangstrennung

Damit findest Du bestimmt leichter einen potenziellen Leidensgenossen.

Ne, die Fritzbox hat ja standardmäßig eine automatische Trennung um 2 Uhr nachts oder so eingestellt um der Zwangstrennung durch den Provider zuvorzukommen.

Wobei das Zwangstrennen ja nach meinem Verständnis die Synchronisation aufrecht erhält, so dass die Nummer viel schneller stattfindet und auch nicht negativ als Abbruch in der Statistik auftaucht. Also nur ein Abmelden der Einwahl.

Meine Frage ist dann, ob entweder die OPNsense oder das DrayTek Vigor 167 ein Problem damit haben, wenn der Provider zwangstrennt und deswegen solche DNS Probleme auftreten...

die Fritzbox hat ja standardmäßig eine automatische Trennung um 2 Uhr nachts oder so eingestellt

Nöö, die Fritte nicht. Das initiiert einzig immer der Provider! Mit der Fritte hat das rein gar nix zu tun!

Wobei das Zwangstrennen ja nach meinem Verständnis die Synchronisation aufrecht erhält

Richtig. Das ist nur das PPPoE was runterfällt und neu ausgehandelt wird der Modemsync bleibt. Initiiert nur vom Provider wohlgemerkt!

ein Problem damit haben, wenn der Provider zwangstrennt und deswegen solche DNS Probleme auftreten...

Nein, denn die PPPoE Daten wie Gateway, DNS usw. werden ja neu ausgehandelt und der dynamisch via PPPoE ausgehandelte DNS überrennt ja einen ggf. fälschlich statisch Konfigurierten. Natürlich nur wenn man NICHT den Haken gesetzt hat im Setup was das außer Kraft setzt!!

Das ist die Standardeinstellung in den Fritzboxen...

Natürlich nur wenn man NICHT den Haken gesetzt hat im Setup was das außer Kraft setzt!!

Welchen Haken meinst du jetzt genau?!

Den Haken "PPPoE DNS will override static DNS" im OPNsense Setup...

System - Settings - General "Allow DNS server list to be overridden by DHCP/PPP on WAN"

Ist angehakt, ja

Zitat von @gruenhorn:
Meine Frage ist dann, ob entweder die OPNsense oder das DrayTek Vigor 167 ein Problem damit haben, wenn der Provider zwangstrennt und deswegen solche DNS Probleme auftreten...

Nein, im Normalfall nicht. Im Gegenteil, das Modem läuft ausgesprochen stabil 24h/365. Dürfte also eher eine Besonderheit der Konfiguration bei Dir sein.

Also die "Verschlucker" über Nacht sind weg seit das mit dem Interface Reset läuft...

Nachdem ich ja irgendein Problem/falsche Einstellung bei der DNS Geschichte hatte und nun mit händisch eingetragenen o2 DNS Servern für den Moment beim VoIP klar komme wollte ich es trotzdem mal "richtig" machen jetzt...

ich würde tatsächlich gerne AdGuard nutzen, das mit der grafischen Oberfläche ist ganz angenehm.

Nutzt man das nun standalone oder soll das nochmal an Unbound forwarden?

Perspektivisch würde ich gern auch DNS over TLS betreiben. Da die gleiche Frage, an welcher Stelle?

Und meine o2 DNS Server muss ich für die Adresse sip.alice-voip.de dauerhaft hinterlegen, nur an welcher Stelle in der Kette?

Standalone auf einem 15 Euro RasPi Zero etc. wäre sicher die bessere Wahl...
DNS over TLS dann natürlich auch über die Uplink DNS Server auf dem Adguard.
Standalone macht dich deutlich flexibler, da du die VoIP Geräte die vom O2 DNS abhängig sind vom Adguard ausnehmen kannst. Auch wenn der Adbuard mal offline ist kannst du über einen einzigen Eintrag im DHCP den Endgeräten wieder die Firewall geben und hast so einen schnellen Workaround.

nur an welcher Stelle in der Kette?

Wie oben schon gesagt: nur bei den VoIP Geräten. Die dürfen vom DHCP nur den O2 DNS bekommen

Ich hätts gerne alles in OPNsense ehrlich gesagt...

Wenn ich in der Fritzbox die o2 DNS Server reinschreibe, können die dann benutzt werden oder überschreibt AdGuard die wieder? Oder muss das dann in Adguard als AUsnahme für den einen o2 Server irgendwo hinterlegt werden?

Und wie gestalte ich bei Unbound und Adguard die Reihenfolge bzw brauche ich überhaupt Unbound wenn ich Adguard nutze?

ich habe das Setup ähnlich Deinem laufen. Können wir gerne mal vergleichen.

System > Settings > General: DNS Servers:
9.9.9.9
2620:fe::fe
1.1.1.1
(jeweils use gateway: none)

Services > adguard:
2 x on

Services > unbound > general:
Enabled
5353
All (recommended)
...
local zone type: transparent

adguard Home > Settings > DNS-Settings > Upstream DNS:
https://dns10.quad9.net/dns-query
https://security.cloudflare-dns.com/dns-query
tls:dns.quad9.net
tls:security.cloudflare-dns.com

Parallel requests

Fallback: 8.8.8.8

Bootstrap DNS Servers:
1.1.1.1
9.9.9.9
2606:4700:4700::1111
2620:fe::fe

Private reverse DNS:
Da habe ich jetzt im Prinzip die IP der OPNsense innerhalb der vLANs hinterlegt a la 192.168.178.1, 192.168.179.1, usw.

Use private reverse DNS resolver: on

Enable reverse resolving of clients IP addresses: on

der Rest darunter sollte Standard sein ...

Viel Erfolg.

Zitat von @Visucius:
Viel Erfolg.

Super, danke

An welcher Stelle kommunizieren Unbound und AdGuard da eigentlich miteinander?

Fallback: 8.8.8.8

Besser nicht wenn man vor Dr. Google nicht nackig mit heruntergelassenen Hosen stehen will!!

https://privacy-handbuch.de/handbuch_93d.htm

Steht doch davor: FALLBACK

aber jetzt noch mal die Frage: Was tut Unbound hier noch?!
Also fehlt nicht noch der Upstream Eintrag in Adguard zu Ubound?

Private reverse DNS:
Da habe ich jetzt im Prinzip die IP der OPNsense innerhalb der vLANs hinterlegt a la 192.168.178.1, 192.168.179.1, usw.

Use private reverse DNS resolver: on

Enable reverse resolving of clients IP addresses: on

wenn ich das mal nachlese, dann beantwortet das meine Frage, oder?

So?

So die DNS Auflösung für sip.alice-voip.de machen?

Okay, das mit dem DNS Override funktioniert nicht ...

Kann ja auch nicht, lies mal nach, was die Funktion macht: homenetworkguy.com/how-to/create-unbound-dns-override-aliases-in-opnsense/

ChatGPT taugt echt gar nix bei Netzwerkfragen

Wie meinen?

Warum trägst du nicht einfach bei deinem VOIP Gerät/Geräten deine Alice als DNS ein.
Dann hast du das Problem umschifft es auf der Sense umbiegen zu müssen.

habs jetzt hier eingetragen

von meinem PC aus funktionierts

C:\Users\>nslookup sip.alice-voip.de
Server:  UnKnown
Address:  10.10.100.1

Nicht autorisierende Antwort:
Name:    sip.alice-voip.de
Addresses:  62.109.121.1
          62.109.121.2

Fritzbox meldet Anmeldung der Rufnummer nicht erfolgreich. Ursache: Gegenstelle antwortet nicht. Zeitüberschreitung

Zitat von @DivideByZero:

Wie meinen?

dass ich chatgpt gefragt hab wie ich das einrichten soll, aber das mit dem DNS overwrite in unbound ist ja offensichtlich falsch

Zitat von @Spirit-of-Eli:

Warum trägst du nicht einfach bei deinem VOIP Gerät/Geräten deine Alice als DNS ein.
Dann hast du das Problem umschifft es auf der Sense umbiegen zu müssen.

kann ich auch tun...
edit: die fritz meldet dns fehler

Zitat von @gruenhorn:
ChatGPT taugt echt gar nix bei Netzwerkfragen

Die Qualität der Antworten bei komplexen technischen Fragen entspricht der Qualität der Suchergebnisse von Google & Co.
1/3 veraltet
1/3 Gut
1/3 falsch

Da hat ChatGPT ja die meisten seiner Informationen her.

Einfach Inhalte kopieren hat häufig "lustige" Nebenwirkungen.

Stefan

ChatGPT taugt echt gar nix bei Netzwerkfragen

Taugt es überhaupt für etwas?? Die Ehefrau oder Freundin gibt in der Regel deutlich bessere Antworten.
Selber Schuld wer so einen haluzinierenden Blödsinn nutzt dem man nichts glauben kann!

Naja, teilweise schon. Zusammenfassungen von Information sind gut.
Und grundsätzlich Erklärungen von Fachbegriffen oder Zusammenhängen sind auch gut.

Aber ja, das Ding neigt dazu, sich einfach Mist auszudenken und kennzeichnet den nicht als solchen.

Aber auch das kann man umgehen, wenn man Quellen einfordert.

Zitat von @Spirit-of-Eli:

Warum trägst du nicht einfach bei deinem VOIP Gerät/Geräten deine Alice als DNS ein.
Dann hast du das Problem umschifft es auf der Sense umbiegen zu müssen.

Das klappt übrigens nicht, DNS Server werden verwendet, aber ne Verbindung gibts trotzdem nicht.

AdGuard sagt mir auch, dass alles brav umgeschrieben wird, wenn ich das eben dort hinterlege.
Aber laufen tut es nach wie vor nicht

Was kann ich denn jetzt systematisch da testen? Kann ich an irgendetwas festmachen, was noch fehlt, damit die Nummer wieder registriert wird?

Die Fritzbox ist ganz schön zickig geworden nach der ganzen Aktion, ich komm nicht mehr zuverlässig aufs GUI, muss sie immer neustarten und dann hängt sie irgendwann wieder. Die leidet wohl etwas unter der VoIP Suche, hm?

Hier mal vom PC aus mit Phoner getestet:

00:12:34,650: Start of application PhonerLite (C:\Windows\explorer.exe)
00:12:35,191: Loading profiles from configuration file: C:\Users\gh\AppData\Roaming\PhonerLite\sipper.ini
00:12:35,227: Loading profile "4923xxxxxxx@sip.alice-voip.de" from configuration file: C:\Users\gh\AppData\Roaming\PhonerLite\sipper.ini  
00:12:35,247: loading USBphone
00:12:35,303: OpenDevice (C:\Program Files\PhonerLite\sipper64.dll)
00:12:35,303: LoadCAPI(C:\Program Files\PhonerLite\sipper64.dll)
00:12:35,303: Installed
00:12:35,303: Installed: 
00:12:35,303: Get Manufacturer: 53 49 50 50 45 52 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00:12:35,303: Get Version: 02 00 00 00 00 00 00 00 03 00 00 00 29 00 00 00 
00:12:35,303: SIPPER: 2.0 (3.41)
00:12:35,303: Register: 160 bytes blocksize
00:12:35,303: Register: 00 0C 00 00 02 00 00 00 07 00 00 00 A0 00 00 00 
00:12:35,307: Register returns: 01 00 00 00 
00:12:35,307: Get Profile: 01 00 1E 00 19 00 00 00 03 00 00 00 03 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00:12:35,307: Listen Request: 1A 00 01 00 05 80 04 00 01 00 00 00 FF 17 00 00 12 00 01 00 00 00 00 00 00 00 
00:12:35,307: Listen Request
00:12:35,307: Facility Request: 12 00 01 00 80 80 06 00 01 00 00 00 03 00 03 00 00 00 
00:12:35,307: Facility Request (Get Supplementary Services)
00:12:35,323: CAPI thread created: 0x060C
00:12:35,478: Using SIP configuration file: C:\Users\gh\AppData\Roaming\PhonerLite\sipper.ini
-------------------------------------------
00:12:35,328: R: DNS lookup for 'GHPC'  
start resolving...
-------------------------------------------
00:12:35,344: R: DNS lookup for 'GHPC'  
10.10.100.21
-------------------------------------------
00:12:35,344: R: DNS lookup for 'sip.alice-voip.de'  
start resolving SRV (UDP)...
-------------------------------------------
00:12:35,350: R: DNS lookup for 'sip.alice-voip.de'  
62.109.121.1 (TTL=10)
-------------------------------------------
00:12:35,370: R: open UDP port (SIP): 5060

-------------------------------------------
00:12:35,375: R: open TCP port (TLS listen): 5061

-------------------------------------------
00:12:35,375: R: open TCP port (TCP listen): 5060

00:12:35,508: Listen Confirm: 0E 00 01 00 05 81 04 00 01 00 00 00 00 00 
00:12:35,508: Listen Confirm
-------------------------------------------
00:12:35,378: R: open UDP port (mDNS): 5353

00:12:35,527: Facility Confirm: 1A 00 01 00 80 81 06 00 01 00 00 00 00 00 03 00 09 00 00 06 00 00 3D 01 00 00 
00:12:35,527: Facility Confirm (Supplementary Services)
00:12:35,527: Facility Request: 16 00 01 00 80 80 07 00 01 00 00 00 03 00 07 01 00 04 3D 01 00 00 
00:12:35,527: Facility Request (Listen To Supplementary Services)
00:12:35,527:  Get Supported Services: success
-------------------------------------------
00:12:35,378: T: 62.109.121.1:5060 (UDP)
REGISTER sip:sip.alice-voip.de SIP/2.0
Via: SIP/2.0/UDP 10.10.100.21:5060;branch=z9hG4bK80735effcdf3ef119e33abf08d9017a6;rport
From: "PhonerLite" <sip:49230xxxxxx@sip.alice-voip.de>;tag=3061232935  
To: "PhonerLite" <sip:49230xxxxx@sip.alice-voip.de>  
Call-ID: 80735EFF-CDF3-EF11-9E31-ABF08D9017A6@10.10.100.21
CSeq: 1 REGISTER
Contact: <sip:49230xxxxx@10.10.100.21>;+sip.instance="<urn:uuid:00E7CBDA-03EB-EF11-A163-9A6F7B5FEA89>"  
Allow: INVITE, ACK, BYE, CANCEL, MESSAGE, NOTIFY, OPTIONS, REFER, UPDATE, PRACK
Max-Forwards: 70
Allow-Events: org.3gpp.nwinitdereg
User-Agent: PhonerLite/3.28
Supported: replaces, from-change
Expires: 600
Content-Length: 0


00:12:35,530: Facility Confirm: 16 00 01 00 80 81 07 00 01 00 00 00 00 00 03 00 05 01 00 02 00 00 
00:12:35,530: Facility Confirm (Supplementary Services)
00:12:35,530:  Listen: success
-------------------------------------------
00:12:35,879: T: 62.109.121.1:5060 (UDP)
REGISTER sip:sip.alice-voip.de SIP/2.0
Via: SIP/2.0/UDP 10.10.100.21:5060;branch=z9hG4bK80735effcdf3ef119e33abf08d9017a6;rport
From: "PhonerLite" <sip:49230xxxx4@sip.alice-voip.de>;tag=3061232935  
To: "PhonerLite" <sip:49230xxxxx@sip.alice-voip.de>  
Call-ID: 80735EFF-CDF3-EF11-9E31-ABF08D9017A6@10.10.100.21
CSeq: 1 REGISTER
Contact: <sip:49230xxxx@10.10.100.21>;+sip.instance="<urn:uuid:00E7CBDA-03EB-EF11-A163-9A6F7B5FEA89>"  
Allow: INVITE, ACK, BYE, CANCEL, MESSAGE, NOTIFY, OPTIONS, REFER, UPDATE, PRACK
Max-Forwards: 70
Allow-Events: org.3gpp.nwinitdereg
User-Agent: PhonerLite/3.28
Supported: replaces, from-change
Expires: 600
Content-Length: 0


-------------------------------------------
00:12:36,881: T: 62.109.121.1:5060 (UDP)
REGISTER sip:sip.alice-voip.de SIP/2.0
Via: SIP/2.0/UDP 10.10.100.21:5060;branch=z9hG4bK80735effcdf3ef119e33abf08d9017a6;rport
From: "PhonerLite" <sip:49230xxxx@sip.alice-voip.de>;tag=3061232935  
To: "PhonerLite" <sip:49230xxxx@sip.alice-voip.de>  
Call-ID: 80735EFF-CDF3-EF11-9E31-ABF08D9017A6@10.10.100.21
CSeq: 1 REGISTER
Contact: <sip:49230xxxxx@10.10.100.21>;+sip.instance="<urn:uuid:00E7CBDA-03EB-EF11-A163-9A6F7B5FEA89>"  
Allow: INVITE, ACK, BYE, CANCEL, MESSAGE, NOTIFY, OPTIONS, REFER, UPDATE, PRACK
Max-Forwards: 70
Allow-Events: org.3gpp.nwinitdereg
User-Agent: PhonerLite/3.28
Supported: replaces, from-change
Expires: 600
Content-Length: 0