24.07.2023

2563

Domäne hinzufügen: 0x0000232A RCODE SERVER FAILURE DCDIAG Keine LDAP-Konnektivität Wireguard

Hallo Experten,

ich schaffe es nicht einen Win11 PC über eine bestehende Wireguard-Verbindung an einem Windows Server 2019 - Domänen-Controller anzumelden mit dem Domänenname "sr.intra".

Der Win11-PC hat eine lokale IP von 10.14.0.49, und der Wireguard-Adapter 192.168.139.242.
Der Server 192.168.139.5. Die Wireguard-Gegenstelle ist eine Fritzbox 6660 mit der lokalen IP 192.168.139.1.

Die Wireguard-Verbindung und der Ping auf den Server sowie SMB-Netzlaufwerke etc. funktionieren tadellos.

Wireguard-Einstellung:

Wireguard läuft:

ipconfig /all auf dem Win11-PC:

C:\Users\Test1>ipconfig /all

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : DRL-Test1
   Primäres DNS-Suffix . . . . . . . :
   Knotentyp . . . . . . . . . . . . : Hybrid
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein
   DNS-Suffixsuchliste . . . . . . . : sr.intra
                                       fritz.box

Unbekannter Adapter dr_wg_20230709:

   Verbindungsspezifisches DNS-Suffix: sr.intra
   Beschreibung. . . . . . . . . . . : WireGuard Tunnel
   Physische Adresse . . . . . . . . :
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 192.168.139.242(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : 0.0.0.0
   DNS-Server  . . . . . . . . . . . : 192.168.139.5
   NetBIOS über TCP/IP . . . . . . . : Aktiviert
   Suchliste für verbindungsspezifische DNS-Suffixe:
                                       sr.intra
                                       fritz.box

Drahtlos-LAN-Adapter WLAN 2:

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : TP-Link Wireless Nano USB Adapter
   Physische Adresse . . . . . . . . : D0-37-45-EB-28-B8
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 10.14.0.49(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.0.0
   Lease erhalten. . . . . . . . . . : Montag, 24. Juli 2023 07:02:11
   Lease läuft ab. . . . . . . . . . : Dienstag, 25. Juli 2023 07:02:14
   Standardgateway . . . . . . . . . : 10.14.0.1
   DHCP-Server . . . . . . . . . . . : 10.10.2.6
   DNS-Server  . . . . . . . . . . . : 208.67.222.222
                                       208.67.220.220
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

C:\Users\Test1>

Ping und nslookup sehen gut aus:

C:\Users\Test1>ping server

Ping wird ausgeführt für server.sr.intra [192.168.139.5] mit 32 Bytes Daten:
Antwort von 192.168.139.5: Bytes=32 Zeit=31ms TTL=127
Antwort von 192.168.139.5: Bytes=32 Zeit=28ms TTL=127
Antwort von 192.168.139.5: Bytes=32 Zeit=33ms TTL=127
Antwort von 192.168.139.5: Bytes=32 Zeit=23ms TTL=127

Ping-Statistik für 192.168.139.5:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 23ms, Maximum = 33ms, Mittelwert = 28ms
	
	
C:\Users\Test1>nslookup sr.intra
Server:  server.sr.intra
Address:  192.168.139.5

Name:    sr.intra
Addresses:  2a02:8070:99b0:3300:6809:d0e1:9843:1b4
          192.168.139.5
		  
C:\Users\Test1>nslookup server.sr.intra.
Server:  server.sr.intra
Address:  192.168.139.5

Name:    server.sr.intra
Address:  192.168.139.5

C:\Users\Test1>nslookup server
Server:  server.sr.intra
Address:  192.168.139.5

*** server wurde von server.sr.intra nicht gefunden: Server failed.

Wenn ich nun versuche den Win11-PC anzumelden, klappt es aber nicht:

Danach kommt der Fehler:

Fehlertext:

Hinweis: Diese Informationen sind für einen Netzwerkadministrator bestimmt. Wenden Sie sich an den Netzwerkadministrator, wenn Sie kein Netzwerkadministrator sind, und leiten Sie die Informationen in der Datei C:\Windows\debug\dcdiag.txt weiter.

Der folgende Fehler ist beim Abfragen von DNS über den Ressourceneintrag der Dienstidentifizierung (SRV) aufgetreten, der zur Suche eines Active Directory-Domänencontrollers (AD DC) für die Domäne "sr.intra" verwendet wird:  

Fehler: "DNS-Serverfehler."  
(Fehlercode 0x0000232A RCODE_SERVER_FAILURE)

Es handelt sich um die Abfrage des Dienstidentifizierungseintrags (SRV) für _ldap._tcp.dc._msdcs.sr.intra.

Die häufigsten Ursachen dieses Fehlers sind:

- Die von dem Computer verwendeten DNS-Server enthalten falsche Stammhinweise. Der Computer wurde zur Verwendung der folgenden IP-Adressen konfiguriert:

208.67.220.220
208.67.222.222
192.168.139.5

- Mindestens eine der folgenden Zonen enthalten eine falsche Delegierung:

sr.intra
intra
. (die Stammzone)

Auf dem Server selbst scheint es ein Problem mit DCDIAG zu geben:

C:\Users\remote>dcdiag /test:dns

Verzeichnisserverdiagnose

Anfangssetup wird ausgeführt:
   Der Homeserver wird gesucht...
   Homeserver = server
   * Identifizierte AD-Gesamtstruktur.
   Sammeln der Ausgangsinformationen abgeschlossen.

Erforderliche Anfangstests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\SERVER
      Starting test: Connectivity
         Bei der DNS-Hostsuche ist ein Fehler aufgetreten, der in der Regel temporärer Natur ist. Wiederholen Sie den
         Vorgang zu einem späteren Zeitpunkt.
         Fehler beim Überprüfen der LDAP- und RPC-Konnektivität. Überprüfen Sie die Firewalleinstellungen.
         ......................... Der Test Connectivity für SERVER ist fehlgeschlagen.

Primärtests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\SERVER

      Starting test: DNS

         DNS-Tests werden ordnungsgemäß ausgeführt. Warten Sie einige Minuten...
         ......................... Der Test DNS für SERVER ist fehlgeschlagen.

   Partitionstests werden ausgeführt auf: ForestDnsZones

   Partitionstests werden ausgeführt auf: DomainDnsZones

   Partitionstests werden ausgeführt auf: Schema

   Partitionstests werden ausgeführt auf: Configuration

   Partitionstests werden ausgeführt auf: sr

   Unternehmenstests werden ausgeführt auf: sr.intra
      Starting test: DNS
         Testergebnisse für Domänencontroller:

            Domänencontroller: server.sr.intra
            Domäne: sr.intra


               TEST: Basic (Basc)
                  Fehler: Keine LDAP-Konnektivität
                  Für diesen Domänencontroller wurden keine Hosteinträge (A oder AAAA) gefunden.
                  Warning: no DNS RPC connectivity (error or non Microsoft DNS server is running)

         Zusammenfassung der DNS-Testergebnisse:

                                            Auth. Bas. Weiterl. Entf.  Dyn.  RReg. Erw.
            _________________________________________________________________
            Domäne: sr.intra
               server                       PASS FAIL n/a  n/a  n/a  n/a  n/a

         ......................... Der Test DNS für sr.intra ist fehlgeschlagen.

In _msdcs ist eine feste IP für den Server hinterlegt:

Auch sonst müsste es passen:

ipconfig /all auf dem Server:

C:\Users\remote>ipconfig /all

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : server
   Primäres DNS-Suffix . . . . . . . : sr.intra
   Knotentyp . . . . . . . . . . . . : Hybrid
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein
   DNS-Suffixsuchliste . . . . . . . : sr.intra

Ethernet-Adapter Ethernet0:

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection
   Physische Adresse . . . . . . . . : 00-0C-29-D4-60-4D
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 192.168.139.5(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : 192.168.139.1
   DNS-Server  . . . . . . . . . . . : 192.168.139.5
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

C:\Users\remote>

Bin ich auf der richtigen Spur mit dem DCDIAG und "Keine LDAP-Konnektivität"?
Im lokalen Netzwerk läuft die Domänenanmeldung, auch wenn ich es gerade mit diesem Win11-PC nicht testen kann (alle anderen PCs funktionieren dort). Muss speziell für Wireguard oder VPN die DNS-Einstellung korrekt sein, was lokal weniger wichtig ist?
Oder könnte noch etwas am Wireguard, den unterschiedlichen Subnetzen oder dem Win11-PC sein?

Es wäre sehr nett, wenn mir jemand helfen könnte. Gerne liefere ich weitere Infos und teste etwas, wenn Jemand eine Idee hat.

Danke schonmal!

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

Content-ID: 7936978383

Url: https://administrator.de/contentid/7936978383

Ausgedruckt am: 19.12.2024 um 12:12 Uhr

18 Kommentare

Neuester Kommentar

Moin,

wie eigentlich fast immer ist das DNS falsch eingestellt. Woher bekommt der PC seine IP? Bei dem DHCP-Server musst Du nachschauen. Das IPCONFIG liefert für Deinen Win11-PC

DNS-Server  . . . . . . . . . . . : 208.67.222.222
                                       208.67.220.220

Und im Fehlertext taucht zwar der wahrscheinlich richtige auf. Davor stehen aber noch die beiden öffentlichen.

- Die von dem Computer verwendeten DNS-Server enthalten falsche Stammhinweise. Der Computer wurde zur Verwendung der folgenden IP-Adressen konfiguriert:

67.220.220
67.222.222
168.139.5

Die wird Windows erstmal fragen und die Antwort "Domain not found" erhalten.

Das sind mit ziemlicher Sicherheit nicht Deine DNS-Server. Außerdem würde ich das Suffix fritz.box noch entfernen. Das stört auch nur. Gib dem Win11 als einzige DNS-Server die der Domain und dann klappt das auch.

hth

Erik

P.S.: Endlich mal einer, der gleich alle Infos liefert, die notwendig sind.

Moin Erik,

hth leider nicht

Die DNS-Server
208.67.220.220
208.67.222.222
stehen im TP-Link WLAN-Stick und wurden von dem lokalen DHCP hier am Win11-PC vergeben. Wie soll ich die ändern? S. oben bei ipconfig /all.

Erst der Wireguard-Tunnel setzt den korrekten DNS 192.168.139.5, aber inwiefern soll ich das beim TP-Link ändern? Der bekommt es ja automatisch vom lokalen DHCP, den ich leider nicht verwalten kann und es auch nichts bringen würde, weil dann würde hier am Win11-PC gar kein Internet und kein Wireguard mehr gehen?

fritz.box habe ich aus der conf-DNS-Zeile entfernt, bringt aber leider nichts.

Weitere Ideen? Wie könnte ich zumindest die DNS-Reihenfolge beim Anmelden der Domäne ändern (192.168.139.5 zuerst)?

-Daniel

P.S.: Danke für's Lob

Moin,

ok. Verstehe.

Erstmal: Du guckst im DNS-Server an der falschen Stelle. Auf der Ebenen sr.intra muss ein A-Eintrag für "server" vorhanden sein mit der korrekten IP. Alle darunter liegenden Ebenen beziehen sich auf diesen.

Dann: Die Reihenfolge der verwendeten DNS-Server kannst Du in den Einstellungen für den Adapter ändern. Ich habe gerade kein Win11 zur Verfügung. Bei Win10 findet man das unter Einstellungen->Netzwerk->Ethernet->Adapteroptionen ändern, rechte Maustaste auf den Adapter->Eigenschaften->TCP/IPv4->Erweitert->DNS

Liebe Grüße

Erik

Hi,

den A-Eintrag für "server" gibt es:

Wie soll ich die Reihenfolge ändern, wenn es sich doch um 2 Adapter handelt?
Wie bringt man das Anmelden der Domäne dazu, es zuerst über den Wireguard-Adapter zu versuchen?
Oder wäre das nicht egal, weil er sowieso alle DNS ausprobiert und damit zuletzt auch den 192.168.139.5 - DNS versucht?

Könnte es vielleicht auch mit der fehlenden LDAP-Konnektivität bei der DCDIAG-Ausgabe am Server zusammenhängen (s. meinen ersten Beitrag)?

Moin,

lass das dcdiag bitte nochmal laufen (auf dem DC).

Liebe Grüße

Erik

wie eigentlich fast immer ist das DNS falsch eingestellt.

Leider und auch wie immer, ist wieder Gateway Redirect und Split Tunneling fälschlicherweise zugleich im VPN Client konfiguriert worden. Der übliche WG Anfängerfehler....

Merkzettel: VPN Installation mit Wireguard

Zitat von @aqui:

wie eigentlich fast immer ist das DNS falsch eingestellt.

Leider und auch wie immer, ist wieder Gateway Redirect und Split Tunneling fälschlicherweise zugleich im VPN Client konfiguriert worden. Der übliche WG Anfängerfehler....

Merkzettel: VPN Installation mit Wireguard

Die conf-Datei habe ich aus der Fritzbox runtergeladen, sind damit deren Programmierer alle Anfänger?

Wäre es so richtig, wenn die eigene lokale IP am TP-Link Stick 10.14.0.49 ist?

Leider läuft das nicht mehr richtig, DNS-Namen werden nicht mehr aufgelöst und ping geht nur noch auf die 192.168.139.1, sonst gar nicht. Split wäre mir am liebsten, da man so noch ordentlich nebenbei im Internet surfen kann und bei Redirect wäre alles ziemlich lahm? Wie wäre es richtig für Split oder geht eine Domänenanmeldung nur mit Redirect?

Zitat von @erikro:

Moin,

lass das dcdiag bitte nochmal laufen (auf dem DC).

Liebe Grüße

Erik

Warum nochmal, ich hab doch gar nichts geändert?

C:\Users\remote>dcdiag /test:dns

Verzeichnisserverdiagnose

Anfangssetup wird ausgeführt:
   Der Homeserver wird gesucht...
   Homeserver = server
   * Identifizierte AD-Gesamtstruktur.
   Sammeln der Ausgangsinformationen abgeschlossen.

Erforderliche Anfangstests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\SERVER
      Starting test: Connectivity
         Bei der DNS-Hostsuche ist ein Fehler aufgetreten, der in der Regel temporärer Natur ist. Wiederholen Sie den
         Vorgang zu einem späteren Zeitpunkt.
         Fehler beim Überprüfen der LDAP- und RPC-Konnektivität. Überprüfen Sie die Firewalleinstellungen.
         ......................... Der Test Connectivity für SERVER ist fehlgeschlagen.

Primärtests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\SERVER

      Starting test: DNS

         DNS-Tests werden ordnungsgemäß ausgeführt. Warten Sie einige Minuten...
         ......................... Der Test DNS für SERVER ist fehlgeschlagen.

   Partitionstests werden ausgeführt auf: ForestDnsZones

   Partitionstests werden ausgeführt auf: DomainDnsZones

   Partitionstests werden ausgeführt auf: Schema

   Partitionstests werden ausgeführt auf: Configuration

   Partitionstests werden ausgeführt auf: sr

   Unternehmenstests werden ausgeführt auf: sr.intra
      Starting test: DNS
         Testergebnisse für Domänencontroller:

            Domänencontroller: server.sr.intra
            Domäne: sr.intra


               TEST: Basic (Basc)
                  Fehler: Keine LDAP-Konnektivität
                  Für diesen Domänencontroller wurden keine Hosteinträge (A oder AAAA) gefunden.
                  Warning: no DNS RPC connectivity (error or non Microsoft DNS server is running)

         Zusammenfassung der DNS-Testergebnisse:

                                            Auth. Bas. Weiterl. Entf.  Dyn.  RReg. Erw.
            _________________________________________________________________
            Domäne: sr.intra
               server                       PASS FAIL n/a  n/a  n/a  n/a  n/a

         ......................... Der Test DNS für sr.intra ist fehlgeschlagen.

Warum kommt die Fehlermeldung mit RCODE_SERVER_FAILURE beim Domänenanmelden, wenn er doch den DNS 192.168.139.5 auflistet?
Und wie bekomme ich die fehlende LDAP-Konnektivität gefixt?

Zitat von @aqui:

wie eigentlich fast immer ist das DNS falsch eingestellt.

Leider und auch wie immer, ist wieder Gateway Redirect und Split Tunneling fälschlicherweise zugleich im VPN Client konfiguriert worden. Der übliche WG Anfängerfehler....

Merkzettel: VPN Installation mit Wireguard

Zur Info, mit der ursprünglichen Einstellung:

[Interface]
PrivateKey = ...
Address = 192.168.139.242/24
DNS = 192.168.139.5, sr.intra

[Peer]
PublicKey = ...
PresharedKey = ...
AllowedIPs = 192.168.139.0/24, 0.0.0.0/0
Endpoint = myfritz.net:...
PersistentKeepalive = 25

C:\Users\Test1>ping server

Ping wird ausgeführt für server.sr.intra [192.168.139.5] mit 32 Bytes Daten:
Antwort von 192.168.139.5: Bytes=32 Zeit=34ms TTL=127
Antwort von 192.168.139.5: Bytes=32 Zeit=40ms TTL=127
Antwort von 192.168.139.5: Bytes=32 Zeit=25ms TTL=127
Antwort von 192.168.139.5: Bytes=32 Zeit=26ms TTL=127

Ping-Statistik für 192.168.139.5:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 25ms, Maximum = 40ms, Mittelwert = 31ms

C:\Users\Test1>nslookup server
Server:  server.sr.intra
Address:  192.168.139.5

*** server wurde von server.sr.intra nicht gefunden: Server failed.

C:\Users\Test1>nslookup sr.intra
Server:  server.sr.intra
Address:  192.168.139.5

Name:    sr.intra
Addresses:  2a02:8070:99b0:3300:6809:d0e1:9843:1b4
          192.168.139.5


C:\Users\Test1>

Und mit Deinem Vorschlag:

[Interface]
PrivateKey = ...
Address = 192.168.139.242/24
DNS = 192.168.139.5, sr.intra

[Peer]
PublicKey = ...
PresharedKey = ...
AllowedIPs = 192.168.139.0/32, 10.14.0.0/24
Endpoint = .myfritz.net:...
PersistentKeepalive = 25

C:\Users\Test1>ping server
Ping-Anforderung konnte Host "server" nicht finden. Überprüfen Sie den Namen, und versuchen Sie es erneut.  

C:\Users\Test1>nslookup server
Server:  UnKnown
Address:  192.168.139.5

*** server wurde von UnKnown nicht gefunden: No response from server.

C:\Users\Test1>nslookup sr.intra
Server:  UnKnown
Address:  192.168.139.5

*** sr.intra wurde von UnKnown nicht gefunden: No response from server.

C:\Users\Test1>

Warum sollte das besser sein?

Du hast im Setup oben auch wieder einen groben Fehler gemacht: "192.168.139.0/32" Ist natürlich ziemlicher Blödsinn, denn eine Hostsubnetzmaske mit 32 Bit kann ja niemals ein ganzes Netzwerk beschreiben und "0" als Hostadresse gibt es nicht. Das der Unsinn dann natürlich in die Hose geht weisst du sicher als Administrator auch selber.
Im Tutorial ist genau beschrieben wie die Hostadresseinträge auszusehen haben! Lesen hilft wirklich.

Wenn du Redirect machen willst ist das per se ja kein Fehler. Es reicht dann aber der Eintrag AllowedIPs = 0.0.0.0/0.
Der besagt ja dann das ALLES in den Tunnel geroutet werden soll. Da muss man dann nicht auch noch weitere separate Netze dazu eintragen, denn mit "ALLES" ist auch wirklich alles gemeint.

Bei einem Redirect muss man eben nur beachten das der Tunnel auch mit sämtlichem lokalen Traffic belastet wird. Wenn man nur remote relevanten Traffic dort haben will ist das ein deutlicher Performance Nachteil. Hängt aber immer vom persönlichen VPN Konzept ab was man damit erreichen will.

Bitte mach doch kein Drama daraus, natürlich muss die .1 dastehen und nicht .0. Kann mich ja mal vergucken?
Das ist doch Dein Beispiel?

Mach ich nun irgendwas falsch, wenn es bei mir so aussieht?

"nslookup sr.intra" klappt schon nicht und die pings etc. auch nicht.

Das Konzept ist natürlich die beste Performance, daher sollte es Split sein. Oder klappt das dann etwa nicht?

Mittlerweile habe ich eine Lösung gefunden. Der Befehl auf dem Client (auf die Idee muss man natürlich erstmal kommen...)

nslookup -type=srv _ldap._tcp.dc._msdcs.sr.intra

hat nicht funktioniert. Es wurde vermutet, dass die Zone mit Prefix "_msdcs" im DNS-Manager fehlt, was auch so war, denn es gab nur die Zone "sr.intra".
Nach Hinzufügen einer weiteren Forward-Lookupzone "_msdcs.sr.intra"

hat das Beitreten in die Domäne nach Eingabe von Benutzer und Passwort auf Anhieb funktioniert:

@aqui: Hat offensichtlich gar nichts mit Wireguard zu tun? Welche Einstellung für Split würdest Du denn empfehlen?

Steht eigentlich alles im Tutorial! 😉
Merkzettel: VPN Installation mit Wireguard

Für Split Tunneling reicht es wenn man beim WG Client unter den Allowed IPs nur den Server mit einer Hostmaske und das remote Netzwerk einträgt.
Beim Server für die Client Peer dann vice versa. Client mit Hostmaske und sofern ein remotes Netz geroutet werden soll das remote Client LAN. Soll lediglich nur auf dem Server bzw. seinem lokalen netz gearbeitet werden wird nur die interne Client IP eingetragen.
Z.B so bei Server intern=.254/24 und lokalem LAN 172.16.1.0/24 und Client intern=.1/24 u. optional lokalem LAN 192.168.1.0/24:

Server (Peer für Client 1):

AllowedIPs: 100.64.64.1/32, 192.168.1.0/24

Client (Peer für Server):

AllowedIPs: 100.64.64.254/32, 172.16.1.0/24

Eigentlich ne ganz einfache Logik!

@aqui Wie kann ich denn auf der Fritzbox die Server-Konfiguration frei ändern? Und bist Du der Meinung, dass die heruntergeladene Client-conf der Fritzbox tatsächlich ungültig und falsch ist mit dem AllowedIPs = 0.0.0.0/0? Das würde mich wundern, da bestimmt Tausende in Deutschland die Fritzbox als Wireguard-Server nutzen.
Und gibt es zu dem Thema "bitte keine Vermischung von Redirect und Split-Tunneling" eine offizielle Doku, oder zumindest eine offizielle Doku wie man AllowedIPs korrekt setzt?
In www.wireguard.com/papers/wireguard.pdf finde ich speziell dazu nichts.

Wie kann ich denn auf der Fritzbox die Server-Konfiguration frei ändern?

Das ist unmöglich, das lässt die AVM Konfiguration im Gegensatz zur "normalen" WG Konfig nicht zu. Auf der Serverseite hast du bei AVM keine Chance.
AVM lässt lediglich nur eine angepasste Client Konfig zum Importieren zu wenn die FB als VPN Initiator arbeitet.

ungültig und falsch ist mit dem AllowedIPs = 0.0.0.0/0?

Nein, falsch ist das per se nicht. die 0.0.0.0/0 bewirkt nur das ALLER Traffic des Clients durch den Tunnel geht, was sehr ineffizient ist wenn man das nicht möchte. Logisch, denn so geht nicht nur der VPN relevante Traffic in den Tunnel, sondern z.B. auch wenn du lokal z.B. nur rumsurfst auf YouTube oder dir Emails abholst. Alles wird dann durch den VPN Tunnel gezwungen. Gut, wenn man damit leben kann ist das OK, ansonsten sollte man seine Client Konfig in den Allowed IPs etwas anpassen.

eine offizielle Doku, oder zumindest eine offizielle Doku wie man AllowedIPs korrekt setzt?

Jepp, natürlich! Das findest du alles auf der Wireguard Hompepage im Kapitel Cryptokey routing! Redirect und Split Tunneling sind aber allgemein bekannte VPN Binsenweisheiten weil sie für alle VPNs gelten, ausnahmslos.
Sagt ja einem schon der gesunde IT Verstand. Bei einem Redirect wo ja eh schon alles in den Tunnel geroutet wird wäre es ja völliger Quatsch dann noch einmal on Top Netzwerk spezifisch einzelnen Traffic in den Tunnel zu routen. Ebenso vice versa. Nachdenken hilft...

Zitat von @aqui:

wie eigentlich fast immer ist das DNS falsch eingestellt.

Leider und auch wie immer, ist wieder Gateway Redirect und Split Tunneling fälschlicherweise zugleich im VPN Client konfiguriert worden. Der übliche WG Anfängerfehler....

Merkzettel: VPN Installation mit Wireguard

Habe genau diese Frage, ob das Mischen nicht falsch ist mit Hinweis auf Deinen Artikel unter
[content:660620#toc-11]
an AVM gestellt und bekam folgende Antwort:

Wenn die Mischung nicht funktionieren würde bzw. wenn dies ein Fehler wäre wie in administrator.de beschrieben, dann wäre unsere Konfiguration anders und es wäre in unserer Dokumentation beschrieben, dass Sie dies nicht so einstellen dürfen. Im Umkehrschluss würde dies ja bedeuten, dass alle in der FRITZ!Box erzeugten Konfigurationen ohne eigene Änderung der Konfig nicht funktionieren würden. Dies kann ich allerdings ausschließen.

Wir empfehlen dies nicht, da Sie hier aktiv die Konfiguration ändern müssen, was nicht über unseren Support abgedeckt ist und wir daher hierzu keinerlei Hilfe anbieten können. Wer dies aber gern versuchen möchte, darf dies natürlich jederzeit machen.

Kann man wirklich argumentieren... es ist richtig und stimmt sonst hätten wir es schon längst in unseren Dokus beschrieben? Und jegliche Änderung an der Wireguard-Config auf eigene Gefahr (Angst schüren)?

Und auf die Frage, ob Split Tunneling nicht besser für die Performance und die Auslastung der Leitung / des Uploads des Wireguard-Servers wäre:

Jain. Ihre Argumente sind natürlich gut und treffen sicher auch auf einige Nutzer zu, den meisten unserer Kunden möchten allerdings entweder ganz über die FRITZ!Box senden oder deaktivieren VPN, wenn Sie lediglich über z.B. Mobilfunk senden möchten.

Nur weil die denken es wollen alle so ist es am besten?

Kann man AVM vielleicht mit einem offiziellen konkreten Hinweis von wireguard.com (wenn ja welchen?) aus der Reserve holen? Oder habe sie etwa recht, weil es funktioniert?

Etwas Lachen muss man auch bei dem Statement „...dann wäre unsere Konfig anders...“! Die ganze IT Welt weiss ja mittlerweile das die AVM WG Konfig „anders“ ist und nicht der entspricht wie Wireguard sie vorgibt. Heise hat das ja auch mehrfach in seinen c’t Artikeln zu der Thematik berichtet. Aber nundenn.... AVM halt. Es wäre aber auch vermessen bei einem Consumer Plasterouter eine andere Antwort zu erwarten. Hoch anrechnen muss man dem AVM Support das er überhaupt geantwortet hat. Im Consumer Billigbereich ist sowas bekanntlich nicht üblich.

Meinst Du den Artikel aus c't 23/2022?
www.heise.de/select/ct/2022/23/2225809105962410605
Ich lese einzig, dass die Clients eine IP aus einem Subnetz anstatt dem bestehenden Netz der Fritzbox erhalten sollten, besonders für die LAN-LAN-Kopplung.
Wo steht, dass die conf-Datei anders und falsch ist und nicht dem entspricht was Wireguard vorgibt? Würde mich persönlich interessieren....
200 Euro für den Router finde ich jetzt nicht spottbillig und auch im Consumer-Bereich darf man sich verbessern und technische Antworten liefern, ist ja nicht verboten und macht einen guten Eindruck.

Lies dir die Grundlagen des Cryptokey Routings durch dann weisst du warum.
https://www.wireguard.com/#cryptokey-routing
Speziell äußert sich das in einem Responder Szenario wenn die FB als WG Server arbeitet. Dort ist nur ein Bruchteil der Optionen möglich die Wireguard vorsieht. Das z.B. ein Responder auch gleichzeitig Client sein kann ist für klassische Wireguard Setups kein Problem, für die AVM Implementation durch die spezielle Implementierung technisch unmöglich. Die obige Diskussion um Redirect bzw. Split Tunneling spricht für sich.

gelöst Frage Windows Userverwaltung Windows Netzwerk Windows Server VPN

Mehr von riegeler

Email Fehler: SSL verify error: certificate name mismatch: DN CN Hriegeler - 24 Kommentare

Dovecot vmail Ordner eines IMAP-Server in Outlook oder Thunderbird importierenriegeler - 8 Kommentare

Outlook Termin Teams Meeting ID hinzufügen oder ändernriegeler - 3 Kommentare

Woher kommen diese LLDP Frames?riegeler - 3 Kommentare

Heiß diskutiert