Abuse warning on update: ddns or tunnel?

My ISP requires a forced daily disconnection, only choice I have is the time of day so every night at 4am UTC I issue a "ifup wan":

Mon Jun 12 04:00:05 2023 daemon.notice netifd: tunnel '6in4-he_2_fra' link is up
Mon Jun 12 04:00:10 2023 user.notice 6in4-he_2_fra: update 1/3: timeout
Mon Jun 12 04:00:17 2023 user.notice 6in4-he_2_fra: update 2/3: abuse
Mon Jun 12 04:00:17 2023 user.notice 6in4-he_2_fra: updated
Mon Jun 12 04:00:20 2023 user.notice firewall: Reloading firewall due to ifup of he_2_fra (6in4-he_2_fra)
Mon Jun 12 04:00:22 2023 user.notice nlbwmon: Reloading nlbwmon due to ifup of he_2_fra (6in4-he_2_fra)
Tue Jun 13 04:00:00 2023 daemon.notice netifd: Interface 'he_2_fra' has lost the connection
Tue Jun 13 04:00:00 2023 daemon.notice netifd: tunnel '6in4-he_2_fra' link is down
Tue Jun 13 04:00:00 2023 daemon.notice netifd: Interface 'he_2_fra' is now down
Tue Jun 13 04:00:00 2023 daemon.notice netifd: Interface 'he_2_fra' is setting up now
Tue Jun 13 04:00:00 2023 daemon.notice netifd: Interface 'he_2_fra' is now down
Tue Jun 13 04:00:00 2023 daemon.notice netifd: Interface 'he_2_fra' is setting up now
Tue Jun 13 04:00:00 2023 daemon.notice netifd: Interface 'he_2_fra' is now down
Tue Jun 13 04:00:04 2023 daemon.notice netifd: Interface 'he_2_fra' is setting up now
Tue Jun 13 04:00:04 2023 daemon.notice netifd: Interface 'he_2_fra' is now up
Tue Jun 13 04:00:04 2023 daemon.notice netifd: tunnel '6in4-he_2_fra' link is up
Tue Jun 13 04:00:09 2023 user.notice 6in4-he_2_fra: update 1/3: Failed to send request: Operation not permitted
Tue Jun 13 04:00:19 2023 user.notice 6in4-he_2_fra: update 2/3: timeout
Tue Jun 13 04:00:19 2023 user.notice firewall: Reloading firewall due to ifup of he_2_fra (6in4-he_2_fra)
Tue Jun 13 04:00:21 2023 user.notice nlbwmon: Reloading nlbwmon due to ifup of he_2_fra (6in4-he_2_fra)
Tue Jun 13 04:00:26 2023 user.notice 6in4-he_2_fra: update 3/3: abuse
Tue Jun 13 04:00:26 2023 user.notice 6in4-he_2_fra: updated
Wed Jun 14 04:00:00 2023 daemon.notice netifd: Interface 'he_2_fra' has lost the connection
Wed Jun 14 04:00:00 2023 daemon.notice netifd: tunnel '6in4-he_2_fra' link is down
Wed Jun 14 04:00:00 2023 daemon.notice netifd: Interface 'he_2_fra' is now down
Wed Jun 14 04:00:00 2023 daemon.notice netifd: Interface 'he_2_fra' is setting up now
Wed Jun 14 04:00:00 2023 daemon.notice netifd: Interface 'he_2_fra' is now down
Wed Jun 14 04:00:00 2023 daemon.notice netifd: Interface 'he_2_fra' is setting up now
Wed Jun 14 04:00:01 2023 daemon.notice netifd: Interface 'he_2_fra' is now down
Wed Jun 14 04:00:04 2023 daemon.notice netifd: Interface 'he_2_fra' is setting up now
Wed Jun 14 04:00:04 2023 daemon.notice netifd: Interface 'he_2_fra' is now up
Wed Jun 14 04:00:04 2023 daemon.notice netifd: tunnel '6in4-he_2_fra' link is up
Wed Jun 14 04:00:09 2023 user.notice 6in4-he_2_fra: update 1/3: Failed to send request: Operation not permitted
Wed Jun 14 04:00:19 2023 user.notice 6in4-he_2_fra: update 2/3: timeout
Wed Jun 14 04:00:20 2023 user.notice firewall: Reloading firewall due to ifup of he_2_fra (6in4-he_2_fra)
Wed Jun 14 04:00:21 2023 user.notice nlbwmon: Reloading nlbwmon due to ifup of he_2_fra (6in4-he_2_fra)
Wed Jun 14 04:00:26 2023 user.notice 6in4-he_2_fra: update 3/3: abuse
Wed Jun 14 04:00:26 2023 user.notice 6in4-he_2_fra: updated

