[NextBox] Guided dynDNS issue / https

Hello,
I’m trying to switch from connecting my NexBox via nextbox.link to connecting it via dedyn.io, mostly because the former way is really slow.
The first steps go fine : in the ‘Guided DNS configuration’, I created my .dedyn address successfully and then get a page that says:

HTTPS / TLS Configuration
Successfully resolved: [myservername].dedyn.io to: [myIP]
Failed resolving: [myservername].dedyn.io [IPv6] need: (…) found: null
Successfully tested reachability for: [myservername].dedyn.io
HTTPS / TLS is not activated
→ Enable HTTPS

From this, I understand (maybe wrongly) that my dedyn redirection is working well; also I checked sending and receiving mails on the NextBox’s Nextcloud.

Now, my router (Turris) is too complex for me to set up the DNS-Rebind (I thought it was not a catastrophy for now)

But that’s where things become interesting : when I click ‘Enable HTTPS’, after a while I get a message that says : 'failed to acquire [myserver]dedy.io with [the mail I declared for the admin user]'
while AT THE SAME TIME I am actually connected via https on the .nextbox.link instance (the page is https://[myservername].nextbox.link/apps/nextbox/#)

So there is something I don’t understand here. Why can I access in https through .nextbox.link and at the same time the interface tells me it doesn’t work?

I suspect this is related to the wrong rebinding, because when I try [myservername].dedyn.io I land on my router interface front-end, so it does not route the request to the NextBox…

But do I understand correctly that the https step ha gone OK, in spite of the negative message I get?

Ok, there are some things to unfold:

Generally, connecting via xxxx.nextbox.link has nothing to do with your own tls/dns-settings and connectivity. That’s the feature of the proxy that you can access your NextBox via a secure channel without having to configure the former.

This being said, your config status does not look too bad: “Successfully tested reachability for: [myservername].dedyn.io”

This should enable you to connect to your NextBox (in the browser) using the subdomain you set up: [myservername].dedyn.io, if this is not the case, make sure your have properly set port forwarding as described here: Port Forwarding & Firewall Configuration - Nitrokey Documentation

DNS-Rebind on the other side will just ensure that IPv6 is working to connect to your NextBox, this is required sometimes depending on your internet-service-provider. Namely, if you get a true dual-stack (IPv4 + IPv6) connection from your ISP, then you should not even need IPv6. But if you’re on a DS-Lite connection, you might need IPv6 to access your NextBox. (see DNS Rebind Protection - Nitrokey Documentation)

As mentioned before, the https used in abc.nextbox.link has nothing to do with the other. Here HTTPS is set up for your domain (as described in a previous post, TLS certificates are bound to a domain, means there is one for yourid.nextbox.link and in this step your NextBox tries to acquire one for [myservername].dedyn.io).

Nope, but this is good news, because this means things are working good, despite the fact that you did not set up your port forwarding inside your router, please do so (Port Forwarding & Firewall Configuration - Nitrokey Documentation) and afterwards navigate to [myservername].dedyn.io and you will end up on your Nextcloud instance, then you can acquire the TLS certificate and things will work…

Best

1 Like

Thank you @daringer for this superfast help!
Indeed I now added the right port forwarding here, and now .dedyn.io just works, and in https!
I’m just left with the IPV6 issue, but I have more time to solve that one, and definitely that’s caused by my improper router setup…
Definitely, this DNS connection is FAR faster than the one through nextbox.link, that’s very impressive -almost as fast as the .local way.
Thank you again for your patience and pedagogy!!
Hervé

1 Like

I am also having this same ipv6 error doing the guided dyndns. Mine still works without it but would be nice to get it working. I couldnt find any whitelist/exemption area on my Linksys EA8300 router eather to fix it.

If your remote access generally is working, you can safely ignore this error.