✔ Galaxy Watch4: "Kopieren Ihrer Google-Konten nicht möglich"

[Corwin-Amber]

Hi,

ich kann mein Google Konto im Rahmen des Erst-Setups nicht auf die neue Galaxy Watch 4 Kopieren. Es kommt zu oben genannter Fehlermeldung.
Ursache könnte auch sein, dass scheinbar mein Samsung Account nicht auf die Uhr kopiert wird. Sehe ich in der Wearable App unter Konto und Sicherung nach, steht dort bei 'Samsung Account': 'Wird auf Ihre Uhr kopiert. Ebsnso ist in der Uhr eine Benachrichtigung mit der Bezeichnung 'Samsung Account' und dem Inhalt 'anmelden'.

Bisher erfolglos versucht:
- Reset der Uhr
- Deinstallieren des Watch Plugins
- Deinstallieren aller Plugins (Buds pro, Watch 3) un dder Wearable App an sich
- Neustart des Gerätes und Neuinstallation aller Werable Apps / Plugins.

Leider bisher erfolglos. Ich kann die Uhr nicht sichern oder nach Software Updates suchen.

Geht es noch jemandem so?

Danke euch

 

[Corwin-Amber]

Hi @Dillinger2020,

es gibt hier eine mehrstufige Firewallanordnung, eine Fritz draussen (wegen des Telekom Glas), dazwischen eine DMZ und innen die UDM. Dazwischen ein Double NAT und einzelne Ports (z.B. Wireguard und IPSEC VPNs) nach draußen forwarded.

In der UDM selbst sind in der Firewall diverse Gruppen angelegt, z.B. 'DNS-Resolver' (pi-holes, deren VIP, Testgeräte). Nur diese dürfen Ziele mit Port 53 TCP/UDP im Internet ansprechen. Weiterhin gibt es diverse WLANs und VLANs. Geräte im für Handy und Uhr relevanten VLAN bekommen per DHCP die VIP der pi-holes als DNS-Server zugewiesen.

Nun gibt es eine weitere Gruppe 'DNS-Offender'. Diese kennzeichnet sich dadurch, daß die Geräte versuchen, hardcoded DNS-Server zu verwenden, in aller Regel 8.8.8.8 und 8.8.4.4. Amazon Alexa-Geräte z.B. sind das. Sie failen aber nicht, wenn sie die Google-DNS Server nicht erreichen können, sondern respektieren dann eben den per DHCP zugewiesenen DNS-Server.
Als 'DNS-Offender' dazu kommt nun das Handy, auf dem die Galaxy Watch 4 eingerichtet wurde. Am einfachsten lässt sich das nachvollziehen, wenn man nach aktualisierter Firmware sucht. Im Firewallog tauchen dann Denies nach 8.8.8.8 und 8.8.4.4., Zielport 53, auf. Der Firmware-Updatecheck schlägt fehl. Erlaubt man mit einer weiteren Firewallregel den Traffic, funktioniert der Updatecheck. Es ist klar nachvollziehbar.

Als Workaround habe ich nun folgendes gemacht (kopiere mal einen Teil meiner Doku rein):

Bekannte DNS-Offender, welche 8.8.8.8 kontaktieren wollen, werden per iptables nach Pihole umgeleitet. Dazu notwendig ist noch eine Firewallregel im UDM-UI, welche Anfragen von den DNS-Offendern nach Pihole erlaubt in LAN in.

Für den Redirect auf der UDM ausführen:
iptables -t nat -A PREROUTING -s 192.168.128.0/24 -d 8.8.8.8/32 -p tcp -m tcp -m iprange --src-range 192.168.128.100-192.168.128.200 --dport 53 -j DNAT --to-destination 192.168.128.xxx:53
iptables -t nat -A PREROUTING -s 192.168.128.0/24 -d 8.8.8.8/32 -p udp -m udp -m iprange --src-range 192.168.128.100-192.168.128.200 --dport 53 -j DNAT --to-destination 192.168.128.xxx:53
iptables -t nat -A POSTROUTING -m iprange --src-range 192.168.128.100-192.168.128.200 -j MASQUERADE

Das ist per se nicht persistent, dazu gibt es aber die UDM-Utilities ( GitHub - boostchicken/udm-utilities: A collection of things I have made to make the Unifi Dream Machine more useful ).

192.168.128.xxx ist die pihole-VIP.

