CDN64 – tunnel without port forwarding

CDN64 makes a service in your home network reachable from the internet without opening a port on your router. It works behind DS-Lite and CGNAT, too, and on lines with only IPv4 or only IPv6. This page walks you through what happens, step by step.

Who connects to whom?

First things first: your node builds the connection – from the inside out. To your router, that's an ordinary outgoing connection, just like opening a website. That's why no port has to be open at home.

  Your home network                       ipv64 edge servers (Germany)
 ┌────────────────┐                     ┌──────────────────────────┐
 │                │ ════ tunnel 1 ═════►│ Nuremberg                │
 │     Node64     │                     └──────────────────────────┘
 │                │                     ┌──────────────────────────┐
 │                │ ════ tunnel 2 ═════►│ Falkenstein              │
 └────────────────┘                     └──────────────────────────┘
  Router: no open port                            ▲
                                                  │ visitors arrive here
                                                  │ (over IPv4 and IPv6)
 The node opens both tunnels outbound: QUIC (UDP), port 7844, else 443.
 If UDP is blocked, it uses TCP with TLS.

• Two tunnels, always: the node keeps a separate tunnel open to each of the two edge servers.
• Protocol: QUIC over UDP with TLS 1.3. The node tries port 7844 first, otherwise 443 – whichever worked last is tried first.
• UDP blocked? After two failed QUIC attempts the node switches to TCP with TLS and retries QUIC every 5 minutes.
• Which path is in use is shown in the PROXY64 host list per edge server with an icon (tooltip per server): QUIC on its own port 7844, QUIC via port 443, fallback to TLS over TCP, not connected. The self-test in the CDN64 dialog names the path as well; via the API, GET /api/cdn64/online returns it per server in the via field (quic, quic443 or tls, only when connected).
• Authentication: the node verifies the server's certificate and signs in with a token. The token is stored encrypted on the node; ipv64 and the servers only keep a hash of it.
• Keepalive: a keepalive goes through the tunnel every 10 seconds. If the tunnel drops, the node reconnects on its own – first after 1 second, then with growing intervals up to 60 seconds.

What happens during a visit?

Let's say someone opens https://cloud.example.com and you've enabled that name for CDN64:

1. DNS lookup
   The browser asks DNS for the address. ipv64 answers with the addresses of both edge servers (IPv4 and IPv6).
2. The edge server accepts
   The browser connects to one of the two edge servers, which only looks at which name the connection is for.
3. Through the tunnel
   The edge server opens a new channel inside your node's existing tunnel and sends the connection through it – together with the visitor's real address.
4. Node64 takes over
   On your node the connection arrives as if it had come straight in on port 443 or 80. Access lists, limits, blocklists, statistics and logs work exactly as they do at home.
5. Your service answers
   The proxy host forwards to your service, and the response travels back the same way.

Where encryption ends depends on the mode – more on that now.

Mode 1 – passthrough (default)

In mode 1 the edge servers are pure mail carriers: they read the address on the envelope and pass on the sealed letter.

 Visitor                 ipv64 edge server             Your home network
 ┌────────────┐          ┌──────────────────┐          ┌──────────────────┐
 │ Browser    │  HTTPS   │ reads only the   │ tunnel   │ Node64           │
 │ or app     │═════════►│ name (SNI)       │═════════►│                  │
 │            │          │                  │ (QUIC)   │ TLS ends here    │
 │ IPv4/IPv6  │          │ does not         │          │ certificate and  │
 └────────────┘          │ decrypt          │          │ key stay here    │
                         │                  │          │                  │
                         │ basic protection:│          │ access lists,    │
                         │ blocklists,      │          │ limits, log      │
                         │ connections/IP   │          └────────┬─────────┘
                         └──────────────────┘                   ▼
                                                        your home service
 Encrypted from the visitor all the way to your node (end-to-end).

