Hallo,

wir haben zwei Warp 3 Pro Wallboxen. Bei einer funktioniert der Fernzugriff ohne Probleme, aber bei der zweiten hat er auf gehört zu funktionieren.

Die beiden Wallboxen sind im gleichen Netzwerk, aber jeweils in ihrem eigenen Stromkreis.
Beide haben die gleiche Verfsion 2.12.1+6a4f9137

Die Logeinträge zeigen nur diese Meldung:
2026-07-15 04:55:05,650 | remote_access | Connecting to Management WireGuard peer my.warp-charger.com:51820
2026-07-15 04:56:06,261 | remote_access | Management connection timed out
2026-07-15 04:56:09,552 | remote_access | Connecting to Management WireGuard peer my.warp-charger.com:51820

Die my.warp-charger.com zeigt auch Statusänderungen der Wallbox an, also es kommen Infos zur Webseite, aber es kommt keine Verbindung zu stande.
Wir haben zwei Accounts, bei meinem Account habe ich mal die betroffene Wallnbox auch hinzugefügt, aber auch dort funktioniert es nicht,

Vielen Dank für eure Unterstützung.

Markus

warp3-2cHk-Debug-Report-2026-07-15T05-00-46-395.txt

Hallo Markus, guck mal bitte nach, ob das Problem immer noch besteht.

Hallo,

ja leider besteht das Problem immer noch. ICh habe die Software auch schon neugestartet, ohne Erfolg.
Ein komplettes Ausschalten sollte ja den gleichen Effekt haben, wie ein Neustart über die Webseite, oder?

Gruß Markus

Okay, schade. Es gab schonmal einen ähnlichen Fehler, der durch Neustart unserer Infrastruktur gelöst werden konnte.

Laut den Logs ist das Problem, dass entweder der Server die WireGuard der Box Pakete nicht sieht oder die Pakete vom Server nicht zurück kommen. Kannst du von der "heilen" Box auch einmal einen Debug-Report ziehen und mir schicken?

Seit wann bestehen die Probleme und gab es kurz vorher eine Veränderung an z.B. deinem Router?

Eigentlich gab es keine Änderungen am Router (Unifi UDM Pro, komplettes Unifi Netzwerk) welche das Problem erzeugen sollte.
ich habe die betoffene Wallbox mal komplett ausgeschaltet, aber selbst nach dem neustart kam keine Verbindung zu stande.
Währen des Test hatte ich auch die Remote Verbindung bei der anderen Wallbox deaktiviert, aber trotzdem kein Erfolg.
Die andere Wallbox verbindet sich beim einschalten der Remote Verbindung direkt wieder mit dem Server.
Es gibt eigentlich auch nur wenige Unterschiede der Wallboxen. Meine (die funktionierende) Wallbox wird über eine gesponserte EVCC Instantz gesteuert und ist per MQTT mit Home Assistant verbunden. Die andere wird über eine nicht gesponsorte EVCC Instanz gesteuert. Alles andere ist gleich.

Meine Schwetster nutzt die Wallbox für ihren Firmenwagen und nutzte den E-Mail Versand des Ladetrackers, welcher auch nicht funktioniert, ich gehe davon aus, dass hier auch die Remoteverbindung genutzt wird.

Danke und Gruß

Markus

warp3-2cCw-Debug-report-2026-07-18T03-55-13-583.txt

Zwei Wireguard-Clients zum selben Server aus demselben Netzwerk ... das ja sicher (wie üblich) per NAT mit dem Internet verbunden ist. Wireguard verwendet UDP, da besteht durch das NAT ein Konfliktpotenzial. Der NAT-Dienst auf dem Router/Firewall muss beim ausgehenden NAT die UDP-Pakete der beiden Warp von verschiedenen Ports versenden, damit Antwortpakete auch jeweils an diese verschiedenen Ports gehen und dann wiederum durch den NAT-Dienst an die richtige Warp intern weitergeleitet werden. Das kann funktionieren, muss aber nicht immer. Insbesondere gibt es im NAT-Dienst timeouts für die Einträge in dieser seiner Zuordungstabelle. Vielleicht geht da etwas schief.

Habe heute Serverseitig versucht genaueres rauszufinden, folgendes hab ich rausgefunden: zwei Geräte erzeugen Requests auf dem Server, die timing-mäßig zu deinem Fehler passen würden. Wenn ich Traffic für die beiden IPs mitschneide kriege ich für die eine ein Gerät, bei dem die WireGuard-Verbindung klappt und bei der anderen ein Gerät, bei welchem der Handshake Serverseitig klappt, aber danach sehe ich keine Keep-Alive-Pakete (sprich die Antwort vom Server kommt nicht durch)

Ich vermute, dass du hinter der Ersten steckst, da es bei dir ja ein Gerät gibt, welches funktioniert. Das würde wiederum bedeuten, dass die Ausgehenden Pakete irgendwo verloren gehen. Wenn du mir deinen Internet-Anbieter steckst könnten wir das ganze verifizieren (gerne auch per PN).

Du hast bei einer UDM pro doch bestimmt die Möglichkeit Pakete mitzuschneiden, oder? Könntest du mir einen Mitschnitt des UDP-Verkehrs von beiden Boxen mit my.warp-charger.com über 10 Minuten zukommen lassen? Am besten wäre es wenn du auch mitschneiden könntest was aus sicht deines Netzwerkes hinter dem NAT passiert.