Zu Deinen Fragen:
- Von unterwegs gibt es einen on demand WG-Tunnel nach zuhause, wobei wireless Android Auto mir hier einen Strich durch die Rechnung macht (funktioniert nicht, wenn ein VPN aktiv ist, obwohl die Routen ganz klar abgegrenzt sind, egal).
- Geräte werden natürlich *nicht* gerootet, das setzt Basis-Sicherheitsfunktionen außer Kraft.
- Probleme treten bei der Erstinstallation und im Betrieb auf (Samsung Account bleibt auf 'wird auf das Gerät kopiert' stehen, Google Account lässt sich nicht hinzufügen, Firmware Updates sind nicht möglich, Software Updates sind nicht möglich (App-Updates).

Ich mache IT-Security hardcore beruflich, für mich ist das kein großes Thema. Eine fehlschlagende Erstinstallation kostet mich aber Zeit, zumal ich ja erstmal draufkommen muss, woran es liegt. Weiterhin ist es einfach ultraschlechter Stil, DNS überhaupt hard zu coden. Richtig schlecht wird es aber, wenn es dann nichtmal den per DHCP zugewiesenen DNS-Server als Fallback nimmt.
Theoretisch kann ein hardcoded DNS-Server auch als Sicherheitsfeature gesehen werden, allerdings ist er das nicht wirklich. Jede einigermaßen fähige Firewall (und jeder Angreifer) kann den Traffic schlicht umleiten. Certificate Pinning ist hier das Mittel der Wahl, um eine vertrauenswürdige Gegenstelle sicherzustellen.

Weiterhin ist es ein essentielles Sicherheitsfeature, alle Geräte (insbesondere PCs) zu zwingen, einen DNS unter der Kontrolle des eigenen Netzwerkes zu verwenden. Dadurch lassen sich z.B. zentral Call-home Versuche von Malware detektieren und möglicherweise unterbinden. Es gibt keinen Kundennutzen dabei, nur hardcoded DNS zu verwenden, nur Schaden. Und der Hersteller macht mir als seinem Arbeitgeber das Leben schwer - da krieg ich eigentlich Pickel.

Ich weiß, 99,5% der Nutzer interessiert das nicht, mich schon. Ich schreibe es einfach mal zusammen - vielleicht stolpert ja jemand darüber, so wie ich - der hat dann weniger Arbeit

Ciao,
Corwin

 

[Corwin-Amber]

Okay, nachdem es beim S20+ der besseren Hälfte auch nicht ging, habe ich überlegt, was das Problem sein könnte.

Ein Blick ins Firewallog der UDM zeigt, dass das gekoppelte Handy UNBEDINGT den Google DNS (8.8.8.8 und 8.8.4.4) verwenden möchte. OHNE geht es nicht, was eine bodenlose Frechheit ist. Bei mir dürfen Geräte aber nicht direkt mit einem externen DNS sprechen, sondern haben den DNS zu respektieren, der ihnen per DHCP zugewiesen wird (in meinem Fall ein pihole). Andere Anfragen werden an der Firewall geblockt. Das ist eine sinnvolle Maßnahme, die noch dazu von Google / Samsug NICHT zu beurteilen ist. Also ein absichtlicher Lock-In Fail von Google.

Und tschüss, Galaxy Watch.

 

[Robster23]

Hatte ich auch. Habs übersprungen. Ging dann problemlos später in der App

 

[Corwin-Amber]

Schön wäre es, ist aber in meinem Fall nachvollziehbar nicht so. Wenn Du den Google DNS blockst, wird der per DHCP zugewiesene DNS-Server nicht genommen und die Einrichtung schlägt fehl. Das kann ich anhand der Firewalllogs nachvollziehbar belegen und reproduzieren.

Es liegt nicht an den Leuten, die für mich arbeiten (Google, Samsung) zu bestimmen, welche DNS-Server ich verwende. In vernünftigen Firmennetzwerken ist es eh Standard, dass natürlich nicht beliegibe DNS-Server verwendet werden können.

Das ist einfach falsch.

 

[Dillinger2020]

@Corwin-Amber

Hallo,
nur ne kurze Verständnissfrage,
wie Du berichtest setzt Du ja eine UDM-Firewall ein um dein Wlan Zuhause abzusichern. Ist ja schon etwas aufwendiger als sich durch ne Fritzbox zu klicken. Wie machst Du denn draussen im LTE/5G dein Gerät sicher? Hast Du die Telefone gerootet und per ndc resolver setnetdns umgestellt oder machst Du nur ein lokales VPN auf? Ich frage nur interessehalber, weil ne Smartwatch und ein Mobiltelefon nimmt man ja sinnvollerweise mal mit wenn man nicht Zuhause ist, man möchte ja dann auch erreichbar sein, bzw von sich aus mit Mitmenschen in Kontakt treten können. Ich habe es ja selber nicht getestet, aber geht es nur um die Erstinstallation, oder funktioniert die Watch generell nur mit 8.8.8.8 ? Bei ersteren Fall könnte man ja den einmaligen Zugriff über eine geeignet abgesicherte Konfigkuration zulassen.
MfG
Dillinger2020 ......EoF..........

 

[Corwin-Amber]

Hi @Dillinger2020,

es gibt hier eine mehrstufige Firewallanordnung, eine Fritz draussen (wegen des Telekom Glas), dazwischen eine DMZ und innen die UDM. Dazwischen ein Double NAT und einzelne Ports (z.B. Wireguard und IPSEC VPNs) nach draußen forwarded.

In der UDM selbst sind in der Firewall diverse Gruppen angelegt, z.B. 'DNS-Resolver' (pi-holes, deren VIP, Testgeräte). Nur diese dürfen Ziele mit Port 53 TCP/UDP im Internet ansprechen. Weiterhin gibt es diverse WLANs und VLANs. Geräte im für Handy und Uhr relevanten VLAN bekommen per DHCP die VIP der pi-holes als DNS-Server zugewiesen.

Nun gibt es eine weitere Gruppe 'DNS-Offender'. Diese kennzeichnet sich dadurch, daß die Geräte versuchen, hardcoded DNS-Server zu verwenden, in aller Regel 8.8.8.8 und 8.8.4.4. Amazon Alexa-Geräte z.B. sind das. Sie failen aber nicht, wenn sie die Google-DNS Server nicht erreichen können, sondern respektieren dann eben den per DHCP zugewiesenen DNS-Server.
Als 'DNS-Offender' dazu kommt nun das Handy, auf dem die Galaxy Watch 4 eingerichtet wurde. Am einfachsten lässt sich das nachvollziehen, wenn man nach aktualisierter Firmware sucht. Im Firewallog tauchen dann Denies nach 8.8.8.8 und 8.8.4.4., Zielport 53, auf. Der Firmware-Updatecheck schlägt fehl. Erlaubt man mit einer weiteren Firewallregel den Traffic, funktioniert der Updatecheck. Es ist klar nachvollziehbar.

Als Workaround habe ich nun folgendes gemacht (kopiere mal einen Teil meiner Doku rein):

Bekannte DNS-Offender, welche 8.8.8.8 kontaktieren wollen, werden per iptables nach Pihole umgeleitet. Dazu notwendig ist noch eine Firewallregel im UDM-UI, welche Anfragen von den DNS-Offendern nach Pihole erlaubt in LAN in.

Für den Redirect auf der UDM ausführen:
iptables -t nat -A PREROUTING -s 192.168.128.0/24 -d 8.8.8.8/32 -p tcp -m tcp -m iprange --src-range 192.168.128.100-192.168.128.200 --dport 53 -j DNAT --to-destination 192.168.128.xxx:53
iptables -t nat -A PREROUTING -s 192.168.128.0/24 -d 8.8.8.8/32 -p udp -m udp -m iprange --src-range 192.168.128.100-192.168.128.200 --dport 53 -j DNAT --to-destination 192.168.128.xxx:53
iptables -t nat -A POSTROUTING -m iprange --src-range 192.168.128.100-192.168.128.200 -j MASQUERADE

Das ist per se nicht persistent, dazu gibt es aber die UDM-Utilities ( GitHub - boostchicken/udm-utilities: A collection of things I have made to make the Unifi Dream Machine more useful ).

192.168.128.xxx ist die pihole-VIP.

Zu Deinen Fragen:
- Von unterwegs gibt es einen on demand WG-Tunnel nach zuhause, wobei wireless Android Auto mir hier einen Strich durch die Rechnung macht (funktioniert nicht, wenn ein VPN aktiv ist, obwohl die Routen ganz klar abgegrenzt sind, egal).
- Geräte werden natürlich *nicht* gerootet, das setzt Basis-Sicherheitsfunktionen außer Kraft.
- Probleme treten bei der Erstinstallation und im Betrieb auf (Samsung Account bleibt auf 'wird auf das Gerät kopiert' stehen, Google Account lässt sich nicht hinzufügen, Firmware Updates sind nicht möglich, Software Updates sind nicht möglich (App-Updates).

Ich mache IT-Security hardcore beruflich, für mich ist das kein großes Thema. Eine fehlschlagende Erstinstallation kostet mich aber Zeit, zumal ich ja erstmal draufkommen muss, woran es liegt. Weiterhin ist es einfach ultraschlechter Stil, DNS überhaupt hard zu coden. Richtig schlecht wird es aber, wenn es dann nichtmal den per DHCP zugewiesenen DNS-Server als Fallback nimmt.
Theoretisch kann ein hardcoded DNS-Server auch als Sicherheitsfeature gesehen werden, allerdings ist er das nicht wirklich. Jede einigermaßen fähige Firewall (und jeder Angreifer) kann den Traffic schlicht umleiten. Certificate Pinning ist hier das Mittel der Wahl, um eine vertrauenswürdige Gegenstelle sicherzustellen.

Weiterhin ist es ein essentielles Sicherheitsfeature, alle Geräte (insbesondere PCs) zu zwingen, einen DNS unter der Kontrolle des eigenen Netzwerkes zu verwenden. Dadurch lassen sich z.B. zentral Call-home Versuche von Malware detektieren und möglicherweise unterbinden. Es gibt keinen Kundennutzen dabei, nur hardcoded DNS zu verwenden, nur Schaden. Und der Hersteller macht mir als seinem Arbeitgeber das Leben schwer - da krieg ich eigentlich Pickel.

Ich weiß, 99,5% der Nutzer interessiert das nicht, mich schon. Ich schreibe es einfach mal zusammen - vielleicht stolpert ja jemand darüber, so wie ich - der hat dann weniger Arbeit

Ciao,
Corwin

 

[Dillinger2020]

Hallo @Corwin-Amber
Ich danke für die sehr ausführliche Antwort, und hoffe Du kaufst Dir kein Auto 'a la Tesla', es sei denn man steht drauf fremdgesteuert zu werden.
Ich für meinen Teil habe irgendwann aufgehört gegen Windmühlen zu kämpfen, und versuche mich entlang eines schmalen Grat zu bewegen zwischen Komfort und Restrisiko. Ich benutze längst nicht alle modernen Dinge um meinen digitalen Fußabdruck klein zu halten, aber manchen Sachen kann Ich doch nicht widerstehen. (ne Swartwatch z.B., jetzt aber nicht unbedingt jeder neue Social-Media Hype).
Gruß
Dillinger2020 .........EoF...........

 

[Corwin-Amber]

Hi @Dillinger2020

OT:
Ich bin ein totaler Nerd und nutze die Technik gerne bis zum Anschlag. Dinge wie z.B. den Google Standortverlauf zu nutzen, ist eine bewusste Entscheidung, weil die Daten ohnehin anfallen - so bekomme halt *auch ich* Zugriff darauf. So verhält es sich auch mit anderen Dingen. Ich denke, wir sind uns da ähnlich, Du schreibst das oben genau so - bewusst verwenden, Risiken minimieren.

Aber bei dem Thema oben gibt es keinen Vorteil für uns Kunden, es ist einfach Unvermögen oder böser Wille - keine Ahnung. Die heute übliche Herstellermentalität von 'friss oder lass es' und die 'Iphonisierung von Fehlermeldungen' im Stil von 'geht nicht, vielleicht später wieder?' anstatt einer zumindest ein wenig aussagekräftigen Fehlermeldung, macht es nicht leichter.
Ich sehe an 'normalen' (und auch jungen) Leuten, wie wehrlos, vor allem aber hilflos diese gegenüber der Technologie sind, die aber einen immer wichtigeren Stellenwert einnimmt - coden und solide Grundkenntnisse sollten eigentlich gleich nach Lesen und Schreiben gelehrt werden

BTT:
Magst Du mir bitte einen Gefallen tun und meinen Beitrag oben als Lösung markieren? Ich selbst kann das nicht (hoffe, der OP kann überhaupt als Lösung markiert werden).

Ciao,
Corwin

 

[Dillinger2020]

Hi,
nur kurz, Ich hab hier nix zum als Lösung markieren, das können hier glaub Ich nur die 'Offiziellen'