• On port 443 the edge server only reads the name from the handshake (SNI) and passes the connection through without decrypting it.
• Certificate and key stay on your node. The certificate comes from the certificate store as usual.
• HTTP/3: if HTTP/3 is on for the proxy host (the default), the edge server reads the name from the first QUIC packet and passes QUIC through raw. TLS and HTTP/3 still end on your node.
• On port 80 (unencrypted HTTP) the edge server reads the first request line and the Host header to find the name.
• The edge servers already provide coarse protection for everyone: a blocklist and limits for connections per IP or IPv6 /64 – see overload protection on the servers. Everything finer is done by your node.
• Mode 1 also works for hosts with “TLS passthrough”.

Mode 2 – terminate on the edge servers

In mode 2 the edge servers open the letter, check it and then send it on through the tunnel. In return they can sort things out right there.

 Visitor                 ipv64 edge server             Your home network
 ┌────────────┐          ┌──────────────────┐          ┌──────────────────┐
 │ Browser    │  HTTPS   │ TLS ends here    │ tunnel   │ Node64           │
 │ or app     │═════════►│ certificate for  │═════════►│                  │
 │            │          │ name and *.name  │ (QUIC)   │ request arrives  │
 │ IPv4/IPv6  │          │                  │          │ as HTTPS with    │
 └────────────┘          │ blocklists,      │          │ the real visitor │
                         │ limits per IP/64,│          │ IP               │
                         │ host must match  │          │ access lists,    │
                         │ SNI; HTTP/1.1-3  │          │ log as usual     │
                         └──────────────────┘          └────────┬─────────┘
                                                                ▼
                                                        your home service

• TLS ends on the edge servers (TLS 1.2 or 1.3, HTTP/1.1, HTTP/2 and HTTP/3).
• Certificate: the edge servers obtain it themselves from Let's Encrypt, for the name and *.name. One server orders it, the other takes it over in encrypted form. Renewal happens 30 days before expiry.
• Until the certificate is ready, the servers pass traffic through as in mode 1. Switching never causes downtime.
• Protection up front: blocklists, connection and request limits per IP or IPv6 /64 (429 above them) and a check that the Host matches the SNI (421 otherwise).
• Every request travels through the tunnel as its own channel with the real visitor IP and counts as HTTPS on the node. Your node doesn't have to trust any header for this. X-Forwarded-* headers sent by the visitor are removed.
• Port 80 redirects to HTTPS with a 301. If your node is unreachable, the servers show a clear error page (502) – see error page.
• Mode 2 does not work for hosts with “TLS passthrough”.
• There's no caching on the edge servers in mode 2. Every request goes all the way to your node, where “Cache assets” and “Block common exploits” work as usual.

What does ipv64 see?

Plain HTTP over port 80 is readable in both modes – that's always the case with HTTP. Use HTTPS and mode 1 is end-to-end encrypted. More on privacy at ipv64: ipv64.net/datenschutz.

Which mode is right for me?

• Mode 1 is the right choice in almost every case: maximum confidentiality, your certificate, your rules.
• Mode 2 is worth it if unwanted traffic should be slowed down before it reaches your line – for example with a small upload – or if you'd like the edge servers to handle the certificate.

Switching modes

In the host list, the Switch mode button toggles between mode 1 and 2. DNS stays the same, there's nothing to change. When you switch to mode 2, the servers keep passing traffic through until their certificate is ready – the service stays reachable the whole time.

Load balancing and redundancy with two edge servers

Load balancing is built in: DNS lists both edge servers, so visitors are spread across Nuremberg and Falkenstein automatically. There is nothing to set up. If a server fails, ipv64 removes it from DNS after about a minute and the other one takes over.

                            ┌─────────────────────────┐
                 ┌─────────►│ Edge server Nuremberg   │◄═══════════╗
                 │          └───────────┬─────────────┘  tunnel 1  ║
 ┌──────────┐    │ DNS: A/AAAA          │ neighbour           ┌────╨─────┐
 │ Visitor  │────┤ of both servers      │ fallback            │  Node64  │
 └──────────┘    │ (TTL 10)             │ (~20 ms extra)      └────╥─────┘
                 │          ┌───────────┴─────────────┐  tunnel 2  ║
                 └─────────►│ Edge server Falkenstein │◄═══════════╝
                            └─────────────────────────┘

