Periodic update DDNS DuckDNS via cron in the Synology DSM

This is a problem that probably only I have, with my peculiar configuration. But anyway I will describe it here, as it can inspire similar solutions to similar problems.


The scenario is as follows: I had a network with two routers, the ASUS RT-AC86U and the Peplink-Balance One, both already described here in Skooter Blog. Why two? Because the Balance One It is excellent in load balancing, but bad in QoS, while RT-AC86UIt is great in QoS, but one has an implementation buguenta both load balancer, and with few resources. And what to make matters worse cancels the QoS to be used.

The double NAT can be a problem in many situations, but my applications has worked perfectly. Just make sure I use UPnP in the internal router (RT-AC86U) and put the second in a mode 1:1, also called Fullcone, where all ports are redirected, as a DMZ, and the gates of the output connections are not exchanged.

Who takes care of DDNS is Peplink-Balance One. Use accounts on DuckDNS, which is an excellent dynamic DNS. It is free and is not disturbing to validate periodically account, as No-IP. I leave a different hostname for each connection.

This worked well for many years, but recently I changed the Vivo Internet Fixed (ADSL) Fiber to the Living (optical fiber), and that my phone line also happened to come by fiber (in practice it is a VoIP) and installed an ONT that already does the router function and also takes care of the phone, which is accessed by a different VLAN, separate Internet connection.

Soon after the installation I've been the ONT (um Askey RTF3505VW-N1) to or mode bridge and the Peplink- He became the PPPoE connection. By switching to the mode bridge there is a warning: “Attention: Changing the operating mode to bridge will disable Internet services, telephony and TV. This also will make it impossible to receive support and updates with improvements.”, which I ignored.

And it worked well for a couple of months, but one day the phone caller ID crashed, without any configuration change. Contacted Vivo, but they could not fix remotely. They sent a technician who merely exchange the ONT by another of the same model, but with the default settings (way router). Said happened some changes in the VoIP network and changed the settings.

The fact is that with the ONT in router mode, Vivo can access it and configure it remotely. Even firmware updates are possible. Moreover, I realized that the new ONT came with an older firmware. It came with BR_SV_s00.00_g000_R3505VWN1001_s19, It is that the former had BR_SV_g000_R3505VWN1001_s26. I called in 10315 and asked for an upgrade and what they did was remotely put an even older version: BR_SV_s00.00_g000_R3505VWN1001_s15. I've tried every way to get the new firmware, but Vivo's little robots do not even know what that is. I've opened up a complaint with Anatel, but the clumsy made it a call that the Internet was not working and they sent technicians without warning. Ultimately, Vivo's support is a huge joke and only serves to lay users. There is no one there who really knows anything about how a network works. But that's a topic for another article.

Returning to the ONT. I just understood that to avoid having to call technicians every time someone in Vivo decides to change any settings, the way is to let the ONT as router same, keeping the “backdoor” Vivo to make configuration changes to reflect the changes you make in your network. I do not really like this external access do not know in whose hands may fall, but the disadvantage of relying on this type of service.

My setup ended up with a triple NAT, and hampered by the fact Vivo ONT does not support NAT Loopback, which prevents local access using the address of the DDNS. This is one of the reasons why I want the latest firmware, since the RTF3505VW-N1 supports this setting, but the Vivo firmware (at least the older) not have. Not even the standard interface (/pattern) with all options.

The triple NAT can also be circumvented by enabling NAT Fullcone option. A bonus of using RTF3505VW-N1 as a router is that it supports IPv6, what Peplink-Balance One today does. So I set up the other two routers to IPv6 passthrough and can I use IPv6 on my network.


But to pass the public IP and PPPoE for RTF3505VW-N1, the Peplink-Balance One does not know when the public IP changes. He even has an option to get the public IP when it receives a private IP, and so it updates the DDNS correctly. But, he is not able to detect when the public IP changes. He should have an option to get the public IP checking periodically, but it doesn't. Already asked for the appeal to the Peplink, but I have not yet met.

O RTF3505VW-N1 suporta DDNS, but only the DynDNS and No-IP, the services that are disturbing the free plan user and forcing a periodic reactivation. You can not use the excellent DuckDNS. The RTF3505VW-N1 terminal is not bash, It is only a limited shell with few options.

Then I thought of leaving this task to the Synology DS918+. Can you configure it DuckDNS, via interface. The problem here is that the method he uses to get the external IP almost always takes the second provider connection, that occasionally assigns a private IP, via CGNAT, that does not serve me for nothing. I needed to ensure that it always caught Vivo IP.

