Häufige Fragen zu DynDNS, Healthchecks, CDN64 und Cloud Router

Kurze Antworten auf die Fragen, die am häufigsten gestellt werden: zu IPv64.net allgemein, zu DynDNS-Domains und Updates, zu Healthchecks, CDN64 und den Blocklisten, zum Cloud Router mit VPN und zu deinem Konto. Ausführliche Anleitungen findest du jeweils auf den verlinkten Seiten.

Allgemeines zu IPv64.net

Was ist IPv64.net?

IPv64.net ist ein DynDNS- und DNS-Dienst mit vollem IPv4- und IPv6-Support. Zu deinem Konto gehören außerdem:

• DynDNS mit 19 Domain-Endungen und eigenen Domains,
• Healthchecks online von mehreren Standorten oder lokal mit Node64, mit Benachrichtigung per E-Mail, SMS, App, Telegram, Discord, Slack, Teams, Matrix, ntfy, Gotify, Pushover oder Webhook,
• DNS Failover, das einen Record automatisch auf ein Ersatz-Ziel umschaltet,
• CDN64, das Dienste über Edge-Server in Deutschland ohne Portfreigabe veröffentlicht – mit Portmapper für TCP und UDP,
• Cloud Router als WireGuard-VPN-Gateway.

Was kostet IPv64.net?

Die Nutzung ist kostenlos. Für kostenlose Konten gelten aus technischen Gründen Limits, etwa bei der Anzahl der Domains und der DynDNS-Updates pro Tag. Bei normaler Nutzung erreichst du sie in der Regel nicht.

Wer mehr braucht oder das Projekt unterstützen möchte, wählt eine größere Kontoklasse: Home / Supporter (40 € / Jahr), Business (100 € / Jahr) oder Company (200 € / Jahr), jeweils inkl. MwSt. als Einmalzahlung für 365 Tage, kein Abo. Alle Limits im Vergleich stehen unter Pricing, Erklärungen unter Konto & Limits.

Wo sehe ich meine aktuellen Limits?

In der Karte Account Status, die auf den meisten Seiten rechts angezeigt wird. Dort stehen deine Kontoklasse, die Anzahl deiner Domains, die DynDNS-Updates der letzten 24 Stunden, Healthchecks, API-Aufrufe und SMS. Ein grünes Badge heißt: Es ist noch Luft. Ein rotes Badge heißt: Das Limit ist erreicht. Mehr unter Konto & Limits.

Meine Frage steht hier nicht. Wo bekomme ich Hilfe?

Frag die Community im v64.tech-Forum oder auf dem Community-Discord-Server. Für einzelne Router und Geräte gibt es den DynDNS Helper mit fertigen Update-URLs und die Anleitungen unter Router & Geräte.

DynDNS-Domains und DNS-Records

Welche Domain-Endungen gibt es für DynDNS?

Du kannst deine Subdomain unter 19 Domains anlegen: ipv64.net, ipv64.de, any64.de, api64.de, dns64.de, dyndns64.de, dynipv6.de, eth64.de, home64.de, iot64.de, lan64.de, nas64.de, root64.de, route64.de, srv64.de, tcp64.de, udp64.de, vpn64.de und wan64.de.

Wie erstelle ich eine DynDNS-Domain?

Nach der Registrierung legst du im Menü DynDNS deine Wunschdomain an. Sie ist sofort freigeschaltet und im Internet auflösbar. Danach trägst du die Update-URL der Domain in deinem Router oder Gerät ein. Schritt für Schritt: DynDNS-Domains und Router & Geräte.

Kann ich meine eigene Domain verwenden?

Ja. Du legst die Domain im Menü DynDNS als eigene Domain an und trägst bei deinem Domain-Anbieter die Nameserver von IPv64.net ein:

• ns1.ipv64.net
• ns2.ipv64.net

Danach verwaltest du alle Records der Domain bei IPv64.net und aktualisierst sie per DynDNS wie eine IPv64-Subdomain. Wie viele eigene Domains möglich sind, hängt von deiner Kontoklasse ab (Konto & Limits).

Welche DNS-Records kann ich anlegen?

Unterstützt werden A, AAAA, CNAME, MX, TXT, NS, SRV, TLSA und CAA.