• Always connected to both: in the host list, a badge per server shows its state: green = tunnel connected, blue = reachable via the other server, red = no tunnel.
• Neighbour fallback: if the tunnel to one server is missing, that server still accepts visitors and relays them via the other server. In measurements this adds about 20 ms.
• DNS failover: if a server goes down completely, ipv64 removes it from DNS after about a minute. The other one carries on alone.
• When a server restarts, the node reconnects by itself – in testing after just over a second.
• If ipv64 itself has a problem, the tunnels keep running with the last configuration. Only changes wait until ipv64 is reachable again.

Parallel connections for Business and Company

With the Business and Company account classes, from PROXY64 1.26.0 the node opens four parallel tunnel connections to each edge server instead of one – each with its own fallback QUIC → QUIC via 443 → TLS. The servers hand new visitors to the least loaded connection.

   Edge server Nuremberg           Edge server Falkenstein
  ┌──────────────────────┐        ┌──────────────────────┐
  │ new visitors go to   │        │ new visitors go to   │
  │ the connection with  │        │ the connection with  │
  │ the least load       │        │ the least load       │
  └──┬───┬───┬───┬───────┘        └──┬───┬───┬───┬───────┘
     ║   ║   ║   ║                   ║   ║   ║   ║  4 tunnels per server
     ║   ║   ║   ║                   ║   ║   ║   ║
  ┌──╨───╨───╨───╨───────────────────╨───╨───╨───╨───────┐
  │                        Node64                        │
  └──────────────────────────────────────────────────────┘
  If one connection fails, the others keep running.

• More performance: with the parallel connections, CDN64 is roughly two to two and a half times as fast. On a home connection your upload remains the limit.
• Relieves your node too: the work is spread not only on the edge servers but also in your node across several CPU cores instead of one.
• More resilience: if one connection fails, the others keep running – on top of the second edge server and the neighbour fallback.
• Load balancing twice, then: between the two servers via DNS and on each server across the four connections.
• In the host list, the server badge shows ×4. Changing the account class rebuilds the connections automatically.

Error page of the edge servers

If your node or target is unreachable or answers with a 5xx error, the edge servers show browsers a small page in ipv64 style (“currently unreachable”, light and dark, German and English, with a link to ipv64.net). This applies in modes 2 and 3.

• Requests from apps and APIs (without text/html) get your target's answer unchanged.
• Keep your own error page: have your target send the response header CDN64-Error-Page: off – the servers then pass its answer through.
• In mode 1, TLS only ends at your side; there the page only exists over HTTP when the node isn't connected or the name is blocked.

If someone calls an edge server directly – by its own name, its IP or a name without a customer – it shows an info page in the same style: a server of the IPv64 CDN that delivers its customers' websites and services, with links to ipv64.net and node64.de. Other paths get a 404 in the same style.

Overload protection on the servers

When a host runs through CDN64, it is protected twice: coarsely and for everyone on the two ipv64 edge servers – before any traffic even reaches your node – and then finely and per host in your node. In the host list, you can tell by the green shield in the "CDN64" column.

  Visitors, bots, attackers
                           │
                           ▼
 ┌──────────────────────────────────────────────────┐
 │ ipv64 edge servers · Germany                     │
 │ • Spamhaus DROP: hijacked networks are out       │
 │ • per IP at most 256 connections, 50 new/s       │
 │ • pause: emergency brake per name, IP hidden     │
 │ • fair throttling from 80 % load, no one cut     │
 └─────────────────────────┬────────────────────────┘
                           ║  encrypted tunnel, real visitor IP
 ┌─────────────────────────╨────────────────────────┐
 │ Node64 · PROXY64 in your home network            │
 │ • Honeypot64 instant block, ipv64 blocklists     │
 │ • country block, rate limits per host            │
 │ • access lists, block common exploits            │
 └─────────────────────────┬────────────────────────┘
                           ▼
                       Your service

