Network requests failed error with Nextcloud 20

Support
1
  • Joplin Android v1.3.13
  • Lineageos 17.1 (Android 10)

Hi,
I just changed my Nexcloud server, and now cannot sync anymore. I saw a lot of posts about this error, but I am a bit lost, and it is most probably related to my configuration so here are the details :

  • Nextcloud 20.0.2 is running on Openmediavault, as well as Swag (formely known as letsencrypt) as reverse proxy.
  • Certificates have been generated, and SSL Report web site is fine, I got A. It says "RSA 4096 bits (SHA256withRSA)", TLS 1.2 and 1.3 supported, Let's Encrypt Authority X3 issuer.
  • The webdav URL provided by Nextcloud is like the following : "https://nextcloud.my.domain/remote.php/dav/files/user/"
  • On my desktop running Ubuntu, I had to move from "Nextcloud" to "Webdav" in Joplin parameters to make new sync works.
  • On the smartphone, it does not work with the "network requests failed" error.
    Screenshot_20201127-185058_Joplin|281x500
  • I have to mention that on the smartphone when wifi is activated, I have my own DNS activated (Pihole actually) because the domain name must be resolved locally (NAT loopback issue). But this setting works fine for the Nextcloud android application (actually, I need it to make it works).

Voilà, is it supposed to work, or is there something wrong I should look at ? And should I use Webdav or Nextcloud method to sync preferably ?

Thank you for your help.

2

Try v1.4 as it has a fix for certain "Network request failed" errors

3

Thanks, but where can I find 1.4 apk file ? (sorry for the noob question).

4

