CDN64: publish services without port forwarding – the Cloudflare alternative

CDN64 makes your website or service reachable from the internet via four IPv64.net edge servers in Germany – over IPv4 and IPv6, even behind DS-Lite and CGNAT and without port forwarding on your router. This page explains how CDN64 works, which modes exist and how to set up names, access lists and port mappings.

What is CDN64 and when do you need it?

CDN64 is the reverse proxy and tunnel service of IPv64.net. Visitors do not connect to your internet connection but to the IPv64.net edge servers: srv07.cdn64.de and srv10.cdn64.de in Nuremberg as well as srv08.cdn64.de and srv09.cdn64.de in Falkenstein. The servers pass the connection on to your service – either through a tunnel that Node64 opens from your home network, or directly to a publicly reachable target. The server overview shows whether the servers are online.

CDN64 helps above all in these cases:

• DS-Lite or CGNAT: you have no public IPv4 address of your own and cannot forward ports. With the Node64 tunnel, visitors still reach your service – over IPv4 too.
• No port forwarding wanted: the tunnel is opened from the inside out. Every port on your router stays closed and your own IP address stays hidden.
• IPv4-only or IPv6-only connection: the edge servers are reachable over both protocols.
• Protection in front of your connection: access lists, pause during attacks, per-IP limits, WAF patterns and detection of attack tools already apply on the edge servers.

In your home network, the local reverse proxy of Node64 is called PROXY64; CDN64 is the server part at IPv64.net. You manage CDN64 at ipv64.net/cdn64, in Node64 and via the CDN64 API. Without logging in, ipv64.net/cdn64 shows an overview with the three modes.

How CDN64 works

A name you switch on in CDN64 (e.g. cloud.deinedomain.ipv64.net) points to its edge servers in DNS – your account class decides how many (see servers per name). A visitor lands on one of the servers. The server recognises from the name where the connection belongs and passes it on.

 Visitor (IPv4/IPv6)
        │  DNS: A/AAAA of your account's edge servers (TTL 10 s)
        ▼
 ┌──────────────────────┐     ┌──────────────────────┐
 │ Edge server          │     │ Edge server          │
 │ Nuremberg (2×)       │     │ Falkenstein (2×)     │
 └──────────▲───────────┘     └──────────▲───────────┘
            ║ tunnel (mode 1/2)          ║ tunnel (mode 1/2)
            ║ opened by Node64           ║
 ┌──────────╨────────────────────────────╨───────────┐
 │ Node64 in your home network – router: no open port│
 └───────────────────────────────────────────────────┘
 Mode 3: the servers connect directly to your publicly
 reachable server, without a tunnel.

The Node64 tunnel

In modes 1 and 2, Node64 opens an outgoing tunnel to each edge server of your account (QUIC over UDP, port 7844 or 443; if UDP is blocked, TLS over TCP). For your router this is a normal outgoing connection. Each tunnel logs in with its own token. Technical details – ports, fallback to TCP, keepalive – are explained in the Node64 docs under CDN64 – tunnel without port forwarding.

Load balancing and failover

• Several servers via DNS: DNS returns the addresses of your account's edge servers. From two servers on, one is in Nuremberg and one in Falkenstein; visitors are spread across them automatically.
• A server fails: if an edge server does not report to IPv64.net for 45 seconds and does not answer a direct check either, IPv64.net removes its addresses from DNS – as long as another server is reachable. Until then the other servers of your account carry the load. If it stays away for more than 3 minutes (so not just a restart), another server stands in for the accounts it is assigned to, preferably at the same location: DNS gets that server's addresses, and Node64 additionally connects to it within a minute – without interrupting the connections to the other servers. If your account has only one server (Free), the name is unreachable until then. Once the server is back for 30 seconds, the previous assignment applies again. A failover is visible on ipv64.net/cdn64 (yellow “failover” badge at the name, note at the tunnel), in Node64 (PROXY64 dashboard card and badge “srv08 → srv09” in the CDN64 column), in the node's log and in the events of the names.
• Parallel connections: depending on your account class, Node64 opens several parallel tunnel connections to each server (Business up to 2, Company up to 4, your choice per name; see servers per name). The servers hand new visitors to the least loaded connection.
• Several tunnels for one name: a name can be assigned to several tunnels (i.e. several Node64 instances). The order is the priority: the first tunnel that is currently connected serves the name. This is a fallback, not load balancing between nodes. You set the list via the API (field tunnels).