This applies to all customers and in every mode. Someone who just causes a lot of traffic is not disconnected; throttling only kicks in under real overload.

Then, in your node – in modes 1 and 2 always with the real visitor IP – the full local protection applies: per-host rate limits, ipv64 blocklists, country blocking, access lists and Block Common Exploits. Your own allow/block list per name directly on the servers is available with mode 3 on ipv64.net/cdn64.

Fair throttling and quota

The edge servers share their bandwidth fairly among all users:

• Nobody gets disconnected – at most slowed down. Only once a server is 80 % busy does fair sharing kick in: whoever needs little gets all of it, 10 % stays free for new visitors, and everyone gets at least 1 Mbit/s. Below 60 % load the throttle is lifted again. This applies to all modes.
• Bandwidth per account: depending on your account plan, an additional bandwidth limit applies, across both servers combined (see table).
• Quota: every enabled name counts as a CDN domain, and the traffic counts against your plan's CDN traffic – both shared with the existing ipv64 CDN. Once the month's traffic is used up, your names are blocked until the next month starts – or until an upgrade of your account plan.

As of 21 Oct 2026. An upgrade applies immediately: names blocked because of traffic are released, and the servers pick that up after about 10 seconds; the new bandwidth applies after at most 10 seconds.

See what your plan includes at ipv64.net/pricing. Node64 shows the monthly figures of your enabled hosts (traffic, requests, rejections) and your quota right in the host list: two tiles with progress bars for the CDN domains in use (with your plan's bandwidth) and the traffic this month. From the second day of the month a forecast shows whether the traffic lasts until the end of the month at the current rate – or until when. The same bars appear on the dashboard in the PROXY64 and ipv64 account cards (yellow from 80 %, red when full).

DNS: nothing for you to enter

• No CNAME needed. When you switch a name on, ipv64 updates it itself: it then points to both edge servers with A and AAAA records (TTL 10 seconds).
• Your previous A/AAAA records are put on hold meanwhile and come back when you switch off.
• Requirement: the name itself has no CNAME and no DNS failover.
• Wildcard names (*.example.com) are skipped when switching on.

At home, traffic stays at home

If your network uses DNS64 on the same node, it answers enabled names with the node's local address (split DNS). Requests from home then don't go out over the internet. This doesn't apply if the node runs in a Docker bridge network – then you get the normal answer.

Requirements

• Node64 version 0.11.98 or later with the PROXY64 module enabled and a proxy host for the name.
• A connected ipv64.net account (central API key under Settings → ipv64, see Connect to ipv64.net) on an account plan that includes CDN domains. The plans are listed at ipv64.net/pricing.
• The name is in a domain of your ipv64 account – for example a DynDNS domain or your own domain managed at ipv64.
• Outbound UDP or TCP on port 7844 or 443 must be allowed. That's the case in almost every home network.

One-click setup

1. Switch on
   In Node64 under PROXY64 → Proxy hosts, click Enable in the CDN64 column for the host and pick the mode. The window explains the three modes at the top with a small sketch; clicking a box picks the mode, mode 3 points to ipv64.net/cdn64.
2. Check the account
   The node checks your ipv64 account and quota. Without an account, the dialog takes you to Connect account.
3. Build the tunnel
   The node registers with the edge servers and builds both tunnels. If UDP is blocked, the tunnel runs over TCP.
4. Enable the names
   Each name of the host is enabled at ipv64 individually; from then on DNS points to the edge servers. If you like, the node also creates an online health check for the first name.
5. Self-test
   The node tests every name over every server and every address family (IPv4, IPv6) across the internet. “OK” means the probe arrived through exactly this node's tunnel. You also see whether the certificate is trusted by visitors and whether DNS has switched over yet.

Each step shows its result and, if something fails, the fix right away. You're done when everything is green.

Notifications

Through your notification channels, Node64 lets you know when the tunnel has been down to all servers for 3 minutes, when it's back, and when ipv64 blocks a name (e.g. because the traffic is used up).

Switching off

Disable in the host list switches the names off at ipv64, and DNS points to the old address again. With the last name, the node also deregisters the tunnel. If you delete a host or remove a name, the sync (every minute) removes it at ipv64. In an emergency – say the node is unreachable – you can also switch names off at ipv64.net/cdn64; the node picks that up.

Node deleted without signing off

If you delete the container without switching the names off, the tunnel is left orphaned at ipv64 (modes 1 and 2). Then:

• After 48 hours without a connection, ipv64.net/cdn64 shows a notice – no mail or notification.
• After 14 days, ipv64 removes everything automatically: DNS goes back to the original records, and the names with their assignment, target, list, port mapper, certificate and the tunnel including its token are removed. This is logged.
• Names that are also attached to another connected tunnel stay. A tunnel that never connected counts from when it was created. Mode 3 is not affected.

Pausing

With Pause in the host list, the edge servers immediately stop accepting anything for a name – in all modes. It's meant as quick self-protection, for example during an attack.

• The servers drop open connections within a few seconds. Mode 1 closes the connection, modes 2 and 3 answer with 503, the port mapper and QUIC accept nothing.
• The tunnel stays connected and DNS keeps pointing to the edge servers – your own address stays hidden. That's the difference to switching off, where DNS points to your address again.
• Settings and statistics are kept. Resume with the same button. Paused names are highlighted in yellow in the host list and under More names in CDN64.
• You can also pause and resume on ipv64.net/cdn64 – for all names of your account, for example when the node itself is unreachable.
• Via the API: POST /api/cdn64/hosts/{id}/online/pause with {"paused": true} or false.

More names in CDN64

Below the host list, the More names in CDN64 card shows the names of your account that this node doesn't manage: names in mode 3 set up on ipv64.net, and names in mode 1 or 2 via another node. It shows target, server cache, allow and block list, port mapper, status and traffic this month. These names are edited on ipv64.net or in the other node; you can pause them right here – via the API with POST /api/cdn64/online/names/{rid}/pause and {"paused": true|false}.

If PROXY64 already has a host with the same name, the name doesn't appear in the card but in that host's CDN64 column: mode, “ipv64.net” or “other node”, status, cache, traffic and pause, for mode 3 a link to edit it. Enabling and switching modes aren't available there. So the card only lists names without a host on this node.

The node fetches the state even without CDN64 names of its own: every 5 minutes if the account has no names, immediately when you open the list.

Common messages

sysctl -w net.core.rmem_max=7500000 net.core.wmem_max=7500000

To keep the value across reboots, also add it to /etc/sysctl.conf or a file under /etc/sysctl.d/.

Port mapper: TCP and UDP via CDN64

A port mapper is a port on the edge servers between 50000 and 62000 – the same on both servers – that passes connections on raw via TCP or UDP. It's meant for services without HTTP(S), such as SSH, WireGuard, game servers or the Proxmox web interface. The service is then reachable as <name>:<port>, for example home.example.ipv64.net:55349.

 Visitor           ipv64 edge server         Node64 (home)
 ┌───────────┐     ┌──────────────┐          ┌──────────────┐   ┌──────────┐
 │ SSH,      │ TCP │ port 55349   │  QUIC    │ stream in    │   │ NAS,     │
 │ WireGuard,│────►│ blocklist,   │═════════►│ PROXY64,     │──►│ Proxmox, │
 │ game      │ UDP │ limits per IP│  tunnel  │ real IP      │   │ server   │
 └───────────┘     └──────────────┘          └──────────────┘   └──────────┘
  name.ipv64.net:55349                        Router: no port open

 Visitor           ipv64 edge server                Your server
 ┌───────────┐     ┌──────────────┐                 ┌───────────────┐
 │ browser,  │ TCP │ cache,       │  directly, no   │ website,      │
 │ app,      │────►│ port mapper, │────────────────►│ game server   │
 │ game      │ UDP │ blocklist    │  tunnel         │ public        │
 └───────────┘     └──────────────┘                 └───────────────┘
                                                     port open at target

Modes 1 and 2: with Node64

1. Create a stream
   Under PROXY64 → Streams, create a stream: port on the node → target in your home network, TCP and/or UDP.
2. Pick a CDN64 name
   In the stream, under Reachable from the internet via CDN64, pick a CDN64 name of this node and save.
3. Read the port
   The servers' port is shown in the stream list (name:port with TCP/UDP) and in the host's row.

• The connection runs through the encrypted tunnel. No port needs to be open at home, and your IP stays hidden.
• Protection is based on the real visitor IP: the stream's blocklists, per-IP limits and country block apply, TLS termination optionally with a certificate from the store.
• Registering and removing at ipv64 happens automatically – when you switch the stream off, delete it, change its port or switch the name off.
• API: field online_name on the stream; the output contains cdn64_ports (name, listen_port, transport) and, on problems, cdn64_error.

Mode 3: without Node64

• Set up on ipv64.net/cdn64 at the name under Edit → Port mappings: server port → target port on your own target.
• The servers connect directly to the target – so it must be reachable from the internet.
• With level 0 a name only uses the port mapper, without a website.
• In PROXY64 these ports appear read-only in the host's row or under More names in CDN64 (server port → target port).

For all modes

• The number of port mappers depends on your account class (quota CDN mappings); the existing ipv64 CDN counts too.
• The name's allow and block list and pause also apply to its ports.
• Traffic counts towards the CDN quota (see quota). For UDP the reflection protection applies.
• Limits: per IP at most 256 concurrent connections and 50 new ones per second, plus 200 new UDP sessions per second and at most 4096 per port. In modes 1 and 2, at most 1024 UDP sessions and 4096 TCP connections per stream come out of the tunnel. Bandwidth and traffic follow your account class.
• Idle timeout: the servers close TCP connections after 1 hour without data in either direction; active connections stay open as long as they like. UDP sessions end after 2 minutes without packets. Tip for SSH: set a keepalive, e.g. ServerAliveInterval 60 in ~/.ssh/config.

Limitations

• Only names in domains of your ipv64 account. Domains at other providers can't be enabled online at the moment.
• Streams only via the port mapper: TCP/UDP streams (e.g. WireGuard) use a port on the edge servers, not 443 – see port mapper.
• No wildcard names (*.) when switching on.
• No caching on the edge servers in modes 1 and 2.
• Your upload is the limit: throughput depends on your line's upload speed. In testing, the tunnel used the test line's full upload (around 48 Mbit/s); response times with HTTP/2 were around 26–30 ms on average. Your numbers depend on your connection.

Mode 3 and port mapper on ipv64.net

If your service is already publicly reachable (public IP or name), you don't need a tunnel: in mode 3 the edge servers go straight to your target – with edge caching, frontend levels and a port mapper for raw TCP and UDP ports. Mode 3 runs without Node64 and is set up only on ipv64.net/cdn64. The dialog in Node64 links there.

Compression: in modes 1 and 2 your node compresses responses (see PROXY64 → Compression). In mode 3 the edge servers compress text responses from the target themselves with zstd, Brotli or gzip if the target doesn't – which saves traffic quota. In mode 3, traffic and bandwidth count the compressed body bytes actually sent, also for responses from the cache; headers don't count. Only responses that go into the cache get the strong compression level. Aborted responses never end up in the cache, and the cache keeps one copy per method the browser accepts.

Next up: the reverse proxy in your home network or certificates. Product overview: PROXY64 & CDN64.

Something unclear, missing, or a question about Node64? Ask in the official forum v64.tech.