• Ein CNAME kann nicht zusammen mit anderen Records auf demselben Präfix liegen. Liegt auf einem Präfix ein CNAME, wird ein DynDNS-Update für diesen Präfix abgelehnt.
• SRV und TLSA brauchen einen Präfix und vier durch Leerzeichen getrennte Werte, z. B. 10 5 5060 sip.example.com.
• CAA besteht aus drei Werten, z. B. 0 issue letsencrypt.org.
• Bei MX wird die Priorität 10 gesetzt, wenn du keine angibst.

Mehr unter DynDNS-Domains.

Kann ich eigene Präfixe (Subdomains) einrichten?

Ja, du kannst beliebige Präfixe als DNS-Records hinzufügen, z. B. nas.deinedomain.ipv64.net. Erlaubt sind Kleinbuchstaben, Ziffern, Punkt, Bindestrich und Unterstrich; Großbuchstaben werden automatisch klein geschrieben. Auch mehrstufige Präfixe wie a.b und Einträge wie _acme-challenge für Zertifikate von Let's Encrypt funktionieren.

Was bedeutet die Option Wildcard?

Die Option Wildcard ist bei neuen Domains standardmäßig aktiviert. Zu jedem A-, AAAA- und CNAME-Record wird dann automatisch ein passender Wildcard-Eintrag gesetzt, sodass auch alle darunterliegenden Namen aufgelöst werden.

Beispiel: Mit aktiver Wildcard zeigt neben deinedomain.ipv64.net auch irgendwas.deinedomain.ipv64.net auf deine IP-Adresse. Ohne die Option ist nur deinedomain.ipv64.net erreichbar.

Für DynDNS-Adressen ist das meist richtig. Brauchst du es nicht, schaltest du die Option in den Einstellungen der Domain ab und setzt bei Bedarf einzelne *-Records von Hand. Eine Änderung gilt sofort für alle bestehenden Records.

Wie schnell ist eine neue IP überall sichtbar?

Jeder Record hat eine TTL (Time to Live). So lange dürfen DNS-Resolver eine Antwort zwischenspeichern; erst danach fragen sie neu. Nach einem Update kann es also bis zur Länge der TTL dauern, bis alle die neue IP sehen. Die TTL deiner Records hängt von deiner Kontoklasse ab (Zeile „DynDNS TTL“ unter Pricing). Den aktuellen Stand prüfst du mit dem DNS Lookup.

DynDNS-Update und Router

Wie aktualisiere ich meine IP unter Linux automatisch?

Trage diese Zeile in die Crontab ein (Befehl crontab -e) und ersetze Key und Domain durch deine Werte:

0 */2 * * * curl -sSL "https://ipv64.net/nic/update?key=DEIN_DOMAIN_KEY&domain=deinedomain.ipv64.net"

Ohne weitere Angaben wird die Adresse eingetragen, von der der Aufruf kommt. Jeder Aufruf zählt auf dein tägliches Update-Limit, auch wenn sich die IP nicht geändert hat. Ein Intervall von einigen Minuten bis Stunden reicht völlig. Mehr unter Update-URL & Protokoll und Router & Geräte.

Welche Parameter versteht die Update-URL?

Der Updater ist unter https://ipv64.net/nic/update und https://ipv64.net/update.php erreichbar und spricht das verbreitete DynDNS2-Protokoll. Die wichtigsten Parameter:

Den Key kannst du auch per HTTP Basic Auth oder als Bearer-Token im Header senden. In myip dürfen IPv4 und IPv6 gemeinsam mit Komma getrennt stehen, die Reihenfolge ist egal – das brauchen z. B. die Speedport-Router der Telekom. Private Adressen wie 192.168.x.x werden nicht angenommen. Alle Details: Update-URL & Protokoll.

Account Update Token, Domain Token, Präfix Token: Was ist wofür?

Es gibt drei Update-Token mit unterschiedlicher Reichweite. Je kleiner die Reichweite, desto weniger kann passieren, wenn ein Token in falsche Hände gerät.

• Account Update Token: gilt für alle Domains in deinem Konto, ob IPv64-Domain oder eigene Domain.
• Domain Update Token: gilt nur für genau eine Domain mit all ihren Präfixen. Der Parameter domain kann dabei entfallen.
• Präfix / Record Update Token: gilt nur für einen einzelnen Präfix und ändert ausschließlich dessen A- und AAAA-Eintrag – praktisch, wenn jemand anderes nur diesen einen Eintrag ändern darf.

Empfehlung: Verwende in Routern und Geräten den Domain- oder Präfix-Token statt des Account-Tokens.

