Unable to connect after switching to Wifi (Android Client)

Hi,
I appear unable to connect to nextcloud via the android app after switching from mobile network to Wifi.
I can always connect via firefox.

This only appeared to become an issue after upgrading to a recent Nextcloud client version (in the last few months).

Looking at logcat I’m getting strange messages about it trying to connect to localhost?!?

Note: I have IPv6 disabled in my home network (I did see some bugs related to this but they appear to have been fixed… Maybe this is a regression??

Thanks in advance!

Interesting parts from logcat:

05-25 02:36:05.510  4966 22393 D OwnCloudClient #0: REQUEST GET /status.php
05-25 02:36:05.513   927 22394 D resolv  : GetAddrInfoHandler::run: {100 786532 100 983140 10182 0}
05-25 02:36:05.513   927 22394 D resolv  : resolv_getaddrinfo: explore_fqdn(): ai_family=0 ai_socktype=1 ai_protocol=6
05-25 02:36:05.513   927 22394 D resolv  : android_getaddrinfofornetcontext: explore_numeric: ai_family=10 ai_socktype=1 ai_protocol=6
05-25 02:36:05.513   927 22394 D resolv  : explore_numeric_scope
05-25 02:36:05.513   927 22394 D resolv  : android_getaddrinfofornetcontext: explore_numeric: ai_family=2 ai_socktype=1 ai_protocol=6
05-25 02:36:05.513   927 22394 D resolv  : explore_numeric_scope
05-25 02:36:05.513   927 22394 I ResolverController: No valid NAT64 prefix (100, <unspecified>/0)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: Check for update of Nextcloud server version at https://upload.example.com/remote.php/dav/files/joe: Socket exception
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: java.net.ConnectException: failed to connect to localhost/127.0.0.1 (port 80) from /127.0.0.1 (port 38599) after 60000ms: isConnected failed: ECONNREFUSED (Connection refused)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at libcore.io.IoBridge.isConnected(IoBridge.java:349)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at libcore.io.IoBridge.connectErrno(IoBridge.java:238)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at libcore.io.IoBridge.connect(IoBridge.java:180)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at java.net.PlainSocketImpl.socketConnect(PlainSocketImpl.java:142)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:390)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:230)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:212)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:436)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at java.net.Socket.connect(Socket.java:621)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at java.lang.reflect.Method.invoke(Native Method)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:140)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:125)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at com.owncloud.android.lib.common.OwnCloudClient.executeMethod(OwnCloudClient.java:199)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at com.owncloud.android.operations.UpdateOCVersionOperation.run(UpdateOCVersionOperation.java:74)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at com.owncloud.android.lib.common.operations.RemoteOperation.execute(RemoteOperation.java:187)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at com.owncloud.android.operations.RefreshFolderOperation.updateOCVersion(RefreshFolderOperation.java:277)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at com.owncloud.android.operations.RefreshFolderOperation.run(RefreshFolderOperation.java:231)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at com.owncloud.android.lib.common.operations.RemoteOperation.run(RemoteOperation.java:363)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at java.lang.Thread.run(Thread.java:920)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: Caused by: android.system.ErrnoException: isConnected failed: ECONNREFUSED (Connection refused)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	at libcore.io.IoBridge.isConnected(IoBridge.java:336)
05-25 02:36:05.519  4966 22393 E UpdateOCVersionOperation: 	... 24 more

Most likely you’re running into a DNS resolution problem. If you’re connection to your network using a Wifi connection. Please explain IN DETAIL how your network and DNS setup looks like, what host name you are using to connect to your server and how do you do it using Firefox (on a desktop or on your Android device?).

Activate DNS-/NAT-Loopback in your router.

Your Android device sends a request to the public address of your router “mydomain.com/nextcloud” (f.ex. 89.123.123.123) . The DNS server in your router queries inside the network the domain “mydomain.com”.
Your Nextcloud instance answers, so the router replaces the request to f.ex. 89.123.123.123 over internet by a private network address f.ex. 192.168.1.10 of your Nextcloud instance.

