Since I am not a coder, I struggle to understand how the implementation of dynDNS for OPNsense is done.
Here is how I understand the structure
Records can be set by using curl. deSEC offers a https api for curl to use
to handle all the logic on what to curl, ddclient is used
ddclient has currently no native deSEC implementation
For OPNsense there are two implementations or forms
Since I am currently not that happy with the deSEC implementation in OPNsense, I wonder what is the best way forward.
A: Proposing a native implementation in ddclient and then adjust OPNsense
B: Change the current OPNsense implementation
C: Use the mode “custom” in OPNsense and create a wiki here on how to configure OPNsense
Again, I have no idea how these things work, but willing to learn and contribute.
In Services->Dynamic DNS->Settings configuration of OPNsense (I am using 24.1.3_1) there is a specific desec service you can use, named desec-v4, so you do not need to implement a custom configuration of your own at all.
You first need to create a Token via the desec control panel, since this is what you put in the Password field in the OPNsense configuration. The rest should be obvious I think.
The “problem” I had with the current OPNsense implementation is that it uses either desec-v4 or v6 to check if the IP changed, and then used the WAN IPs.
That would not work for me, since my NGINX reverse proxy has a different IPv6.
Since my IPv6 is static, I wanted to manually set the static IPv6 and have dyndns for my dynamic IPv4. But I was unable to only update my IPv4 without touching the fix IPv6, because I was unable to use the preserve option.
I solved this by switching to ddclient on the proxy itself.
But I still wonder if the implementation could be done in a smoother way. Simple stuff like not asking for username, have the field say token instead of password and so on. I get why Peter decided to use deletions, but I think the user could be warned about that. At the moment, the GUI is pretty generic standard and not a special one for deSEC.
I will also take a look at “custom get” to see if this would be even simpler.
Damn that was stupid! I thought that I have to use some special variables or URL methods to get dual stack working and not deleting either IPv4 or IPv6. But the funny thing is, I don’t have to do anything
I just ran some test for other sides and it works perfectly fine out of the box in OPNsense
I can use desec-v4, I can use Interface IPv4 or ip4only.me but it will still update both IPv4 and IPv6!
So my best guess is that the current ddclient implementation does not really use the check IP method and then use that variable to create a curl with that variable, but instead just uses update.dedyn.io.
So like the docs describe, in theory that would mean that the current OPNsense implementation could suffer a man in the mittel attack.