Was bedeuten die Antworten und Fehlercodes des Updaters?

Standardmäßig antwortet der Updater mit JSON. Mit &output=min kommt nur das einzelne Wort zurück; bei Fehlern außer badauth lautet es fail.

Mein Router meldet einen Fehler beim DynDNS-Update. Was kann ich tun?

Die Updater der Hersteller erwarten unterschiedliche Antworten: Der eine will eine ausführliche Antwort, der nächste nur ein einzelnes Wort. Probiere der Reihe nach:

1. Ausgabe minimieren: https://ipv64.net/nic/update?key=…&domain=…&output=min
2. IPv4 erzwingen: https://ipv4.ipv64.net/nic/update?key=…&domain=…
3. IPv6 erzwingen: https://ipv6.ipv64.net/nic/update?key=…&domain=…
4. Domain-Token nutzen statt des Account-Tokens, in besonderen Fällen den Präfix-Token.
5. Logs ansehen: Unter Logs siehst du, was bei IPv64.net angekommen ist.

Fertige URLs für viele Geräte stehen im DynDNS Helper und unter Router & Geräte.

Ich habe DS-Lite oder CGNAT. Was muss ich beachten?

Bei DS-Lite und CGNAT hast du keine eigene öffentliche IPv4-Adresse. Du teilst sie mit anderen Kunden deines Anbieters und bist darüber von außen nicht erreichbar.

Damit diese geteilte IPv4 gar nicht erst eingetragen wird, stellst du in den Einstellungen der Domain die Option Ignore IPv4 / A Records ein. Der Updater setzt dann nur noch den AAAA-Record. Umgekehrt gibt es Ignore IPv6 / AAAA Records. Brauchst du trotzdem Erreichbarkeit per IPv4, helfen der Cloud Router oder CDN64 mit Node64 – ganz ohne Portfreigabe.

Wie erreiche ich einzelne Geräte per IPv6, wenn sich mein Prefix ändert?

Bei IPv6 hat jedes Gerät eine eigene Adresse aus dem Prefix deines Anschlusses und einem festen Geräteteil. Ändert der Anbieter das Prefix, ändern sich alle Adressen.

Dafür speicherst du an der Domain das IPv6-Prefix und legst je Gerät einen AAAA-Record an, der nur den Geräteteil enthält und mit :: beginnt. Statt des Geräteteils kannst du auch die MAC-Adresse eintragen, sie wird automatisch umgerechnet.

Dein Router meldet das neue Prefix über den Parameter ipv6prefix, z. B. &ipv6prefix=2001:db8:1234:5600::/64 oder – über ipv6.ipv64.net – &ipv6prefix=auto. Alle Geräte-Records werden dann automatisch angepasst. Mit &onlyprefix wird nur das Prefix aktualisiert und kein A- oder AAAA-Record der Domain:

https://ipv6.ipv64.net/nic/update?key=DEIN_DOMAIN_KEY&ipv6prefix=auto&onlyprefix

Weitere Beispiel-URLs unter Update-URL & Protokoll, ein durchgerechnetes Beispiel unter DynDNS-Domains.

Kann ich DynDNS-Update und Healthcheck kombinieren?

Ja. Lege unter Healthchecks einen Push-Check an und hänge seinen Token mit &healthcheck=TOKEN an deine Update-URL. Bei jedem DynDNS-Update wird der Push-Check mit angepingt. So merkst du, wenn dein Router keine Updates mehr sendet. Wohin die Nachricht dann geht, stellst du unter Benachrichtigungen ein.

Was macht das DNS Failover?

Das DNS Failover verbindet einen Healthcheck (online, lokal oder hybrid) mit einem DNS-Record. Meldet der Healthcheck einen Ausfall, wird der Record automatisch auf ein Ersatz-Ziel umgestellt; ist das ursprüngliche Ziel wieder erreichbar, wird zurückgeschaltet. Solange ein Failover aktiv ist, lassen sich Monitore und Regeln der Policy nicht ändern. Anleitung: DNS Failover.

Healthchecks

Was können die Healthchecks von IPv64.net?

Sie überwachen Webseiten, APIs, Server, Ports, Zertifikate, DNS-Einträge, Domains (WHOIS/RDAP) und Cronjobs. Gemessen wird online von den Standorten Nürnberg und Falkenstein, lokal im Heimnetz mit Node64 oder beides zusammen. Fällt etwas aus, bekommst du eine Nachricht – per E-Mail, SMS, App, Chat-Dienst oder Webhook. Alle Check-Typen stehen unter Healthchecks.

