How to use deSEC with TrueNAS?

dynDNS at dedyn.io
1

After I came to deSEC via my NextBOX and was recently helped by the support with a problem so friendly, I would like to use my second domain at deSEC and come with the help of support or the community here to get a valid DDNS entry and certificate.
As a successor to my NextBOX I bought a TrueNAS Mini on which I want to run Nextcloud as a plugin.
The NextBOX made me the setup of deSEC service excellent easy and super prepared / explained.
With TrueNAS is unfortunately not so. There I have to know more myself.

The TrueNAS does not list deSEC service under Dynamic DNS at the moment. Only ddnss.de is known as a German service. However, there is the possibility to set up a “Custom Provider”.

Question:
Do you think it makes sense for you to support me (dedicated layman, no expert in certificates etc.) in setting up deSEC service and a certificate, or should I better register a domain at ddnss.de instead?

Below you can see a screenshot showing which entries should be made for a “Custom Provider”.

2022-11-28 - B
2022-11-28 - B971Ă—581 19.7 KB

1 Like
2

Hi Coffee,

welcome to deSEC! :slight_smile:

We have a guide on this: Configuring your dynDNS Client — deSEC DNS API documentation Please go check it out and let us know if it helped!

Best,
Nils

1 Like
3

I’m trying at the moment only to enter the IPv4 address, because I haven’t found anything about IPv6 in the Dynamic DNS Service implementation of my TrueNAS.

In the meantime I used

cat /var/log/messages | grep Dec

and found a first mistake I had made this afternoon. Now I tried the following setup

2022-12-04 - A
2022-12-04 - A983Ă—581 27.3 KB

and found the error message

Failed resolving hostname xxx.dedyn.io: Name does not resolve

in the messages

Dec  4 13:37:17 truenas-2022-11-18 1 2022-12-04T22:37:17.349450+01:00 truenas-2022-11-18.local inadyn 46810 - - In-a-dyn version 2.9.1 -- Dynamic DNS update client.
Dec  4 13:37:17 truenas-2022-11-18 1 2022-12-04T22:37:17.369899+01:00 truenas-2022-11-18.local inadyn 46810 - - Failed resolving hostname xxx.dedyn.io: Name does not resolve
Dec  4 13:37:17 truenas-2022-11-18 1 2022-12-04T22:37:17.893552+01:00 truenas-2022-11-18.local inadyn 46810 - - Update forced for alias xxx.dedyn.io, newIP# 46.82.###.###

I asked Peter if he could see something of my attempts today in his logs.

4

I don’t see any critical failures in the log entries you cited.

Initially it would be normal for the DNS resolution to fail, as the A record does not exist until you have successfully updated it. The last cited log entry seems to indicate that the update was triggered. Are there any further related messages after that entry?

Did you try to manually resolve the name? E.g. $ host xxx.dedyn.io or $ dig xxx.dedyn.io A (replace xxx with your subdomain of course). What is the result?

One more thing: Having DDNS work may not be sufficient for your NAS to be reachable from the Internet. If you are in a typical home setup then your router generally gets only a single public /32 IPv4 address. But in some situations it will not get any public IPv4 address, for example when using DS-Lite. This depends on your Internet provider. In the first case your router must be configured to forward traffic (for certain ports) to your NAS. In the second case you are out of luck for IPv4. You would need to use IPv6 then.

Does your router get a public IPv4 address from your provider? Please note that https://checkipv4.dedyn.io will probably show an IPv4 address in any case. But for incoming traffic this IP may not work in the DS-Lite case.

Another thing: If you are in the situation where your Router does get a single public IPv4 address then it may be much better to configure DDNS on the router than on the NAS. Your NAS would locally use a private IPv4 LAN address, e.g. 168.168.x.x and publicly use that same single public IPv4 address (NAT on the router). And your router would likely update DDNS automatically whenever that public IPv4 address changes, not every 5 min. like your NAS is currently trying to do. So that would be more efficient and faster.

fiwswe

5

Thank you for your answer and suggestions, @fiwswe :handshake:

Yes, I checked with nslookup and got a response without any IP address.
I use Telekom DSL - no DS-Lite involved.
All my other DDNS from my Synology Diskstations with other DDNS providers and my NextBOX with dedyn.io work nice.
NextBOX works nice with IPv4 and IPv6 through my Fritz!Box
I want to have a dedicated own DDNS for my TrueNAS because I intend to use IPv6 too.
As you might know, the IPv6 address is without NAT and delivers different IPv6 addresses for each end system “behind” my Fritz!Box.

6

Hmm, nslookup(1) only resolves IPv4 addresses. But I guess that is what you want at this point? If it does not return an IP then chances are the DDNS update failed. (Or your DNS setup is faulty but you can easily check that by trying to resolve some other host of which you know that it has a DNS A record.)

