I’m using a dedyn.io address since some months to connect two Raspies for services like Adguard home und Bitwarden. Since last week I can’t connect to my services from outside.
I’ve figured out:
The Raspis are working fine and can be reached from my internal network. While I’m at home I can also reach them with the dedyn.io addresses!
When I’m in another network they can’t be reached anymore. I tried different ways:
Ping from my internal network to my dedyn.io address: Success (IPv4 services are reachable)
Ping from mobile network to my dedyn.io address: Success (IPv6 services aren’t reachable)
Ping from my network using a VPN: Request timed out (Zeitüberschreitung bei der Anforderung)
Ping from another network: TTL expired during transit) (Die Gültigkeitsdauer wurde bei der Anforderung überschritten). Tracert shows that the route loops inside Vodafone network and doesn’t reach the target.
I didn’t change things in my internal network and everything worked fine from begin so I’m quite sure, that the problem has to be outside my network. Can there be a routing problem or sth. like that?
Unless you suspect deSEC is at fault or you are having problems with your deSEC configuration this seems to be somewhat off-topic for this forum. But…
Does not prove much other than that something is responding to your pings. Whether that is your RasPi, your router or someone else`s device is open to debate. Ping does not test your service!
Huh? Success but services are not reachable? Explain please.
Without knowing more details this does not tell us anything.
But from these vague results I would suspect that the IPs configured in your dedyn.io A/AAAA records do not match your actual public IPs.
So, lacking details about your setup, my guess would be that your provider gave you new (dynamic) IPs and you failed to update them in your dedyn.io zone and/or in the forwarding rules of your router. So check the following:
What are your current public IPs as reported by your router?
Note: For IPv4 you could test e.g. by calling https://checkipv4.dedyn.io/. For IPv6 checking the corresponding https://checkipv6.dedyn.io/ may or may not be helpful depending on your setup due to SLAAC and IPv6 privacy extensions commonly used for IPv6 host configuration. The IPv6 address you might get is most likely not the one used by your service even if you test from the same host (your RasPi).
Also note that most providers will give your router a dynamic IPv6 address (/64) and for the hosts in your LAN you get a separate dynamic /56 prefix or something similar. Thus being able to ping the router IPv6 address does not get you your RasPi.
To which IPs do your dedyn.io DNS A/AAAA records point? Compare these to the IPs you determined above.
You did not specify but if you are trying to run a service on IPv6 using dynamic IPv6 addresses/prefixes, things get very complicated. It can be done (I’m doing it) but there is a lot of custom scripting involved to trigger updates of the DDNS record or even service reconfiguration when the host IP changes. I did this on OpenBSD. Doing it on Linux is probably possible but I have not tried.
If you want any further help then you will need to describe your setup in more detail.
The problem is that I don’t have a clue what has gone wrong because everything worked fine for months and I haven’t changed my setup. Of course I’ve updated the raspies (apt-get update/upgrade) but I didn’t notice anything strange there.
To clarify: Success (IPv4 services are reachable) → Not only the Ping successes: I can connect to the services (AdGuard Home and Bitwarden) using the dedyn.io address without any issues when I’m in my own network.
Success but services are not reachable? Explain please. → I can perform a ping to my dedyn.io address but I can’t reach my services (Bitwarden/Adguard Home). This could mean that there is some kind of problem with iPV6 configuration on my side. But again I didn’t change the settings of my router (FritzBox), didn’t change my ISP or didn’t change the network settings of the Raspis.
Could it be worth a try to disable IPv6 on the Raspies and change the update.dedyn.io to ipV4 only and delete the AAAA record?
This would be a good guess but I’ve double checked it. I’ve even disconnected the fibre optic modem to gain new IP addresses and the A/AAAA records in my dedyn.io account have been updated within seconds so I can’t find a misconfiguration there.
I will look through the advice you gave me and report back.
Like I wrote previously, hosting a service behind a dynamic IPv6 prefix is non-trivial.
Most routers have built-in DDNS clients but they will only update the IPv6 address of the router, not that of any LAN hosts which will use IPv6 addresses from the IPv6 prefix. So your host (in your case your RasPi) needs to detect the change of the prefix and update the DDNS AAAA record. You probably need to do this in a way that the router updates only the IPv4 address (without deleting the IPv6 record) and the host handles only the IPv6 address.
Standard IPv6 host configuration uses SLAAC and IPv6 privacy extensions on most OSes. Getting a non-temporary IPv6 address for your service requires special configuration of the interface. (E.g. EUI-64 IID.)
Your local host package filter/firewall (if active) or your service configuration may require an update when the IPv6 address changes. (YMMV)
Forwarding rules in your router need to adjust to the new IPv6 address. This depends on your router. E.g. for FRITZ!OS this is possible because the host is internally tracked using the MAC address/Interface Identifier (IID). This only works when the IPv6 IID of the address (the lower 64 bits) stay fixed, i.e. using an EUI-64 IID.
Note: Combining a manually generated IID with a dynamic IPv6 prefix was impossible on OpenBSD. I would expect similar results on Linux and other OSes.
So yes, if you can temporarily go back to IPv4-only that would be good way to reduce the number of potential issues.
Not sure how your fibre optic connection works but it is probably similar to a VDSL connection w.r.t. getting IPs. Sometimes the router software has a way to reconnect to get new dynamic IPs. But pulling the plug works as well
Again: Router IPv6 address ≠ RasPi IPv6 address. So make sure your AAAA record points to the RasPi not to the router. For IPv4 you don’t have this issue.
It’s LEW al local electricity supplier. They’ve been providing Internet for local business since years and recently started to provide smaller villages with FTTH. They wrote me that for technical reasons they can’t provide Dualstack anymore. I wrote them back that I need IPv4 for technical reasons. No they wrote, that I’ll be back on Dualstack until tomorrow