By chance I noticed that the update process for the he.net IPV6 tunnel is reporting an "abuse" warning, every time and sometimes already at the second try. I am quite baffled: the IPV4 address is definitely changing from one day to the other (I checked the logs) and no update takes place for the IPV6 address since I have a static /48.

How do I find out what is really going on here?

You still need to notify HE to update the tunnel endpoint with the new address from your side. Most likely this update is not as fast as you'd thought it is. But let's have a look at the configuration, while we're at it.

Where is the problematic ddns?

So it might be running twice, once on its own and once through the he.net script?
I am using DuckDNS (longtime supporter), here is /etc/config/ddns:

config ddns 'global'
        option ddns_dateformat '%F %R'
        option ddns_loglines '250'
        option ddns_rundir '/var/run/ddns'
        option ddns_logdir '/var/log/ddns'

config service 'duckdns_v4'
        option service_name 'duckdns.org'
        option enabled '1'
        option lookup_host 'XXX.duckdns.org'
        option password 'YYY'
        option use_https '1'
        option domain 'XXX.duckdns.org'
        option retry_count '10'

config service 'duckdns_v6'
        option use_ipv6 '1'
        option service_name 'duckdns.org'
        option enabled '0'
        option lookup_host 'XXX.duckdns.org'
        option password 'YYY'
        option use_https '1'
        option domain 'XXX.duckdns.org'
        option ip_network 'he_2_fra'
        option retry_count '10'

How is it updating IPv6 when it is disabled?
Are you sure it is not trying to update v4 via v6 interface accidentally?
Can you lock it to v4 only?

Since henet doesn't change the IPs, there is no need to have ddns for v6.

It is not updating IPV6 and it shouldn't be: I have a /48 and the addresses are static.
What should be updated is the IPV4-endpoint for the tunnel.
I might as well completely remove the config, I left it there but disabled to preserve history.

Locking means adding
option use_ipv6 '0'
under 'duckdns_v4", right?

First of all the interface must be required per documentation, but it is missing from your config.
Second:

whatever is abusing is not connected to the wan but to the henet interface. So are you certain that what abuses is the ddns or the dynamic update of your endpoint for the 6in4 tunnel?

Thanks for catching that! I checked the backups of my config and it has always been that way, at least for the last 4 years. Of course I am not sure what is causing the problem, that's the whole point of asking here :smiley:

Now the duckdns_v4 service has two additional keywords:

option interface 'wan'
option use_ipv6 '0'

and the duckdns_v6 (still disabled) has one:
option interface 'he_2_fra'

Toggled WAN, waited for DNS update to propagate (I am on holiday) and reconnected: "abuse" message is still there.

You probably don't understand what we're asking.
Isn't that 'abuse' related only to the 6in4 tunnel and has nothing to do with ddns?

1 Like

It might as well be the case, though I still have no idea what kind of abuse it might be. Changing the title now.
Searching the he.net forums now, I see that abuse goes together with blocked updates... and I can connect just fine over IPV6, so I'm puzzled.

Although it has become rather obvious it's the henet endpoint update producing the log, you can easily verify that by disabling ddns and doing the ifup wan :slight_smile:
As for what to do with that, maybe henet has a better explanation so it's worth asking in their forums.

Ok, back home, ran the test and indeed the message is unchanged; thanks for pointing me in the right direction, @trendy !

Anyway, I posted the question in their forum, let's wait and see what comes up :slight_smile:

1 Like

Back in the day, I made good experiences with a crontab tearing down the connection volutarily:

0 5 * * * [ $(ifstatus wan | jsonfilter -e '@.uptime') -lt 3650 ] || (ubus call network.interface.henet down;ubus call network.interface.wan down;sleep 1;ubus call network.interface.wan up;sleep 15;ubus call network.interface.henet up)

(this can be simplified and most of the sleeps are probably not necessary either).

Perhaps you should try dyn.dns.he.net as a DDNS service.

That's what I am doing too, basically: early morning the connection gets restarted, always at the same time.
0 4 * * * /sbin/ifup wan

Other niceties (restart vpn) are handled via hotplug-extras.

Other than this funny "abuse" warning this setup has been running stable for the past few months.

Why? Thanks to @trendy the DNS has been ruled out as source of the warning, so it is unclear to me what I could gain from it.

Ok, basically the he.net forum was not terribly useful and got nowhere. I'm dropping the issue since the tunnel otherwise works and the original question is answered

2 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.