Servers per name

Not every name uses all edge servers. Your account class decides how many: Free 1, Home / Supporter 2, Business 1 or 2 (your choice), Company 1 to all (your choice; the list grows with the number of servers, “all” includes future servers). In addition, Business (1–2) and Company (1–4) choose the connections per server, e.g. 1 server with 1 connection or 3 servers with 2 connections each. Free (1 server, 1 connection) and Supporter (2 servers, 1 connection each) are fixed. The values apply per name (in Node64 per proxy host for all its names), e.g. name A with 1 server and 1 connection, name B with 4 servers and 4 connections each; in mode 3 only the number of servers. The DNS of a name lists only its servers. The tunnel of a node connects to the servers of all its names, per server with the highest number of connections of the names there; the names share the connections of a server.

• Assignment: IPv64.net assigns the servers automatically – one per location first, then servers other names of the same node already use (fewer connections), otherwise the one with the fewest assignments. The assignment stays fixed until the number changes. Node64 shows the servers a proxy host currently uses in its row in the CDN64 column.
• Choosing servers and connections (Business, Company): in Node64 under PROXY64 → Proxy hosts in the CDN64 column (button with the number of servers in the row of the proxy host) or via the API, per name. IPv64.net then updates the DNS of the name; Node64 connects to the new servers within a minute, connections to the remaining ones keep running.
• Several tunnels for one name: all tunnels of the name connect to its servers so a backup can take over.
• Class changed: the new number applies within a few minutes; the name keeps the servers assigned first.
• Old DNS answer at the visitor: if a visitor still reaches a server the name no longer uses, that server passes them on to a server with your tunnel.
• Load balancing (emergency brake): if an edge server stays above 70 % of its capacity for 15 minutes and another one is below 40 %, IPv64.net moves one name (mode 1/2) with noticeable traffic there – at most one per quarter of an hour, never during a server failure and never for Company with “all”. The new server is added first; the old one is dropped only when your tunnel is up on the new one, so there is no outage. A moved name then stays on its servers for 24 hours. The move shows in the events of the names (“Lastausgleich: srv08 → srv10”) and in the Node64 log.

The three modes

The mode decides where encryption (TLS) ends and how the edge servers reach your target.

Mode 1: pass-through (end-to-end)

The edge servers only read the name from the connection setup (SNI; for HTTP on port 80 the Host header) and pass the connection without decrypting it through the tunnel to Node64. TLS ends in your node, certificate and key stay with you. With HTTPS the servers see no content, paths or cookies. They also pass HTTP/3 (QUIC) through raw. This is the default and the right choice in almost all cases.

Mode 2: terminate TLS on the edge servers

The edge servers terminate TLS themselves (HTTP/1.1, HTTP/2 and HTTP/3) and send each request with the real visitor IP through the tunnel to Node64. This lets them filter before your connection: request limits per IP (above them 429) and the check whether the Host header matches the SNI (otherwise 421). Port 80 redirects to HTTPS with 301. The servers obtain the certificate themselves (see certificates); until it is there, they pass through as in mode 1.

Mode 3: direct to the target, without Node64

Mode 3 has no tunnel. The edge servers connect directly to your target – like a classic reverse proxy. The target must be publicly reachable. You set up mode 3 at ipv64.net/cdn64 or via the API:

• Target: either the current A/AAAA records of the name (your DynDNS updater keeps them up to date, see DNS) or a fixed target – a public IP address or a host name. Private, CGNAT, documentation and other non-public addresses are not allowed.
• Backend: HTTPS (default, port 443) or HTTP (port 80), any port. Optionally the servers verify the target's certificate („Verify the target's certificate“, off by default). „Prefer IPv6“ (on by default) connects over IPv6 first.
• Frontend: level 0 = no website, port mappings only; level 1 = HTTP (port 80) only; level 2 = HTTPS, port 80 redirects to HTTPS (default); level 3 = HTTPS (port 443) only.
• Cache: optionally the servers cache responses – up to the cache size of your account class per name. Only what the target itself marks as cacheable is stored (Cache-Control: max-age/s-maxage or Expires, without private, no-store, no-cache and without Set-Cookie), only GET/HEAD without authentication and at most 8 MB per object. The response header X-Proxy-Cache shows HIT or MISS.
• More: WebSockets work automatically. The visitor's IP arrives in the header X-Forwarded-For or X-Real-IP. The servers compress text responses themselves if the target does not.