Hello,
Some good news : I installed Joplin 1.4.11, and tried again. Same error.
Then I disabled WIFI on smartphone, to force GSM usage, and sync finally starts (using Nextcloud connector and webdav URL provided by Nextcloud.
-=-
So it appears to be a "NAT hairpinning" issue (or NAT loopback). On smartphone, I have Blokada application running with my own DNS set, pointing to my Pihole local server. On that Pihole server, I have set the 2 DNS records (A & CNAME) for my local machine running OMV, Nextcloud and Swag.

  • That setting works for Nextcloud client application on the smartphone (I set it up for that purpose).
  • That setting does not work for Joplin sync, so problem is most probably related to DNS resolution and NAT...
    Some more context :
    My WIFI connection is set to DHCP, the Livebox from Orange french provider is the server. I guess it provides me with a IPv6 DNS I cannot remove (even modifying WIFI connection to STATIC and setting my own local DNS), this is why at the end I installed Blokada to make Nextcloud App work...
    It is not clear to me what happens at this stage, but that may help some people facing the "Network request failed" error.
    I hope that helps...
5

Hi!
I have the same issue since an upgrade of Joplin 1.4.11 on Android, I have a configuration with documents on a pi running NextCloudPi... but unfortunately the trick to disable wifi didn't work for me! I

6

Actually it does not work anymore for me. It worked once, then no way to sync anymore.
It is really annoying, and for me a big issue being unable to sync from android. I guess (from what I read here) it is related to certificate, but I dont want to enable http access on my nextcloud server, for security reason.
Because Nextcloud Android App is syncing fine on the same smartphone, there is for sure an issue with Joplin client.
I start thinking about looking for another app for my notes because of this. :frowning:

7

Is your Certificate Chain Complete?

8

@JackGruber,
Thanks, you point me to the right direction. It is working now again with wifi disconnected.
Explanations:
What happened is that I set up Pihole as DHCP provider on my LAN, trying to resolve that " NAT hairpinning" issue. This was required to access Nextcloud webUI and complete my setup :
That way, Pihole also works as DNS provider, and I created to records (A & CNAME) to point to my Nextcloud server Iocal IP Address. So far so good.
So now the smartphone also gets IP and DNS from Pihole. But Joplin still fails to sync in such configuration. And my last tries with wifi were failing, thus my last post.
-=-
Your update about Certificate Chain Complete (which is good by the way) makes me realized one thing : my provider changed my IP address !! (French Orange provider does not grant you static IP address, unfortunately). So this is why my sync was not working anymore on GSM. I had to update my DNS records at the domain level, and now Joplin sync is back when wifi is off !
Good news, I can stay with this limitation, it is not a big deal to me.
QUESTION:
But I have a question then (if you know the answer) : does that mean using my local IP address, my certificate does not work (and therefore makes Joplin sync fails) ? What I observe is that the workaround defining local DNS records to bypass the NAT limitation allows me to access the Nextcloud server UI, but I had to validate a "warning" about certificate before accessing (probably linked to that different IP address). Could that be the reason why Joplin sync fails ??
Thank you anyway for your help.

9

Yes, the certificates schould valid!

Why you don't use names in your configuration / certificates ?

10

When creating the docker container for Nextcloud, I did use names (URL and SUBDOMAINS). And Swag container created the Let's Encrypt certificate (see first post).
-=-
But I still have to confirm certificate when navigating first time from a browser on my LAN: something about "not secured connection", and details say "This Web site contains identifying information that belongs to a different Web site. The identifying data on this website has not been issued by a trusted organization."
Once you accept to continue, all is fine.
-=-
May this is causing the issue with Joplin on the LAN ?

11

So I thought that IPs are used.

From WAN is verything fine?

When this is true, then normaly no certificate warning will not be shown.
Therefore I think that something is wrong with the configuration / call.

12

If the certificate is for a.b.com and you browse internally to 10.0.2.3 you will get such an error. Thus you will have to enter in your /etc/hosts file the following entry:

10.0.2.3 a.b.com
13

My answers in bold:
From WAN is verything fine? yes

When this is true, then normaly no certificate warning will not be shown.
Therefore I think that something is wrong with the configuration / call.

Your certificate is for: nextcloud.my.domain ? nextcloud.host.my.domain
When i read it corectly you use Let's Encrypt certificate? Issuing CA: Let's Encrypt Authority X3
On your pihole you change the IP for nextcloud.my.domain? one A record for host.my.domain, and one CNAME record for nextcloud.my.domain (as registered at domain level)
You use on LAN the FQDN (nextcloud.my.domain) not only nextcloud? Yes, and no issue there. For Joplin, I use the webdav URL provided by nextcloud
Visiting https://nextcloud.my.domain/remote.php/dav/files/user/ from WAN is OK? Yes, get authentification window then webdav interface message like below.
Visting https://nextcloud.my.domain/remote.php/dav/files/user/ from LAN gives an error? No, I get the default message "This is the WebDAV interface. It can only be accessed by WebDAV clients such as the Nextcloud desktop sync client."
Is your Certificate OK when you check it with openssl or an online tool?
https://www.geocerts.com/ssl-checker / openssl s_client -showcerts -servername -connect :
With openssl you can also check your LAN side. All tests are ok, both gocerts (website) and openssl tool (local command line)*, I guess openssl result is the LAN side as my desktop has the pihole DNS for resolver.

14

And where does the certificate warning come in?
Okay, I'm out of here now. Since I don't use NextCloud.

15

Well I don't really agree with that. This is all about resolution name process (services order), whatever it is done by local hosts file or DNS server. So, if hosts file is read first, then I will fallback to my NAT hairpinning issue.
-=-
To keep things simple:

  • my desktop on ethernet LAN (Ubuntu) has no problem with Joplin to sync using "Nextcloud" method. DNS is my pihole server and DNS names points to local address.
  • my smartphone with wifi activated (and pihole as DNS) : Nextcloud app has no problem to sync, Joplin fails systematically (network request failed).
    -=-
    As I said, I can live with that (sync on GSM).
16

If warning has been accepted once, you don' get it anymore.
Thank you for your help !

17

Ok, but than there is a problem with your certificate. Could you post the openssl output?

18

Here it is:

    $ openssl s_client -showcerts -servername nextcloud.host.domain.fr -connect nextcloud.host.domain.fr:443
    CONNECTED(00000003)
    depth=0 C = US, ST = CA, L = Carlsbad, O = Linuxserver.io, OU = LSIO Server, CN = *
    verify error:num=18:self signed certificate
    verify return:1
    depth=0 C = US, ST = CA, L = Carlsbad, O = Linuxserver.io, OU = LSIO Server, CN = *
    verify return:1
    ---
    Certificate chain
     0 s:C = US, ST = CA, L = Carlsbad, O = Linuxserver.io, OU = LSIO Server, CN = *
       i:C = US, ST = CA, L = Carlsbad, O = Linuxserver.io, OU = LSIO Server, CN = *
    -----BEGIN CERTIFICATE-----
    MIIDsTCCApmgAwIBAgIUHIzoFfXc+XLisqE5zmdmZNZp0qMwDQYJKoZIhvcNAQEL
    BQAwaDELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMREwDwYDVQQHDAhDYXJsc2Jh
    ZDEXMBUGA1UECgwOTGludXhzZXJ2ZXIuaW8xFDASBgNVBAsMC0xTSU8gU2VydmVy
    MQowCAYDVQQDDAEqMB4XDTIwMTEyMjE3MTU0NFoXDTMwMTEyMDE3MTU0NFowaDEL
    MAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMREwDwYDVQQHDAhDYXJsc2JhZDEXMBUG
    A1UECgwOTGludXhzZXJ2ZXIuaW8xFDASBgNVBAsMC0xTSU8gU2VydmVyMQowCAYD
    VQQDDAEqMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3SWeIDBW1Rqu
    ojuvDQqayIwR0LgiFKRwBnmcKfBulqMZwzWvXFY6F0UY1XKWJmZDdiYqtQSLoPf+
    af8NM3K6j1RnVl/ulZYr2ElsVt8mfDVvv9MtyKCOBGEIWjCKN8519DQN5np1d/qY
    zu0YWKjonUBENmiMQfqwZzx99xVk9yOYC4ee2zhKw1ut5ndsySWLxU5GFpfOh5z/
    PP7oRNSnWKKW3nYctKIA13ycTmj1Xc+1cfa91ZAXCP3ZuwetgAR4hQJrMrQ9/3TR
    TKqsUp9ONXq+FWHWs69lroRO+IkaLAc5nrkYarqayeLbQa1YEcyxXCL6EhwcU5sG
    f0GDQtWPSwIDAQABo1MwUTAdBgNVHQ4EFgQU/jROGoJhGoawmv+v0z+h+U+yosQw
    HwYDVR0jBBgwFoAU/jROGoJhGoawmv+v0z+h+U+yosQwDwYDVR0TAQH/BAUwAwEB
    /zANBgkqhkiG9w0BAQsFAAOCAQEAPlyQz/QFGxYkvARKoKzhOFpznjPUmRiQ0G+j
    lM+itvYW5/OhChg7EUmjf1HeipcxZzMD9Iy3RdTbePNmDHXZGaaJtLLo79XKsTkt
    QhaKEvmB1eb7bsfsiUESOicv+YL2UvsyykHBS6tp1J03jshLmIyenf2opWaQNiVT
    wCMWdJjBQ7HzMTmMSBMYCO3R2/OVxSiaTGVDiljFUGMXVzC5C3XzsW11XmgWRFmQ
    PnX8e6oueHAfoevx8endX5ATWNO6O4qrGLdWj9Kpyg2e2CmaNBO9TvuQxfpx4RAV
    CSRzVMAQYkw1CSHmOMf/vL79H3dc0oXTPwA51RQ5HZhy/97mfg==
    -----END CERTIFICATE-----
    ---
    Server certificate
    subject=C = US, ST = CA, L = Carlsbad, O = Linuxserver.io, OU = LSIO Server, CN = *

    issuer=C = US, ST = CA, L = Carlsbad, O = Linuxserver.io, OU = LSIO Server, CN = *

    ---
    No client certificate CA names sent
    Peer signing digest: SHA256
    Peer signature type: RSA-PSS
    Server Temp Key: X25519, 253 bits
    ---
    SSL handshake has read 1626 bytes and written 412 bytes
    Verification error: self signed certificate
    ---
    New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
    Server public key is 2048 bit
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
    No ALPN negotiated
    SSL-Session:
        Protocol  : TLSv1.2
        Cipher    : ECDHE-RSA-AES256-GCM-SHA384
        Session-ID: 20C2FBCE8B77A4B746B1806A98EF0D51B9877580F3F328819EC05D31B1F23F1C
        Session-ID-ctx: 
        Master-Key: D3F2230038B358C1C98475719099F43C8176A87B5C4BBE2BEB8FAE493A75A812C2DC6836637FFE24B5BE2E46EA3DE10B
        PSK identity: None
        PSK identity hint: None
        SRP username: None
        TLS session ticket lifetime hint: 300 (seconds)
        TLS session ticket:
        0000 - 44 57 d3 3d 38 d2 f2 16-5a e7 a5 b5 ae 44 a9 8a   DW.=8...Z....D..
        0010 - f1 d9 03 8d 83 38 8f df-fd 34 02 c6 d6 71 68 f9   .....8...4...qh.
        0020 - 1f c6 3b ba 85 5a fd 0a-f6 86 e4 73 30 79 89 c9   ..;..Z.....s0y..
        0030 - 76 f9 d9 28 0b 45 01 6b-44 1e 21 22 8b 45 73 07   v..(.E.kD.!".Es.
        0040 - 58 84 82 57 2d 24 18 7a-26 35 82 c2 45 2a c3 7d   X..W-$.z&5..E*.}
        0050 - fa e1 a5 7e 9f 5e 15 43-03 f7 0b 38 83 d0 ba 00   ...~.^.C...8....
        0060 - c9 ec 75 b4 17 70 bb 2a-dd bb 66 62 f1 af 26 3f   ..u..p.*..fb..&?
        0070 - 73 fe d7 c3 af 5e ed 3e-28 39 5f 21 40 00 4e cf   s....^.>(9_!@.N.
        0080 - fc ca e2 2c 4c e6 93 ca-cb 19 88 e1 62 1a ef d6   ...,L.......b...
        0090 - d6 54 ac 81 3e 28 8a 30-7e 8e 0a 00 b7 7e e0 bd   .T..>(.0~....~..
        00a0 - 52 f4 a9 72 00 01 5c 95-18 a7 f0 ff 40 89 e1 db   R..r..\.....@...
        00b0 - 7a 00 e1 54 5a 08 29 66-f6 e8 cd 61 80 9d 63 5b   z..TZ.)f...a..c[
        00c0 - 74 39 e8 db c2 48 63 70-e1 5d 1d 9a ae b0 50 e4   t9...Hcp.]....P.

        Start Time: 1609669585
        Timeout   : 7200 (sec)
        Verify return code: 18 (self signed certificate)
        Extended master secret: yes
    ---
    closed
̀```
19

Ok, this is a self signed certificate, and not the Let's Encrypt certificate.

C = US, ST = CA, L = Carlsbad, O = Linuxserver.io, OU = LSIO Server, CN = *

This certificate can then not be verified and the Network requests failed error occurs.

20

Ok, I understand. It is a bit confusing to me, because geocerts says:
Screenshot

I have no knowledge about this. Do you know if it is planned to make it work one day, or is it impossible ?