Force update DuckDNS without providing the IP would be a solution, because this update is done via HTTP or HTTPS, and when the IP is not provided it automatically detects the IP that made the connection. My Peplink-Balance One I made rules for TCP connections with destination port 80 or 443 (HTTP/HTTPS) always use Vivo fiber connection, preventing Netflix select the slower connection (15 Mbps vs 200 Mbps Fiber Vivo), it would not work well with videos in 4K. So updates would always come out via Vivo Fiber, unless this connection was unavailable.

But then there is another problem: Synology DSM internal mechanism only updates the IP when he notices a change and, as I mentioned, normally it will be monitoring the IP of the second connection, because the rule that let the default is to use the connection that answers first, and this tends to be the second provider, which although less bandwidth, It has an average latency of less than the fiber Vivo.


The way here was appeal to a solution via cron, that each 5 minutes call the update mechanism of DuckDNS. As the call is via HTTP or HTTPS, she always goes out the live connection Fiber, unless it is inactive.

Here are the steps to follow. First you need to open an SSH session as the DS918 +.

Within my home (~), I created a directory 'duckdns’ and I got it:

mkdir duckdns  
cd duckdns

Then, I created a script '', usando o nano. Recalling that the nano to be installed via community package in DSM. The saw is available natively, for those who may prefer:


Inside the script put the following statement (all on one line):

echo url="" | curl -k -o ~/duckdns/duck.log -K -

Replace DOMAIN TOKEN and the respective values ​​that can be obtained at DuckDNS.

I saved the script and let it executable:

chmod 700

I then tested the implementation of the '':


With the implementation creates a file 'duck.log'. Come Czech-lo:

cat duck.log

Inside it there must be an 'OK'. Se um for 'KO’ or another answer any error occurred.

Lack add the task in cron. We must first become root:

sudo -i

And edit the / etc / crontab:

nano /etc/crontab

And add this line to the end:

*/5 * * * seuusuario ~/duckdns/ >/dev/null 2>&1

You need to change 'myUser’ by your username.

Then save the file and restarts the daemon do cron:

synoservice -restart crond

And we can already leave the root:


If everything is working, a new duck.log is generated every 5 minutes.

0 0 votes
Article Rating

Permanent link to this article:

Sign up
Notify about
more new top rated
Inline Feedbacks
See all reviews

Opa! You can do port forwarding in RTF3505VW-N1? Need bridge?


Well then, Yesterday I spent the whole day looking at the matter of making this port forwarding unit. In the beginning, It seemed that nothing I did point in, the doors did not address whether the port that I forward. Stir in firewall, on the port forwarding and also on the virtual server / standard. Now a strange thing, even without any port forwarded on the device, many doors as answering external testing. Not tou with dmz or anything activated. Tou with full activated cone, but from what I understand this setting only has to do with doors as directed. I wonder what's going on?


It is the same Vivo, com o firmware BR_SV_s00.00_g000_R3505VWN1001_s19.

Routing with external source package was exactly what I wanted, I wanted to host some files to study. I find it strange routing to be working externally without my having sent no door and not activated dmz, nem nothing. on the device, the way as the configs, It was not for him to forward any port, i guess. But by referring ta, enough ports to. I have more than one device connected to the network.

If I put the RTF3505VW-N1 as a modem in bridge with another router I still need to log on to the other PPPoE router? I can not call directly on the PC and log the same 'cause I need wifi windows.

Obrigadão unanswered.


Yes, tava testing with Simple Port Tester in the way tcp. He gave up access to some sites I did with MS IIS. But it is possible my computer open a door via UPnP on the router without appearing configuration?


You might consider two changes to your code to disperse your requests so you don’t get 502 errors since all examples are firing at 5 minute intervals.

First, to CRON, change */5 to n-59/5 where n= 1 or 2 or 3 or 4 or 5, pick randomly. This will offset your interval by the value of “n” so you are not using the same minute as everyone else. Example, 3-59/5 will fire at 3, 8, 12, 17… as opposed to 5, 10, 15, 20 … like everyone else. This spreads everyone into 5 groups.

Second, add sleep $((RANDOM % 60)) to your before your CURL line pauas your DuckDNS call 0-60 second which will use to entire range seconds in the minute you pick for your CRON task to fire.

This means that all users will be spread out through 300 possible slots in a five minute interval and make a 502: Bad Gateway error far less likely.

We would like to know what you think, Leave your commentx