You can switch between mode 1 and 2 at any time; DNS stays the same. Switching between mode 3 and the tunnel modes is not possible directly: switch the name off and on again with the other mode.

Which mode fits?

• Mode 1 if you use Node64 and want maximum confidentiality – your certificate, your rules.
• Mode 2 if unwanted traffic should be slowed down before your connection (e.g. with a small upload) or the edge servers should take care of the certificate.
• Mode 3 if your server is already publicly reachable and you want a reverse proxy with cache in front of it – without Node64.

What IPv64.net can see in modes 1 and 2 is compared in the Node64 docs under What does ipv64 see?.

Requirements and adding names

Requirements

• An account class with CDN domains. Without CDN domains in the class, IPv64.net rejects the request (see quota).
• The name belongs to a domain of your account – a DynDNS domain or your own domain managed at IPv64.net. The domain itself and every name below it are allowed, e.g. deinedomain.ipv64.net or www.deinedomain.ipv64.net. Deactivated domains do not count.
• The name has no CNAME and no active DNS failover.
• For modes 1 and 2: Node64 with the PROXY64 module, linked to your IPv64.net account (see Link Node64). Outgoing UDP or TCP on port 7844 or 443 must be allowed.
• For mode 3: a publicly reachable target (public IP address or host name). If you use the name's A/AAAA records as target, at least one of them must contain a public address.

Switch on modes 1 and 2 in Node64

1. Create a proxy host
   In Node64 under PROXY64 → Proxy hosts, create a host for the name that points to your service in the home network.
2. Switch on CDN64
   In the CDN64 column click Switch on and choose mode 1 or 2. Node64 registers the tunnel at IPv64.net, opens it and switches on every name of the host.
3. Wait for the self-test
   Node64 checks every name via all servers of your account and both address families. After that the service is reachable via CDN64.

The steps in detail are under One-click setup in the Node64 docs. At ipv64.net/cdn64 these names are shown with the note Node64: target, mode, certificate and access lists are managed in Node64; in the portal you can pause and switch them off.

Switch on mode 3 at ipv64.net/cdn64

1. Open the page
   At ipv64.net/cdn64, find the card Add a name (mode 3, direct to target).
2. Enter the name
   Under Name, enter a domain of your account or a name below it.
3. Set the target
   Under Target, choose the name's A/AAAA records or a fixed target, plus backend (HTTPS/HTTP), port, frontend level and optionally cache.
4. Switch on
   With Switch on, IPv64.net changes the DNS. The servers fetch a certificate (about a minute), then the name is reachable via HTTPS.

With the pen icon in the list Names in CDN64 you later change target, access list and port mappings. All settings are also available via the API.

Switching off

With the power icon (Switch off) at ipv64.net/cdn64, with Switch off in Node64 or via the API you switch a name off. DNS then points to your previous addresses again; target, access list, port mappings and certificate of the name are removed. If you switch off a mode 1 or 2 name in the portal, Node64 follows. If you only want to block the service briefly without revealing your address, use pause instead.

Orphaned tunnels: Node64 deleted without signing off

If you delete a Node64 container without switching its names off first, its tunnel stays orphaned at IPv64.net (modes 1 and 2 only). Then:

• After 48 hours without connection, ipv64.net/cdn64 shows a notice with the date of the clean-up. There is no e-mail or notification.
• After 14 days without connection (a tunnel that never connected counts from its creation), IPv64.net removes the tunnel with its token and its names: DNS returns to your original records; target, access list, port mappings and certificate of the names are deleted. This is recorded in the account log.
• A name that is also assigned to another tunnel stays; only the assignment to the orphaned tunnel is removed.
• If the node itself still reports to IPv64.net (e.g. only PROXY64 is switched off), the tunnel stays.
• The clean-up only runs while an edge server is reachable and some tunnel was connected in the last 15 minutes. An outage at IPv64.net therefore never leads to deletion.

DNS and certificates

When you switch a name on, IPv64.net changes the DNS itself – you do not need to add a CNAME or any record:

• All active A and AAAA records of the name are deactivated. They stay stored and are shown in the domain as „CDN64 Active“.
• For each edge server of your account an A and an AAAA record with TTL 10 seconds are added. CDN64 manages these records; you can neither edit nor delete them, not even via the API.
• When you switch off, the server records are deleted and your original records are activated again.
• When you pause, DNS stays on the edge servers.
• If you delete the domain or your account, IPv64.net also removes the CDN64 names in it; the edge servers drop them the next time they fetch their configuration.

