Nextcloud Android App IPv6 Probleme über nicht WLAN Verbindungen?

Hallo Gemeinde,

ich betreibe Zuhause einen Nextcloud Server 20.0.3 mit einem Ubuntu 20.04.1 LTS. Alles läuft wie es soll, bis auf die Nextcloud App auf Android - und zwar nur wenn diese nicht im WLAN ist.

Es sieht wohl so aus, das (endlich) die Telekom auf native IPv4 + IPv6 Adressen umgestellt hat. Sprich, mein Handy hat eine IPv4 und eine IPv6 Adresse im 4G Netz. Ich gehe davon aus, das dass Android 10 dann bevorzugt die IPv6 verwendet.

Warum er dann allerdings per App nicht zum Server kommt ist mir gerade unklar. Ping vom Handy aus geht, die Webseite ist per Browser auch erreichbar. Bei einer erneuten Anmeldung in der App kommt er mit “Host nicht gefunden”. Teste ich die aktuelle IPv4 Adresse anstatt den DNS-Namen der Subdomain schlägt er an, kommt aber korrekterweise mit einem Zertifikatsfehler. Er kommt also hin. Warum macht da die Subdomain Probleme?

Provider ist Vodafone mit Dual-Stack. Habe also IPv4 + IPv6 nach außen. Gut so.

Per WireGuard über das 4G Netz klappt alles wunderbar. Dort gibt es aktuelle bei mit keine IPv6 Adresse.

Ich gehe aktuell von keinem Fehler der Systeme aus (Serverconfig, FritzBox, NAT, DNS).

Weiß hier jemand mehr?
Ich danke.

1 Like

Hat denn niemand das gleiche Problem?

Ich habe das gleiche Problem. Provider bei mir ist Willy Tel (Hamburg).
Der Aufruf über den Android Browser ist erfolgreich, in der Nextcloud App kommt die Meldung “Konnte den Host nicht finden”.

Beim Aufruf mit curl sieht man “Keine Berechtigung”, er macht aber ein Fallback auf ipv4.
“Access denied” meldet auch die Nextcloud Notes App.

$ curl -v https://mycloud.sonstwo.de
*   Trying 2a04:xxxx:xxxx:xx::xxx:443...
* connect to 2a04:xxxx:xxxx:xx::xxx port 443 failed: Keine Berechtigung
*   Trying 199.1.1.1:443...
* Connected to mycloud.sonstwo.de (199.1.1.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):

Bei mir ist der Fehler irgendwo in meinen Fritzbox-Einstellungen, da ich über die öffentliche ipv6-Adresse der Fritzbox keine Verbindung herstellen kann, über die ipv6-Adresse des Zielgerätes jedoch schon.

Es wäre jedoch schön, wenn die Nextcloud-App auch einen Fallback auf ipv4 machen würde.

Ich konnte das Problem bei mir lösen.

Dieser Beitrag war hilfreich für mich: https://www.router-forum.de/avm-fritzbox/fritz-box-ipv6-dyndns-und-forwarding.t67575/#:~:text=Bei%20IPv6%20gibt%20es%20kein,Freigabe%20der%20Box%20selbst%20aufrufbar.

“Bei IPv6 gibt es kein “Port Forwarding”. Das, was du bei IPv6 in der FB konfigurierst, sind Freischaltungen in der Firewall.”

Das habe ich zwar schon öfter gehört, aber bin noch nie in der Praxis damit in Berührung gekommen. Schön, dass ich es noch 2020 lernen konnte. :smiley:

Eine Freischaltung über “MyFritz” war für mich die Lösung. Ärgerlich, dass es nicht ohne den Dienst geht. Dann bekomme ich eine neue Subdomain für meinen Server (myserver.xxx.myfritz.net).

Intuitiv finde ich das schlechter, denn wenn ich jetzt das Gerät bei mir im Netzwerk wechsel, ändert sich auch der Servername bei allen Clients…?!

Aber vorerst bin ich froh, dass die Verbindung wieder funktioniert.

Bir mir das gleiche:

curl: try 'curl --help' or 'curl --manual' for more information
$ curl -v subdomain.domain.de
*   Trying 2a02:xxx:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:xxxx
* connect to 2a02:xxx:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:xxxx port 80 failed: Permission denied
*   Trying 188.xxx.xxx.xx:80...
* Connected to subdomain.domain.de (188.xxx.xxx.xx) port 80 (#0)
> GET / HTTP/1.1
> Host: subdomain.domain.de
> User-Agent: curl/7.72.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Mon, 21 Dec 2020 07:30:45 GMT
< Content-Type: text/html
< Content-Length: 162
< Connection: keep-alive
< Location: https://subdomain.domain.de/
<
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host subdomain.domain.de left intact
$

Wenn ich die IPv6 Adresse des Servers Angebe kommt ein “Konnte den Host nicht finden”, wenn ich die IPv4 Adresse angebe, kommt er hin. Wenn ich vom Handy aus die Webseite Aufrufe komme ich hin, kein Problem.

Ich nutze https://dynv6.com/ für den DynamicDNS Dienst. Bei meinem Provider ist wiederrum ein CNAME Eintrag auf die Subdomain.

Für mich ist das ein Problem der App selbst.

Leute IPv6 gibt es nicht seit gestern :slight_smile:

MyFRITZ! funktioniert bei mir auch nicht. Wüsste auch nicht warum. Ich bekomme die gleichen IPv4 + IPv6 Adressen zurück wie von meiner richtigen Subdomain. Sprich: Die Dienste dahinter laufen so wie sie sollen.

Das muss aus meiner Sicht an der App liegen.

Oder?

Dann stimmt was mit deinem ipv6 routing nicht.

Das schließe ich mal aus, weil ich mit der IPv6 Adresse per Browser auf die Seite komme (Zertifikatsfehler / Zugriff über eine nicht vertrauenswürdige Domain).

Hier funktioniert das offensichtlich nicht.

Stimmt, da hatte ich ausversehen das falsche rein.

$ curl -v https://[2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]/
*   Trying 2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:443...
* Connected to 2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx (2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /data/data/com.termux/files/usr/etc/tls/cert.pem
  CApath: /data/data/com.termux/files/usr/etc/tls/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=subdomain.domain.de
*  start date: Oct 20 01:00:17 2020 GMT
*  expire date: Jan 18 01:00:17 2021 GMT
*  subjectAltName does not match 2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
* SSL: no alternative certificate subject name matches target host name '2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx'
* Closing connection 0
* TLSv1.3 (OUT), TLS alert, close notify (256):
curl: (60) SSL: no alternative certificate subject name matches target host name '2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx'
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
$

Viele Dienste und Clients versuchen gerne erstmal auf Port 80, wenn der dicht ist und nicht weitergeleitet wird, kann das ggf. schon als nicht erreichbar interpretiert werden…

Port 80 und 443 ist für IPv4 und IPv6 erreichbar.

Keiner gibt https:// … ein, sondern nur subdomain.domain.de.

Dann scheint es ja am DNS zu liegen…?
Magst Du mal den Output von
dig subdomain.domain.de AAAA
posten?

Und einmal
curl -v https://subdomain.domain.de
(Du hattest es bisher nur für http gepostet).

Wenn Du einen Bug in der Nextcloud App vermutest, müsste das curl mit Domain ja funktionieren.

Hmmmmm …

https

$ curl -v https://subdomain.domain.de
*   Trying 2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:443...
* connect to 2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 443 failed: Permission denied
*   Trying 188.xxx.xxx.xxx:443...
* Connected to subdomain.domain.de (188.xxx.xxx.xxx) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /data/data/com.termux/files/usr/etc/tls/cert.pem
  CApath: /data/data/com.termux/files/usr/etc/tls/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=subdomain.domain.de
*  start date: Oct 20 01:00:17 2020 GMT
*  expire date: Jan 18 01:00:17 2021 GMT
*  subjectAltName: host "subdomain.domain.de" matched cert's "subdomain.domain.de"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x746a610800)
> GET / HTTP/2
> Host: subdomain.domain.de
> user-agent: curl/7.72.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 302
< server: nginx
< date: Tue, 22 Dec 2020 07:54:02 GMT
< content-type: text/html; charset=UTF-8
< location: https://subdomain.domain.de/login
< expires: Thu, 19 Nov 1981 08:52:00 GMT
< cache-control: no-store, no-cache, must-revalidate
< pragma: no-cache
< set-cookie: oc_sessionPassphrase=uDnmbvzfmgeyCxjWaKiLbuzJZfodHddl%2FlsrbsTtTUASg%2FrEZzL8WzpAgN6cJA6kDmnCb2f7KXoaTsQGLJgPdCap4Lodx14z0xmR7Ijg0RsgsfW6u0FO8jhiOFz2GKA%2F; path=/; secure; HttpOnly; SameSite=Lax
< set-cookie: ocjbjsc45z0x=8rjvvteq85god9u3j4204st8jm; path=/; secure; HttpOnly; SameSite=Lax
< content-security-policy: default-src 'self'; script-src 'self' 'nonce-NUlkYVY1bEFJQ3NGOUJZYS9JUkJ5RU05UnBTZFFtOFhRelY0NlVNdjRtQT06aGRNWkR0Y1hhbDlza1NCMnI5NTUrWEpRUE5iZWNTeDJERm9hdURwbmt6Yz0='; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *; object-src 'none'; base-uri 'self';
< set-cookie: __Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
< set-cookie: __Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
< strict-transport-security: max-age=63072000; includeSubdomains; preload;
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< x-robots-tag: none
< x-download-options: noopen
< x-permitted-cross-domain-policies: none
< referrer-policy: no-referrer
< x-frame-options: SAMEORIGIN
<
* Connection #0 to host subdomain.domain.de left intact

http

**$ curl -v http://subdomain.domain.de
***   Trying 2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:80...
*** connect to 2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx port 80 failed: Permission denied
***   Trying 188.xxx.xxx.xxx:80...
*** Connected to subdomain.domain.de (188.xxx.xxx.xxx) port 80 (#0)
**> GET / HTTP/1.1
**> Host: subdomain.domain.de
**> User-Agent: curl/7.72.0
**> Accept: */*
**>
*** Mark bundle as not supporting multiuse
**< HTTP/1.1 301 Moved Permanently
**< Server: nginx
**< Date: Tue, 22 Dec 2020 07:54:19 GMT
**< Content-Type: text/html
**< Content-Length: 162
**< Connection: keep-alive
**< Location: https://subdomain.domain.de/
**<
**<html>
**<head><title>301 Moved Permanently</title></head>
**<body>
**<center><h1>301 Moved Permanently</h1></center>
**<hr><center>nginx</center>
**</body>
**</html>
*** Connection #0 to host subdomain.domain.de left intact
**$

Wie man sieht kommt er mit http Port 80 hin zum Webserver.

Laut App sollte doch https Port 443 ausreichen.

Mein nginx leitet ja alles von http auf https um. Ich habe mich nach dieser super Anleitung gehalten:

Jemand noch Ideen?

Okay also die curls gehen nicht mit ipv6. Es ist also kein Problem der Nextcloud App.

Da der hier geht:
curl -v https://[2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]/

Und der nicht:
curl -v https://subdomain.domain.de

…ist es Dein DNS.

Was liefert denn
dig subdomain.domain.de AAAA

Vermutlich stimmt die Adresse nicht mit der aus dem curl oben überein.

Denke nicht das es ein DNS Problem ist …

IPv6 AAAA
$ dig subdomain.domain.de aaaa

; <<>> DiG 9.16.9 <<>> subdomain.domain.de aaaa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44668
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;subdomain.domain.de.             IN      AAAA

;; ANSWER SECTION:
subdomain.domain.de.      21599   IN      CNAME   subdomain.dynv6.net.
subdomain.dynv6.net.     59      IN      AAAA    2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

;; Query time: 90 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Dec 22 10:41:07 CET 2020
;; MSG SIZE  rcvd: 106

$ dig subdomain.domain.de aa

IPv4 AA

; <<>> DiG 9.16.9 <<>> subdomain.domain.de aa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37409
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;subdomain.domain.de.             IN      A

;; ANSWER SECTION:
subdomain.domain.de.      21599   IN      CNAME   subdomain.dynv6.net.
subdomain.dynv6.net.     59      IN      A       188.xxx.xxx.xxx

;; Query time: 90 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Dec 22 10:41:15 CET 2020
;; MSG SIZE  rcvd: 94

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60395
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;aa.                            IN      A

;; AUTHORITY SECTION:
.                       86257   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2020122200 1800 900 604800 86400

;; Query time: 30 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Dec 22 10:41:15 CET 2020
;; MSG SIZE  rcvd: 106

$

Termux nimmt komischerweise den 8.8.8.8 als DNS, anstatt den vom Provider. Interessant.

Der Server ist jetzt mit einer Subdomain unter einer IPv4 und IPv6 Adresse direkt erreichbar. Ich denke das war der Fehler.

Tipp zum Testen von IPv6 Pings.
http://ipv6now.com.au/pingme.php

Hallo,
ich bin am Verzweifeln und mit meinem Latein am Ende, habe schon die verschiedensten Dinge probiert und es will nicht funktionieren.

Ausgangslage ist:
NAS mit OMV darauf läuft NC mit MariaDB im Docker geroutet wird mit Traefik auf den Host mit Port 443.

Egal was ich probiere, die App will seit Version 3.14 nicht mehr. Manchmal scheint diese sich zu verbinden, denn vereinzelt lädt diese Bilder hoch.
Auch ging es Mal kurzzeitig mit Mobilfunk.

Irgendwer einen Tipp für mich?
Wenn ich Curl -v subdomain.dedyn.io
oder Big subdomain.dedyn.io AAAA

Aufrufe habe ich eine unterschiedliche IPv6 Adresse als der DDClient ausgibt.
Wo liegt mein Denkfehler??

Hallo zusammen,

ich habe das gleiche oder ein ähnliches Problem, verstehe die Lösungsansätze in diesem Threat jedoch nicht. Könnte evtl. jemand weniger technisch erklären, was zu tun ist?

Nach Installation der Android App möchte ich mich mit dem QR-Code anmelden. Die dadurch eingetragene URL ist auch korrekt und wenn ich diese kopiere und mit einem Browser auf dem Smartphone aufrufe, kann ich mich ohne Probleme anmelden.

Die App schreibt jedoch „Verbindung testen“ und dann kommt immer „Konnte den Host nicht finden“.

Andere Einstellmöglichkeiten sehe ich nicht und ich konnte zwar das Problem online finden, jedoch keine Lösung dazu. Mit der IP statt URL funktioniert es ebenfalls nicht. Über verschiedene Browser und Geräte gibt es sonst keine Probleme mit der Anmeldung, sondern nur mit der App.

Was kann ich bitte noch versuchen?

Nextcloud 19.0.12 läuft auf einem QNAP TVS 672XT mit Linux 4.14.24-qnap x86_64. Ein Update auf 20.0.10 schlägt jedoch fehl.

Danke & viele Grüße,

Rico