Was ist der Unterschied zwischen online, lokal und hybrid?

Online misst IPv64.net von außen – so, wie deine Besucher den Dienst sehen. Lokal misst eine Node64 in deinem Netz, auch Ziele, die nur intern erreichbar sind. Hybrid macht beides; die Detailseite zeigt dann, ob ein Problem innen, außen oder beim Dienst selbst liegt. Mehr unter Ausführungsort.

Kann ich Geräte mit privater IP-Adresse überwachen?

Nicht online: IPv64.net erreicht dein Heimnetz nicht von außen und lehnt private Ziele wie 192.168.x.x, localhost oder .local-Namen für Online-Checks ab. Mit einer verknüpften Node64 misst du solche Ziele lokal – ohne Portfreigabe, und lokale Messungen zählen nicht gegen deine Limits.

Wie überwache ich einen Cronjob oder ein Backup?

Mit einem Push-Check: Du stellst den erwarteten Abstand ein (z. B. 86400 Sekunden für ein tägliches Backup) und rufst am Ende des Jobs die Push-URL https://ipv64.net/health.php?token=DEIN_PUSH_TOKEN auf. Bleibt der Aufruf aus, meldet IPv64.net eine Störung; mit &status=down meldest du einen Fehler selbst. Beispiele unter Push-Checks.

Was zählt gegen meine Healthcheck-Limits?

Nur Online-Messungen. Jeder Standort eines Online- oder Hybrid-Checks belegt eine Messstelle; dazu gibt es ein Tageskontingent an Online-Messungen und Pushes. Ist es erreicht, pausieren die Online-Checks bis Mitternacht und stehen auf „Kontingent aufgebraucht“; lokale Messungen laufen weiter. Das Formular rechnet den Verbrauch vorab aus. Details unter Limits.

Mein Check steht auf „Nicht überwacht“. Was heißt das?

Seit drei Intervallen (mindestens 5 Minuten) liefert keine Messstelle frische Daten – meist ist die einzige messende Node offline. Ob der Dienst erreichbar ist, weiß IPv64.net dann nicht. Prüfe die Node in der Node-Übersicht oder nimm zusätzlich einen IPv64-Standort dazu (hybrid).

Ich bekomme keine Benachrichtigung. Was kann ich prüfen?

• Gibt es überhaupt einen aktiven Kanal? Ohne Kanal gehen keine Nachrichten raus.
• Hat der Check eigene Kanäle gewählt? Sonst gelten nur die Standardkanäle.
• Ist ein E-Mail- oder SMS-Kanal noch „nicht bestätigt“?
• Sind am Check und am Kanal „bei Störung“ bzw. „bei Entwarnung“ eingeschaltet?
• Läuft gerade eine Ruhezeit oder ein Wartungsfenster, oder hängt der Check von einem gestörten Check ab?
• Was sagt das Zustellprotokoll? Ein Test mit dem Papierflieger-Knopf zeigt, ob der Kanal funktioniert.

Mehr unter Benachrichtigungen.

Wie vermeide ich zu viele Nachrichten?

Setze Wiederholungen vor Alarm, damit ein einzelner Aussetzer nicht meldet, und Abhängigkeiten, damit bei einem Ausfall des Routers nur er meldet. Viele gleichzeitige Störungen fasst IPv64.net zu einer Sammelmeldung zusammen, und in den Ruhezeiten kommt alles gesammelt danach – außer bei kritischen Checks. Siehe Ruhezeiten und Sammelmeldung.

CDN64

Was ist CDN64 und brauche ich dafür eine Portfreigabe?

CDN64 veröffentlicht deine Webseite oder deinen Dienst über vier Edge-Server von IPv64.net in Nürnberg und Falkenstein. Besucher verbinden sich mit diesen Servern, nicht mit deinem Anschluss. Mit Node64 (Modus 1 und 2) brauchst du keine Portfreigabe: Node64 baut den Tunnel von innen nach außen auf. Nur Modus 3 verbindet sich direkt mit einem öffentlich erreichbaren Ziel. Mehr unter CDN64.

Funktioniert CDN64 mit DS-Lite und CGNAT?