Yes but there are other issues to think about when running a server over IPv6 in such a setting:

  • Telekom provides dynamic public IPs, or more specifically two dynamic public IPv6 prefixes. One is a /64 prefix used by your FRITZ!Box for its own public IPv6 address. The other is a /56 prefix out of which the FRITZ!Box will pass on a /64 prefix to your LAN clients. Incoming traffic to IPs from this prefix are routed to the IPv6 address of your FRITZ!Box.
  • Your LAN clients will normally use SLAAC to choose their Interface Identifiers (IIDs) and most OSes will use the IPv6 privacy extensions to do so. (Note: Prefix + IID = IPv6 address.) These IPv6 addresses are great for outgoing traffic but their lifetime is very limited. At any given time there will be one such address used for new outgoing connections and possibly a number of older addresses that will expire soonish that are kept available for a while to avoid problems with older connections. For incoming traffic these are really not very suitable.
  • Your FRITZ!Box blocks incoming traffic by default. You can tell it to forward certain traffic, but you need to specify the IID of your client. And if SLAAC and privacy extensions are used, that IID will change frequently. So you need to reconfigure your host to use a static IID but in sich a way as to allow SLAAC to still react to changes in the dynamic prefix. The MAC address based EUI64 is one way of achieving this as there is a 1:1 correspondence between an EUI64 IID and the MAC address. And interface MAC addresses don’t change under normal conditions, giving you a static IID.
  • Next you need to make your service LISTEN on the current IPv6 address — even when that address changes. It may work to configure :: (all/any IPv6 addresses). Or you may need to react to changes of the IPv6 address and adjust the service configuration and restart the service. The later is somewhat complicated because there are probably no hooks to get notified when an IP changes in your OS. So you need to periodically check, figure out the current prefix, compare that to the last seen prefix and act if there is a change. (Don’t forget to filter out link local and ULA addresses though.)
  • While you are acting on the changed IPv6 prefix you may as well trigger the DDNS update from there. Just use e.g. curl to access the DDNS update URL (easy), or to access the deSEC API (slightly more complicated).

It can be done though :wink: I’m running such a setup using OpenBSD as the host OS. Otherwise very similar to your situation: Telekom DSL & FRITZ!Box. Whenever the IPv6 prefix changes my cron script notices the change and acts by updating DDNS, reconfiguring and restarting services and logging the change.

fiwswe

7

Hallo @peter ,

vielen Dank fĂĽr deine Antwort auf meine Frage, was du eventuell in euren Logs sehen kannst.

Ja. Die Update-Requests sehen aus wie folgt:

GET /?myipv4=%3cipaddr%3e<meineDomain>dedyn.io

Zum einen wird das also der <ipaddr> Platzhalter nicht korrekt ersetzt. Wie da die Syntax ist, hängt von der jeweiligen Update-Software ab.

Zum anderen ist dein Domainname einfach an die URL angehängt. Das ist nicht korrekt. Wenn deine Software das immer so macht, muss die URL vorher mit hostname= enden, sodass sich daraus in Kombination ein korrekter Query-Parameter ergibt (vgl. https://desec.readthedocs.io/en/latest/dyndns/update-api.html#determine-hostname).

Den Logs zufolge benutzt TrueNAS intern offenbar Inadyn. Die Platzhalter (insbesondere %i fĂĽr die IP) sind hier beschrieben: https://github.com/troglobit/inadyn/blob/master/README.md#custom-ddns-providers

Du könntest auch darum bitten, dass Support für dedyn.io von Haus aus eingebaut wird: https://github.com/troglobit/inadyn/issues

Das muss ich nochmal in Ruhe lesen, wenn mein Kopf freier ist als heute nach diesem wieder anstrengenden Tag. Ich werde mir überlegen müssen, wie ich weiter vorgehen möchte. Es wird dauern, bis ich meine Gedanken so weit sortiert haben werde, dass ich auch für das Thema mit dem richtigen Zertifikat einen gedanklichen Ansatz habe, mit dem ich mich nicht für unbestimmte Zeit blockiere…

Wenn ich einen Ansatz erkennen werde, dass und wie ich mit aus beiden Infos

Zum einen wird das also der <ipaddr> Platzhalter nicht korrekt ersetzt. Wie da die Syntax ist, hängt von der jeweiligen Update-Software ab.

und

Zum anderen ist dein Domainname einfach an die URL angehängt. Das ist nicht korrekt. Wenn deine Software das immer so macht, muss die URL vorher mit hostname= enden, sodass sich daraus in Kombination ein korrekter Query-Parameter ergibt (vgl. https://desec.readthedocs.io/en/latest/dyndns/update-api.html#determine-hostname).

irgendwelche Strings berechnen kann, die mit der in der TrueNAS vorhandenen Software doch die richtigen EInträge in eurer API abliefern … aber ich checks im Moment noch nicht …
Ich denke im Moment, dass fĂĽr

Zum einen wird das also der <ipaddr> Platzhalter nicht korrekt ersetzt.

wohl eher kein Workaround für mich möglich ist…

Was die Idee

Du könntest auch darum bitten, dass Support für dedyn.io von Haus aus eingebaut wird: https://github.com/troglobit/inadyn/issues

betrifft … eher werde ich mich erst mal an den Support des Hersteller der TrueNAS, iX systems, wenden …

8

Tut mir leid, ich hab im Moment nicht die Kraft, das gut nach Englisch zu übersetzen. Vielleicht hilft ja DeepL Translate – Der präziseste Übersetzer der Welt wenn jemand meinen deutschen Text übersetzen möchte.

9

I also wrote:

Den Logs zufolge benutzt TrueNAS intern offenbar Inadyn. Die Platzhalter (insbesondere %i für die IP) sind hier beschrieben: inadyn/README.md at master · troglobit/inadyn · GitHub

A string like /?myipv4=%i&hostname= or similar should thus work.

Stay secure,
Peter

1 Like
10

Dear @peter
thank you very much indeed :handshake: for your suggestion!

I think it just worked with that :smiley:
the nslookup now returns the expected IPv4 address
Can you please check your logs to see if everything looks good and correct there, or if there are any anomalies that I should still address

All the best,
Coffee

P.S.
As the core of the solution for configuring the “DynamicDNS” service of my TrueNAS Mini I note down
@nils ’ guide Configuring your dynDNS Client — deSEC DNS API documentation
plus that I have to use
@peter 's Custom Path string
/?myipv4=%i&hostname=

11

Inadyn now supports deSEC: Changeset 51329 – DD-WRT

It may be a while until TrueNAS integrates the new version.

Stay secure,
Peter

1 Like