Accessing nextcloud via ipv6 and client issues

Hi together,

About a year ago we have noticed, that our nextcloud cannot be accessed any more by the adroid client, when the smartphone was using a few specific, mostly small privat WIFI networks. A long error search brought us to the point, that this may be caused by the app trying to access via ipv6, but the host not responding on that channel. We are running the nextcloud using the DNS service inherent to our router (myfritz domain), so it is accessible from the web on some weird port (6971). I then tried accessing it directely by the external ipv- adresses, which worked just fine for the external ipv4 of our router using the port, but did not work for any of the external ipv6 adresses, neither the one of the router, nor the ones given to the server.

The nextcloud is using apache and mysql and is running in a normal (not docker) installation on ubuntu 20.04. What settings (server-side, in apache, and in the router) would i have to adapt, to get external access running.
My feeling so far was, that the ipv6 suffix used in the router was not the same then used in Ubuntu or anything apache was listening too, but i have to admit I a kinof wary when it comes to my experience with ipv6.

[/details]

Nextcloud version (eg, 20.0.5): 21.0.2
Operating system and version (eg, Ubuntu 20.04): Ubuntu 20.04
Apache or nginx version (eg, Apache 2.4.25): 2.4.41
PHP version (eg, 7.4): 7.4.3
Database: mysql/MariaDB 10.3.29

The issue you are facing:
Access problems using mobile clients, but only specific to a few networks. Access is no problem using normal mobile networks, university WIFI or similar, in most private WIFI networks the app states it is unable to reach the server.

Is this the first time you’ve seen this error? (Y/N): No, 100% reproducible within the last year.

Steps to replicate it:

  1. connect to WIFI
  2. open client, refresh → connection problem
  3. disconnect from WIFI to mobile network
  4. retry → no problem

The output of your Nextcloud log in Admin > Logging:
→ there is no output available, as the server is never reached by the client

The output of your Apache/nginx/system log in /var/log/____:
→ nothing related, as it does not respond to the external access tries

My experience is the same, it looks Android prefers IPv6 (and Win10 as well from ~2020)

In your Fritzbox you can configure port sharing for IPv4 and IPv6 separately. maybe you just didn’t share your NC system for IPv6?

It’s crucial - for IPv6 you can’t share specific IP address… So far I understand you can only tie the share to specific MAC address (directly connected to Fritzbox) by choosing the system from a drop-down menu. I’m using docker so maybe this limitation doesn’t apply to your system.

some references:

1 Like

Thanks a lot! It took me a while to get the configuration right, but I got it running now. And as a short manual should anyone ever have that problem as well: Fritzbox offers two kind of port-forwardings, the standard one, which basically only supports ipv4 and the “myfritz-freigabe”. This one actually creates an own myfritz-domain for the server [SERVERNAME.crypticlettercombination.myfritz.net] and is also routing ipv6 correctly. Next to that i also had to use netplan to set a static ipv6 token for my server (the server now takes the prefix from the router and always appends the same 64 bit ending), such that the router now knows, which ipv6 address to forward to and can also lift the firewall here. All in all myfritz-domains and ipv6 are not the most lovely couple, but it is possible.

1 Like

cool stuff… I don’t see “myfritz-freigabe” - can you describe in detail? the only way I managed to configure port sharing to internal device is to choose the device from drop-down list (works only for devices directly connected to Fritzbox).

image

and I’m interested in a way how you managed to create predictable IPv6 address? could you share your way or maybe a good guide?

So I have a FritzBox 7590, so the interface looks a little different. I first select the device, then click on “neue Portfreigabe” and then get this box:

grafik

where i can choose between the standard port forwarding and the myfritz-share. Taking the upper one and choosing “other” the port and protocol can be chosen and the respective port is forwarded as ipv4 and ipv6, this respective forwarding is then also shown in the myfritz web-interface:

and has a separate domain there. The predictable IPV6 address was then the more difficult part, what you have to reach is a state, where the server always uses the same “ipv6-suffix (64 bit)”, while accepting the pre-fix (also /64) given by the router. The suffix has to be entered as IPv6 interface ID as visible in your sharing monitor up there. Under Ubuntu 20.04 (should work for 18.04 and more recent) this can be done using netplan. It should be installed and used by the system by default and reads it’s config files from /etc/netplan/***.yaml
Here it will read every file in the folder ending by .yaml in alphabetic order and overwrite if things are in conflict. So i just created another .yaml file there with the following entry: (After a major war with the available options and a lot of trial and error)


	network:
	  version: 2
	  renderer: NetworkManager
	  ethernets:
	    eno1:
	      dhcp4: yes
	      dhcp6: yes
          ipv6-address-token: ::xxxx:xxxx:xxxx:xxxx

Instead of the xxxx, I simply used the current ipv6 of the system, as this was per definition free in the network, the name of the ethernet adapter can be found by “ifconfig”. This had the consequence, that the server was still accepting ipv6/ipv4 via dhcp, but creates an additional ipv6 address with the current public prefix of the router and then appends the defined token. The token option here seems to be the way to tell the server to always use the same ipv6 ending instead of creating a new one from time to time. This works for approx one week now without producing any problems.

Unfortunately there is no good guide I can share, I found this option only in the manual of netplan and was quite puzzled, that nobody seemed to ever have this problem…

1 Like