Ja, mit Node64 in Modus 1 oder 2. Der Tunnel ist eine ausgehende Verbindung (UDP oder TCP auf Port 7844 oder 443), die auch hinter DS-Lite, CGNAT und an Anschlüssen nur mit IPv6 funktioniert. Die Edge-Server sind per IPv4 und IPv6 erreichbar – Besucher kommen also auch per IPv4 zu deinem Dienst.

Welchen Modus soll ich nehmen?

Modus 1 reicht verschlüsselte Verbindungen nur durch; TLS endet erst in deiner Node (Ende-zu-Ende). Das ist der Standard. Modus 2 beendet TLS auf den Edge-Servern und kann so schon dort filtern. Modus 3 braucht kein Node64 und geht direkt zu deinem öffentlich erreichbaren Server, auf Wunsch mit Cache. Ein Vergleich steht unter Die drei Modi.

Muss ich einen CNAME oder andere DNS-Records eintragen?

Nein. Beim Einschalten stellt IPv64.net den Namen selbst um: Er bekommt A- und AAAA-Records der Edge-Server mit TTL 10 Sekunden, deine eigenen Records ruhen und kommen beim Ausschalten zurück. Der Name muss in einer Domain deines IPv64.net-Kontos liegen und darf keinen CNAME und kein aktives DNS Failover haben. Details: DNS und Zertifikate.

Läuft mein DynDNS-Update weiter, wenn ein Name in CDN64 ist?

Ja. Der Updater aktualisiert die ruhenden eigenen Records weiter, das öffentliche DNS zeigt aber auf die Edge-Server. In Modus 3 mit dem Ziel „A/AAAA-Records des Namens“ nutzen die Server so immer deine aktuelle IP. Antwortet der Updater bei einer Adressfamilie mit "cdn", hat der Name dafür nur den Record eines Edge-Servers (siehe Antworten).

Wie viele Namen und wie viel Traffic habe ich?

Das hängt von deiner Kontoklasse ab: Free hat 1 CDN-Domain und 10 GB Traffic im Monat, Home / Supporter 5 und 100 GB, Business 10 und 20 TB, Company 25 und 20 TB. Ist der Traffic aufgebraucht, sperrt IPv64.net deine Namen bis zum Monatswechsel oder bis zu einem Upgrade. Alle Werte stehen unter Kontingent und Traffic.

Wie schütze ich meinen Dienst bei einem Angriff?

Mit Pause auf ipv64.net/cdn64, in Node64 oder per API nehmen die Edge-Server für den Namen sofort nichts mehr an und trennen offene Verbindungen. Das DNS bleibt auf den Servern, deine eigene IP-Adresse bleibt also verborgen. Dauerhaft schränkst du den Zugang mit der Zugriffsliste des Namens, in Node64 zusätzlich mit Ländersperre und Blocklisten ein (siehe Schutz).

Ich habe Node64 gelöscht, ohne CDN64 auszuschalten. Was passiert?

Der Tunnel bleibt bei IPv64.net verwaist. Ab 48 Stunden ohne Verbindung zeigt ipv64.net/cdn64 einen Hinweis mit Datum. Nach 14 Tagen entfernt IPv64.net den Tunnel und seine Namen automatisch; das DNS zeigt dann wieder auf deine ursprünglichen Records. Willst du das vermeiden, starte Node64 wieder oder schalte die Namen auf ipv64.net/cdn64 selbst aus. Mehr unter Verwaiste Tunnel.

IP-Blocklisten

Kosten die Blocklisten etwas?

Nein. Alle Listen unter ipv64.net/v64_blocklists sind kostenlos und ohne Anmeldung abrufbar, auch die v64 Blocklist als Tagesstand. Nur den Live-Stand der v64 Blocklist (alle 30 Minuten) gibt es mit Listen-Token für Beitragende mit Honeypot64-Sensor und alle Kontoklassen außer Free; in Node64 holt PROXY64 das Token automatisch über deinen API-Key. Beachte die Lizenzen der Quellprojekte, z. B. CC BY-NC-SA bei DShield. Mehr unter Blocklisten.

Welche Liste soll ich nehmen?

Für den Anfang Spamhaus DROP (spamhaus_drop) oder FireHOL Level 1 (firehole_l1) – beide haben sehr wenige Fehlalarme. Für Server im Internet eignet sich all_notor (alle Angreifer-Listen ohne Tor) plus die v64 Blocklist. Eine Tabelle nach Einsatzzweck steht unter Welche Liste für wen?.