DynDNS updates keep running

The DynDNS updater keeps updating the deactivated records in the background. In mode 3 with the target „A/AAAA records of the name“, the edge servers therefore always use your current address. If the name has no record of its own for an address family but only the edge server's record, the updater leaves it unchanged and reports "cdn" for that family (see responses).

Certificates

• Mode 1: the certificate lives in your node (Node64 certificate management). The edge servers never see it.
• Modes 2 and 3: the edge servers obtain the certificate themselves from Let's Encrypt – for the name and *.name via DNS-01. For this, IPv64.net briefly sets the TXT record _acme-challenge in your domain. If DNS-01 fails, HTTP-01 yields a certificate for the name only. If Let's Encrypt is at its limit, the servers fall back to ZeroSSL.
• One server orders, the other takes over the certificate. Certificate and key are stored encrypted at IPv64.net; only the edge servers hold the key for that.
• Renewal happens 30 days before expiry.

Protection: access lists, country blocking, blocklists, WAF and pause

A name in CDN64 is protected in two layers: coarsely on the edge servers, before traffic reaches your connection, and finely in Node64 (modes 1 and 2) with the real visitor IP.

Access list (allow / block list)

Each name has a list of IP addresses and networks on the edge servers (IPv4 and IPv6, e.g. 192.0.2.10 or 2001:db8:1234::/48), at most 200 entries. The Default setting defines what it means:

The list applies to web access and to the name's port mappings. When the list changes, the servers also close connections that are already open. At ipv64.net/cdn64 you edit it for names in mode 3; for names in modes 1 and 2 use the API, or the PROXY64 access lists in Node64.

Block list from Node64: From PROXY64 1.45, the block list and the allow list under PROXY64 → Access lists also apply on the edge servers. Node64 sends both lists for its tunnel to IPv64.net, the first 1000 entries of each list. The servers then reject these addresses for all names of the tunnel in modes 1 and 2 right at connection setup, also at the port mappings. The allow list takes precedence. In the statistics these rejections count as access list.

Country blocking

Country blocking („block these countries“ or „allow only these countries“) is set in Node64 per proxy host and per stream. It works in modes 1 and 2 because Node64 receives the real visitor IP. The country lists come from IPv64.net daily. Details: country blocking in PROXY64. The edge servers themselves have no country blocking; in mode 3 you restrict access with the access list.

Blocklists

• On the edge servers a fixed blocklist applies to all names and modes (Spamhaus DROP, updated every 30 minutes). It is checked at connection setup.
• In Node64 you choose under PROXY64 → Access lists which IPv64 blocklists apply – such as the combined list, the v64 Blocklist from the honeypot network or lists of cloud networks. The selection comes directly from IPv64.net. Details: ipv64 blocklists in PROXY64.

Limits on the edge servers

For all names, the edge servers apply per-IP limits (IPv6 per /64): at most 256 simultaneous connections and 50 new connections per second. In mode 2 there are also request limits per IP (above them response 429). From 80 % load a server shares its bandwidth fairly; nobody is disconnected, only slowed down. The exact values are listed under Protection against overload on the servers.

WAF patterns and attack tools (JA4)

Two more filters on the edge servers keep automated attacks and scanners away from your connection:

• Attack tools (JA4) – all modes: the connection setup yields a JA4 fingerprint of the program, without decrypting anything. If it belongs to a known attack tool from the IPv64.net honeypot network, the servers close the connection. A JA4 only gets on the list once at least three independent accounts have reported it; browsers (Chrome and all Chromium browsers, Firefox, Safari) are never on it. Levels: off, count only or block.
• WAF patterns – modes 2 and 3, on by default: requests such as .env, .git, wp-config.php or ../ and typical scanners such as sqlmap or nikto get 403. In mode 1 the servers do not see the requests.

You switch them per host in Node64: under PROXY64 → Proxy hosts with the shield button next to pause, not on ipv64.net/cdn64 (via the API with PATCH). Which patterns apply exactly and what the light WAF cannot do is described under Protection on the servers.

Protection figures on ipv64.net/cdn64

At the bottom right, below the Node64 tunnels, four small tiles sum up the last 30 days of all names – also if you only use mode 3: requests served with the traffic delivered, requests blocked before your server (blocklists, WAF, overload), attack tools stopped (JA4) and the share of visitors who came via IPv4.

