"Access Denied" when trying to backup over SSL using myfritz.net (dynamic DNS) address

Support
1

Good morning everyone,

until the beginning of September, my Duplicati setup worked like a charm for almost two years. But since then, I get an “Access Denied” error message when trying to backup, which unfortunately does not help me a lot. The details from Duplicati log are shown below. I hope that someone can help me to figure out a way to get it working again.

My setup is the following:
The destination: Backups shall be transferred to a Synology NAS on a remote location. The NAS is located behind a FritzBox router and a port forwarding rule is configured on the FritzBox to make the NAS’ SSH server available on port 4222. The FritzBox uses the myFritz-DynDNS-service to provide an always-available URL, because the actual IP addresses will change every few days.

The source: I’m running Duplicati 2.0.7.1_beta_2023-05-25 on an Ubuntu server 20.04. Duplicati uses sFTP / SSH to access the NAS. I configured the server address xxxExampleXXX.myfritz.net and port 4222, the correct path on the server, username and password. In addition, the ssh-fingerprint of the destination server is specified (and up to date). This configuration was not changed for years.

Now I found out the following:

  • By using ping on the Ubuntu servers terminal, I verified that the myfritz-URL resolves to the correct IP address - both IPv4 and IPv6 routes are available (ping -4 / ping -6) and responsive
  • I can successfully connect via ssh (on the Ubuntu servers terminal) to the SSH on xxxExampleXXX.myfritz.net with port 4222 and I see the (old) backup data on the destination path
  • Probably the most interesting: if I replace the myfritz-URL with the IPv4 address in the Duplicati configuration, Duplicati connects successfully and the backup runs through.

My next idea was to check if I can connect via SSH on the terminal if I just enter the IPv6 address - and this results in a Permission denied as well. So my conclusion is, the connection can not be established by IPv6 (probably due to the configuration of the FritzBox, which supports port forwarding only on IPv4), but Duplicati only tries v6 and does not fall back to IPv4. This still does not explain why it worked for so long until September - there have not been any updates to Duplicati or the FritzBox at that time. Only the Ubuntu server itself will have installed several updates, of course.

Does anyone have an idea about this issue? Or, as a workaround, is there any way to force Duplicati on IPv4 without specifying a (not static…) IPv4 address?

Thank you and best regards,
Holger

System.Net.Sockets.SocketException (0x80004005): Access denied
at Duplicati.Library.Main.BackendManager.List () [0x00049] in <9cab5b8f1b4f49ec980acae8e278968b>:0
at Duplicati.Library.Main.Operation.FilelistProcessor.RemoteListAnalysis (Duplicati.Library.Main.BackendManager backend, Duplicati.Library.Main.Options options, Duplicati.Library.Main.Database.LocalDatabase database, Duplicati.Library.Main.IBackendWriter log, System.Collections.Generic.IEnumerable1[T] protectedFiles) [0x0000d] in <9cab5b8f1b4f49ec980acae8e278968b>:0 at Duplicati.Library.Main.Operation.FilelistProcessor.VerifyRemoteList (Duplicati.Library.Main.BackendManager backend, Duplicati.Library.Main.Options options, Duplicati.Library.Main.Database.LocalDatabase database, Duplicati.Library.Main.IBackendWriter log, System.Collections.Generic.IEnumerable1[T] protectedFiles) [0x00000] in <9cab5b8f1b4f49ec980acae8e278968b>:0
at Duplicati.Library.Main.Operation.BackupHandler.PreBackupVerify (Duplicati.Library.Main.BackendManager backend, System.String protectedfile) [0x0005f] in <9cab5b8f1b4f49ec980acae8e278968b>:0
at Duplicati.Library.Main.Operation.BackupHandler.RunAsync (System.String sources, Duplicati.Library.Utility.IFilter filter, System.Threading.CancellationToken token) [0x01048] in <9cab5b8f1b4f49ec980acae8e278968b>:0
at CoCoL.ChannelExtensions.WaitForTaskOrThrow (System.Threading.Tasks.Task task) [0x00050] in <9a758ff4db6c48d6b3d4d0e5c2adf6d1>:0
at Duplicati.Library.Main.Operation.BackupHandler.Run (System.String sources, Duplicati.Library.Utility.IFilter filter, System.Threading.CancellationToken token) [0x00009] in <9cab5b8f1b4f49ec980acae8e278968b>:0
at Duplicati.Library.Main.Controller+<>c__DisplayClass14_0.b__0 (Duplicati.Library.Main.BackupResults result) [0x0004b] in <9cab5b8f1b4f49ec980acae8e278968b>:0
at Duplicati.Library.Main.Controller.RunAction[T] (T result, System.String& paths, Duplicati.Library.Utility.IFilter& filter, System.Action`1[T] method) [0x0026f] in <9cab5b8f1b4f49ec980acae8e278968b>:0
at Duplicati.Library.Main.Controller.Backup (System.String inputsources, Duplicati.Library.Utility.IFilter filter) [0x00074] in <9cab5b8f1b4f49ec980acae8e278968b>:0
at Duplicati.Server.Runner.Run (Duplicati.Server.Runner+IRunnerData data, System.Boolean fromQueue) [0x00349] in <30a34d71126b48248d040dda634ddad9>:0

2

I don’t know about setting up a C# application to only use IPV4 and I doubt there is a way.
There are (probably) ways of setting up a Linux application to not use IPV6 (using a DNS proxy such as dnsmasq to return only an IPV4 address for a given host is the first thing that comes to mind), but they are rather complicated and the easiest way by far would be to just remove the IPV6 address from the adapter. No IPV6, no route.

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
3

Was it always publishing an IPv6 address? Is there a way to stop it (or do you like it sometimes)?
Alternatively, maybe the ssh server got stricter somehow. You could check changelog and config.

It’s kind of ugly, but it’s better than hardcoding that address:

Example Scripts

SFTP/SSH

URL Format:
ssh://hostname/folder

run-script-before

Executes a script before performing an operation.

Example of a script using google.com as a stand-in for whatever the name would be in your case:

$ echo "--remoteurl=ssh://`dig google.com A +short | head -1`/folder"
--remoteurl=ssh://172.253.63.138/folder
1 Like
4

Thanks for your suggestion, but I would rather not disable IPv6 completely for my Ubuntu server, if there is another way.

5

Thank you, this looks like a really nice workaround!

I do still have one idea that I want to test first: it might be possible to have the Fritzbox router forward IPv6 requests to the NAS if I specify a subdomain for it - this would be the “cleanest” solution. I will let you know if this works in case someone else has a similar problem.