Was ist der Unterschied zwischen all und all_notor?

Beide fassen Spamhaus DROP, FireHOL Level 1, DShield, blocklist.de, ET Compromised und Feodo Tracker zusammen. all enthält zusätzlich die Tor-Listen und sperrt damit auch alle Tor-Nutzer; all_notor lässt Tor weg. Die v64 Blocklist, CINS, IPsum, DoH-, Cloud- und KI-Listen stecken in keiner der beiden.

Wie oft werden die Listen aktualisiert, wie oft darf ich sie abrufen?

Die Listen aus öffentlichen Quellen werden mehrmals täglich neu erzeugt, die Länderlisten täglich, die v64 Blocklist als Tagesstand einmal täglich und als Live-Stand alle 30 Minuten. Bitte ruf die Listen höchstens alle 30 Minuten ab; alle 1 bis 6 Stunden reicht. Details unter Aktualisierung und Fair Use.

Was ist die v64 Blocklist?

Die eigene Liste von IPv64.net. Sie entsteht aus den Meldungen der Honeypot64-Sensoren der Community: Eine Adresse kommt erst darauf, wenn Sensoren mehrerer unabhängiger Accounts sie gemeldet haben, und fällt ohne neue Angriffe nach 14 Tagen wieder heraus. Es gibt sie als eine Liste (v64), ohne Teillisten; Tagesstand und Live-Stand zeigt IPv64 Secure. Einen eigenen Sensor betreibst du mit Node64. Mehr unter v64 Blocklist.

Meine IP steht auf einer Liste. Was kann ich tun?

Für die v64 Blocklist zeigt die IP-Auskunft, warum die Adresse gelistet ist; dort stellst du auch einen Freigabe-Antrag. Greift die Adresse danach 24 Stunden lang keinen Sensor an, wird sie automatisch freigegeben und 30 Tage geschützt. Bei den anderen Listen wendest du dich an das jeweilige Quellprojekt (z. B. Spamhaus oder blocklist.de); mit der nächsten Aktualisierung verschwindet der Eintrag auch bei IPv64.net. Oft steckt ein befallenes Gerät im eigenen Netz oder eine geteilte Adresse (Mobilfunk, CGNAT, VPN) dahinter.

Wie binde ich eine Liste in meine Firewall ein?

Fast jede Firewall nimmt eine URL mit einer Adresse oder einem Netz je Zeile an, z. B. https://ipv64.net/blocklists/ipv64_blocklist_firehole_l1.txt. Schritt-für-Schritt-Anleitungen für nftables, iptables/ipset, pfSense, OPNsense, MikroTik, Palo Alto, FortiGate, Sophos, nginx, CrowdSec und Node64 stehen unter Blocklisten einbinden.

Soll ich die Listen auch für ausgehenden Verkehr nutzen?

Nur ausgewählte: Spamhaus DROP und Feodo Tracker auch ausgehend (Ziel = Liste), damit befallene Geräte ihre Steuerserver nicht erreichen; die DoH-Server-Liste nur ausgehend, damit Geräte deinen eigenen DNS-Filter nicht umgehen. Die übrigen Listen sind dafür gedacht, eingehende Verbindungen nach Absender zu sperren.

Cloud Router und VPN

Was ist der Cloud Router?

Ein virtueller Router in deutschen Rechenzentren mit eigener Routing-Tabelle und Firewall. Deine Geräte verbinden sich per WireGuard mit einem VPN Gateway darin. So machst du Dienste hinter DS-Lite oder CGNAT von außen erreichbar, verbindest Standorte oder nutzt ihn wie einen normalen VPN-Anbieter. Mehr unter Cloud Router.

Kostet der Cloud Router extra?

Nein, er gehört zu jeder Kontoklasse, auch zur kostenlosen. Anzahl der Router, Gateways und Peers, Bandbreite und Monats-Traffic hängen von der Kontoklasse ab (Pricing). Im kostenlosen Konto ist der Internetzugang über den Gateway eingeschränkt. Extra kosten nur eine eigene öffentliche IPv4 (6,99 € / Monat) und der Managed Cloud Router.

Bekomme ich eine eigene öffentliche IPv4?