The Android device is expecting an answer from your public network address but receives an answer from private IP. So the device discards the answer.

After enabling DNS-/NAT-Loopback, the router replaces in the answer of your Nextcloud instance its private IP address by the public IP address to forward it to your Android device.

So your Android device will accept the answer and can communicate now.

Thanks for the tips/advice:)

I run a private BIND DNS that servers the same domain that is publicly accessible, privately (I believe this can be referred to as split horizon DNS), so when on mobile data (not on home network) I get the public IP (from my public DNS server) which is then NATed to my server and when on WIFI I get the servers private IP (from my private DNS server).

Anyway enabling “Reflection for port forwards” in Opnsense seems to have fixed it although I still don’t understand why it would be going to the public IP? And whats with the mention of localhost (127.0.0.1) in the logs??
Firefox on the same device appears to resolve this correctly to the private IP (always works regardless of underlying network)…
Does the Android app cache the DNS result?? Maybe a bug?

Anyway thanks again!!

Ok so unfortunately that was short lived. After restarting the phone (connected to wifi before and after restarting) the Nextcloud app is again refusing to find my server, continually trying to locate it at 127.0.0.1 (as in the above log message)!

Any other ideas where the 127.0.0.1 is coming from?

A bit more detail about my home network/nextcloud server:
Incoming connections first hit an opnsense fw → reverse proxy in DMZ → nextcloud VM.
This is the same for external connections and internal (just the source network is different and external connections are NATed.) ie: nothing goes direct to the sever, it all hits the reverse proxy first.
As mentioned above I run my own DNS internally.
Say my NC server is upload.example.com then the internal DNS server will respond with an internal IP for this - say 10.0.1.100. This is the IP the app should get when connected via wifi.
When connecting externally, my public DNS will respond with my public IP - say 123.45.67.89, the request will then hit my FW, reverse proxy and eventually end up on the NC server.

As I said this all works perfectly (have never had any issues) with firefox (or any other web browser that is), connecting to the same URL: ie - https://upload.example.com.
This only seems to be an issue with the Nextcloud app, and only recently…

I’ll see if I can find an older version of the app and test again - not sure if anyone knows where old apk’s for nextcloud client would be?

Thanks again…

Either remove the internal DNS entry or set the external IP instead of the internal.

Ok so I did a bunch more testing…

Firstly I was wrong about an older version of the client working - which started pointing me away from any issue with the nextcloud client (btw old packages of nextcloud can be found on the fdroid archive repo if anyone needs these - https://f-droid.org/archive)

Looking over the logs in detail I noticed this just before what I pasted above:

05-29 23:25:23.270 17101 17101 D OperationsService: Starting command with id 1
05-29 23:25:23.273 17101 17213 D NetworkUtils: Searching known-servers store at /data/user/0/com.nextcloud.client/files/knownServers.bks
05-29 23:25:23.281 17101 17213 D OwnCloudClient #0: Creating OwnCloudClient
05-29 23:25:23.282 17101 17213 D OwnCloudClient: Proxy settings: localhost:-1
05-29 23:25:23.282 17101 17213 D AccountUtils: Restoring cookies for null
05-29 23:25:23.289 17101 17213 D OwnCloudClient #0: REQUEST GET /status.php

Specifically “Proxy settings: localhost:-1” was different between when it worked and when it didnt (mobile data vs. wifi)…
This makes some form of sense though as I have a proxy.pac file that I had been configuring (only recently) on my device for my home wifi.

Anyway changing the wifi’s proxy setting from “proxy auto-config (with my custom proxy.pac)” to “none” allows it to work again…

I still think there is a bug here though as this proxy pac file should not match anything to do with nextcloud (and works for everything else).
Anyway I’ll do a bit more testing to confirm…

PS: Thanks again for your suggestions guys, and hopefully this may help someone with a similar setup not bang their head against the wall for quite as long as I did!!

FYI: Raised Unable to connect via wifi if Proxy Auto-Config is set · Issue #10297 · nextcloud/android · GitHub