Below each name, ipv64.net/cdn64 shows next to the shield icon what the edge servers did for it in the last 30 days:

• blocked – rejected before anything reached your service: blocklists, access list, overload, WAF patterns and attack tools (JA4) combined
• IPs – blocked IP addresses (IPv6 per /64)
• overload – overload stopped by the connection and request limits
• hidden – connections via CDN64 that kept your own address hidden; in brackets, how many of them came via IPv4

Numbers per day and reason and the most frequent attack tools are shown by Node64 under PROXY64 → CDN64 statistics (more), via the API with GET /cdn64o/protection.

Pause: the emergency brake

With pause (pause icon at ipv64.net/cdn64, Pause in Node64 or via the API) the edge servers immediately stop accepting anything for a name – in all modes. It is meant as quick self-protection, for example during an attack.

• The servers close open connections within a few seconds, including port mappings, WebSockets and long downloads.
• DNS keeps pointing to the edge servers – your own address stays hidden. That is the difference to switching off.
• Settings and statistics are kept. Resume with the same button (play icon).
• At ipv64.net/cdn64 you can pause every name of your account – including names in modes 1 and 2 when the node itself is unreachable.

Port mapper: TCP and UDP via CDN64

The port mapper passes raw TCP or UDP connections on – for services without HTTP(S) such as SSH, WireGuard, game servers or the Proxmox web interface. It opens the same port between 50000 and 62000 on all edge servers. The service is then reachable as name:port, e.g. home.deinedomain.ipv64.net:55349.

• Port assignment: if your target's port is free within the range, you get the same one. Otherwise IPv64.net assigns a free port from the range. Via the API you can request a specific port.
• Modes 1 and 2: you set up the port mapping in Node64 on the stream (PROXY64 → Streams, „reachable from the internet via CDN64“). The connection runs through the tunnel, no port is open at home. See port mapper in the Node64 docs.
• Mode 3: at ipv64.net/cdn64 on the name under Port mappings (TCP/UDP): enter a service name, the port of your target and TCP or UDP, then Add. The servers connect directly to the target; it sees the servers' address, not the visitor's. With frontend level 0, a name uses only the port mapper, without a website.
• All modes: the name's access list and pause also apply to its ports. Traffic counts towards the CDN quota. The number of port mappings depends on your account class.
• Idle: the servers close TCP connections without data in both directions after 1 hour, UDP sessions after 2 minutes without packets.
• UDP: as protection against reflection, the target may only send a visitor a multiple of what came from that visitor. Pure one-way data streams over UDP are therefore not suitable.

Quota and traffic per account class

Every name you switch on counts as one CDN domain. Traffic (in + out, all servers and port mappings) counts against the monthly CDN traffic. Names and port mappings in the former IPv64 CDN are included in the count.

The live values are on Pricing and under Account & limits; via API, GET /api/v2/plans returns them. Your current usage is shown at the top of ipv64.net/cdn64 in the Quota line.

• Traffic used up: when the monthly traffic is reached, IPv64.net blocks all names of the account (status blocked, reason traffic); the edge servers then reject requests. In the new month IPv64.net releases them again.
• Upgrade: after upgrading your account class, names blocked because of traffic are released immediately; the servers pick this up after about 10 seconds.
• Counting: the edge servers regularly report traffic, connections, requests and rejections per name to IPv64.net. The monthly numbers are shown in the list at ipv64.net/cdn64 and in Node64.

Limitations

• Only domains of your IPv64.net account. Names in domains at other DNS providers cannot be switched on.
• No CNAME and no active DNS failover on the name. Conversely, DNS failover does not offer the records of a name in CDN64 for selection.
• No wildcard names (*.) when switching on. If wildcard is enabled for the domain, the edge servers also accept sub-names of the name.
• At most 10 tunnels per account.
• No cache in modes 1 and 2 – there your node caches and compresses.
• Streams only via the port mapper: TCP/UDP services run over a port between 50000 and 62000, not over 443.
• Your upload is the limit: in modes 1 and 2, throughput depends on the upload of your connection.

Troubleshooting

The history of a name – switching on, changes, pauses, blocks, edge server outages – is available via the API at GET /cdn64o/hosts/{id}/events. More help is in the FAQ and the v64.tech forum.

Found a mistake or missing something? Tell us in the v64.tech forum. · Updated: 2026-11-04