Standardmäßig nutzt dein Cloud Router die IPv4 und IPv6 seines VPN-Servers, die sich mehrere Kunden teilen. Portfreigaben laufen dann über zufällig vergebene Ports. Eine eigene öffentliche IPv6 je Cloud Router legst du kostenlos selbst an; eine eigene IPv4 kostet 6,99 € / Monat (inkl. MwSt.) und wird per E-Mail an info@ipv64.net gebucht. Details: Öffentliche IPv4 und IPv6.

Wie gebe ich einen Port frei?

Mit dem Portmapper beim Gateway (Gateway Options → Portmapping): Ziel-IP im Tunnel, Port und Protokoll (TCP oder UDP) eintragen. IPv64.net vergibt einen zufälligen öffentlichen Port. Der Portmapper verbindet nur IPv4 mit IPv4 und IPv6 mit IPv6 und ist noch im Testbetrieb. Anleitung: Portfreigabe mit dem Portmapper.

Kann ich den Cloud Router als normales VPN nutzen?

Ja. Ein Client verbindet sich mit dem Gateway und geht darüber ins Internet – wie bei einem normalen VPN-Anbieter. Dazu stehen in der Konfiguration AllowedIPs = 0.0.0.0/0, ::/0. Siehe VPN Gateway.

Mein Peer verbindet sich nicht. Was kann ich prüfen?

• Zeigt die Peer-Liste einen Ladekreis, wird die Änderung noch übertragen – kurz warten.
• Rotes Netzwerk-Symbol: kein aktueller Handshake. Prüfe, ob der Tunnel auf dem Gerät aktiv ist, ob ausgehendes UDP zum Gateway-Port erlaubt ist und ob du die aktuelle Konfiguration (nach einem Schlüsselwechsel) verwendest.
• Hinter NAT oder CGNAT einen Keepalive setzen, z. B. 00:00:25.
• Warndreieck „IP missmatch Subnet“: Die Tunnel-Adresse liegt nicht im Netz des Gateways.

Mehr unter Fehlersuche.

Speichert IPv64.net meine Verbindungsdaten?

Ja. IPv64.net führt bewusst keine „No-Log-Policy“, sondern hält sich an die gesetzlichen Vorgaben: Verbindungsrelevante Daten werden unveränderbar gespeichert, bei Verdacht kann der Verkehr aufgezeichnet werden. Illegale Dienste sind verboten. Wer in deinem Gateway verbunden ist, siehst du selbst unter Show Connections.

Was ist der Unterschied zum Managed Cloud Router?

Der Managed Cloud Router kann dasselbe, läuft aber dediziert nur für dich – ohne geteilte CPU und Bandbreite, mit eigenen IPv4- und IPv6-Adressen inklusive PTR-Records und ohne Limits. Es gibt ihn als Cloud-Variante für 49,- € und als Hardware-Variante für 149,- € pro Monat. Siehe Managed Cloud Router.

Konto und Sicherheit

Kann ich mein Konto mit einem zweiten Faktor schützen?

Ja. Unter Settings und dort unter 2FA hinterlegst du eine Authenticator-App (TOTP, z. B. Google Authenticator) oder einen YubiKey. Beim Login wird der zweite Faktor dann zusätzlich zum Passwort abgefragt. Siehe Konto & Limits.

Kann mein IT-Dienstleister mein Konto mitverwalten?

Ja, ohne dass du dein Passwort weitergibst. Beide braucht ihr ein eigenes Konto bei IPv64.net.

1. Du trägst unter Settings in der Karte Share my Account die E-Mail-Adresse des anderen Kontos ein.
2. Das andere Konto bestätigt die Anfrage in seinen Settings unter Managed Accounts.
3. Danach kann es sich von dort mit einem Klick in dein Konto einloggen und wieder zurück in das eigene wechseln.

Der Zugriff erfolgt ohne dein Passwort und ohne deine 2FA – gib ihn also nur Personen, denen du vertraust. Während des Zugriffs wirst du selbst ausgeloggt. In deinen Settings siehst du, wann die Freigabe zuletzt benutzt wurde, und kannst sie jederzeit entfernen.

Gibt es eine API?

Ja. Den API-Key findest du unter API. Über die API verwaltest du unter anderem Domains und DNS-Records, z. B. für die DNS-Challenge von Let's Encrypt. Wie viele API-Aufrufe pro Tag möglich sind, hängt von deiner Kontoklasse ab. Alle Aufrufe beschreibt die Seite API.

Fehler gefunden oder etwas fehlt? Schreibt uns im v64.tech-Forum. · Stand: 2026-11-04