Hattet ihr mal versucht, die funktionierende WARP auszuschalten und zu schauen, ob sich die bislang nicht funktionierende dann verbinden kann (ggf. nach einem Neustart)?

Hi,
wir haben das Problem gefunden. Es lag an einem Switch im Netzwerk, welcher scheinbar die Antwort vom Server geblockt hat.
Dies habe ich festgestellt, als der Switch unplanmäßig neugestartet wurde und danach wurde direkt die Verbindung zum Remote Server aufgebaut.
Was komisch war, dass dieser Switch nicht der Switch ist in welchem die Wallboxen direkt angeschlossen sind, sondern ein Swtich vor dem Switch.

Daher kann dieses Problem als gelöst geschlossen werden.

Danke für die großartige Unterstützung.

Gruß Markus

On 7/18/2026 at 4:15 AM, Markus S said:

Meine Schwetster nutzt die Wallbox für ihren Firmenwagen und nutzte den E-Mail Versand des Ladetrackers, welcher auch nicht funktioniert, ich gehe davon aus, dass hier auch die Remoteverbindung genutzt wird.

Korrekt. Ist die Mail jetzt, da die Remoteverbindung wieder funktioniert, rausgegangen?

Ich habe nur eine warp3 wallbox und steuere die eigentlich über mqtt im homeassistant, aber das der fernzugriff hat auch noch NIE funktioniert. ich probiere es nach updates immer mal wieder aus, aber heute habe ich mir nochmal die mühe gemacht das Debugging KI unterstützt und systematisch zu machen. Ergebnis der fritzbox mitschnittte für wan und lan ist, dass die https verbindung mit dem portal anstandslos funktioniert (kann mich sauber registrieren, sehe aktualisierungen aber keine Verbindungsmöglichkeit) aber auf der LAN Bridge des routers kommt schlicht gar kein udp von der wallbox an (im wireshark mit "ip.src == meinwallboxip && udp" gefiltert leer), obwohl sie es vermeintlich probiert:
2026-10-08 13:56:11,230 | remote_access | Management connection timed out

2026-10-08 13:56:39,707 | remote_access | Connecting to Management WireGuard peer my.warp-charger.com:51820

2026-10-08 13:57:43,625 | remote_access | Management connection timed out

2026-10-08 13:57:46,109 | remote_access | Connecting to Management WireGuard peer my.warp-charger.com:51820

2026-10-08 13:58:49,009 | remote_access | Management connection timed out

...

Ein KI-Verdacht wäre noch dass es an ein falsches interface gebunden ist, aber ich habe den AP auch mal nur als fallback installiert und bin sonst über LAN verbunden. Ein generierte Formulieurng für diese Nachfrage ist:
"Laut Code (remote_access.cpp, master) wird der Rückgabewert von management->begin() nicht geprüft, und „Connecting…“ wird vor DNS-Auflösung und Tunnelaufbau geloggt. Mein Mitschnitt zeigt kein einziges UDP-Paket der Wallbox. Ich vermute, dass begin() still fehlschlägt. Ließe sich hier Fehler-Logging ergänzen oder eine Debug-Firmware bereitstellen?"

Jetzt lese ich hier das ein Switch schuld war. Gewisse Switch-Kaskaden habe ich auch. Kann man das genauer beschreiben was das Problem war? Eigentlich denke ich nicht dass Switche im reinen L2-Switching ein Rolle spielen sollten und ntp funktioniert ja auch, aber mir fällt auch nichts mehr ein.

Bitte lade einen Debug-Report runter (unter System → Ereignis-Log) und hänge ihn hier an.

oh ja, bitteschön

warp3-2fmf-Debug-Report-2026-10-08T14-50-39-342.txt

Du hast zwei DNS-Server konfiguriert. 192.168.178.21 ist primär, 192.168.178.1 ist sekundär. Letzteres ist wahrscheinlich die FritzBox. Anfragen gehen immer zuerst an den primären Server raus. Ich weiß nicht, was das für ein Gerät ist oder was es antwortet, aber auf jeden Fall wundert es mich nicht, wenn du auf der FritzBox keine Anfragen siehst.

Kannst du mal 192.168.178.21 entfernen und nur die FritzBox als primären Server eintragen?

On 10/8/2026 at 2:10 PM, SleepyEye79 said:

Ein KI-Verdacht wäre noch dass es an ein falsches interface gebunden ist, aber ich habe den AP auch mal nur als fallback installiert und bin sonst über LAN verbunden. Ein generierte Formulieurng für diese Nachfrage ist:
"Laut Code (remote_access.cpp, master) wird der Rückgabewert von management->begin() nicht geprüft, und „Connecting…“ wird vor DNS-Auflösung und Tunnelaufbau geloggt. Mein Mitschnitt zeigt kein einziges UDP-Paket der Wallbox. Ich vermute, dass begin() still fehlschlägt. Ließe sich hier Fehler-Logging ergänzen oder eine Debug-Firmware bereitstellen?"

Spontan würde ich KI-Schwachsinn vermuten, da management->begin() erst ausgeführt wird, nachdem bereits eine HTTPS-Anfrage an den selben Server erfolgreich war. Du hättest also zumindest die DNS-Anfrage vor der HTTPS-Anfrage sehen müssen.