NAT Traversal erklärt: wie P2P-Remote-Desktop durch Ihren Router greift.

Sie haben eine öffentliche IP-Adresse und ein Dutzend Geräte hinter Ihrem Router. Ihr iPad ist per Mobilfunk drei Netze weiter unterwegs. Irgendwie baut eine Remote-Desktop-App in unter einer Sekunde eine direkte Verbindung vom einen zum anderen auf – meist ohne Relay dazwischen. So funktioniert diese Magie tatsächlich: ICE, STUN, TURN, Hole Punching und die unbequeme Wahrheit über symmetrisches NAT.

Warum das wichtig ist

Stellen Sie sich einen Dienstagmorgen vor. Ihr Mac mini steht zu Hause hinter einem Router mit einer einzigen öffentlichen IPv4-Adresse. Ihr iPad ist im Zug, in einem Mobilfunknetz mit eigenen Schichten der Adressübersetzung. Zwischen den beiden Geräten liegen mindestens zwei NATs, wahrscheinlich drei. Keines der beiden Geräte ist aus dem öffentlichen Internet standardmäßig erreichbar.

Und doch öffnen Sie Remio auf dem iPad, tippen auf den Mac, und eine Sekunde später blicken Sie auf Ihren Desktop. Video und Eingaben fließen direkt zwischen den beiden Geräten – kein Cloud-Relay, kein Proxy dazwischen, der Ihren Bildschirm neu kodiert.

Die Technik, die das möglich macht, hat einen Namen – NAT Traversal – und dahinter steht eine Familie klar definierter Protokolle: STUN, TURN und ICE. Es sind dieselben Protokolle, die WebRTC für Videoanrufe im Browser nutzt, und sie sind der Grund, warum jedes moderne P2P-Remote-Desktop vermeiden kann, Ihre Bildschirm-Frames durch das Rechenzentrum eines Dritten zu zwingen. Dieser Artikel erklärt, was jedes davon tut, warum es existiert und wie sie zusammenwirken, um den Weg mit der niedrigsten Latenz zwischen zwei Geräten hinter Routern zu finden.

Das NAT-Problem in 60 Sekunden

Das Internet wurde so entworfen, dass jedes Gerät eine eigene, öffentlich routbare Adresse hat. Im gesamten IPv4-Adressraum gibt es rund 4,3 Milliarden Adressen – 1981 reichlich, Ende der 1990er-Jahre ganz offensichtlich nicht mehr.

Die Notlösung hieß Network Address Translation. Ihr Router erhält von Ihrem Provider eine öffentliche IPv4-Adresse. In Ihrem Zuhause bekommt jedes Gerät eine private Adresse aus einem reservierten Bereich (typischerweise 192.168.x.x oder 10.x.x.x). Sendet Ihr Laptop ein Paket nach außen, schreibt der Router die Absenderadresse auf seine eigene öffentliche IP um, merkt sich die Zuordnung und leitet weiter. Kommt die Antwort zurück, schlägt der Router die Zuordnung nach und schreibt die Zieladresse wieder auf Ihren Laptop um.

Genau deshalb funktionieren eingehende Verbindungen standardmäßig nicht. Von außen hat Ihr Laptop keine Adresse; nur der Router hat eine. Das Paket eines Fremden an ihre-router-oeffentliche-ip:5060 trifft auf einen Router ohne passende Zuordnung und wird verworfen.

Für eine P2P-App ist das die ganze Aufgabe. Beide Gegenstellen sitzen hinter Routern, die Pakete nur weiterleiten, wenn sie sich erinnern, zuvor etwas nach außen gesendet zu haben. Keine Seite kann die andere einfach „anrufen“ – sie müssen mit ihren Routern zusammenarbeiten, um einen vorübergehenden Weg zu öffnen.

Hole Punching: die Firewall dazu bringen, Sie wieder hereinzulassen

Das ist der Trick. Die NAT-Tabelle Ihres Routers wird über ein Fünf-Tupel geführt: Quell-IP, Quellport, Ziel-IP, Zielport und Protokoll. Sendet Ihr Gerät ein ausgehendes UDP-Paket an 1.2.3.4:5678, legt der Router einen temporären Eintrag an: „Wenn ein UDP-Paket von 1.2.3.4:5678 an meine öffentliche IP auf Port X zurückkommt, leite es an dieses Gerät auf Port Y weiter.“

Dieser Eintrag existiert für eine gewisse Zeit – typischerweise 30 bis 60 Sekunden – und läuft dann ab, sofern ihn nichts auffrischt. In diesem Zeitfenster wird jedes Paket von der Zieladresse akzeptiert.

Das ist das Schlüsselloch, das P2P-Apps nutzen. Kennen beide Gegenstellen die öffentliche Adresse der jeweils anderen, können sie gleichzeitig je ein einzelnes ausgehendes UDP-Paket an die andere senden. Der Router jeder Seite öffnet eine ausgehende Zuordnung. Das erste Paket jeder Seite wird womöglich verworfen – der andere Router hat seine Zuordnung noch nicht geöffnet –, aber das zweite Paket hat ein Ziel. Von da an glauben beide Router, eine normale ausgehende Unterhaltung weiterzuleiten, und die beiden Geräte sprechen direkt miteinander.

Das nennt man UDP Hole Punching. Es ist leicht wundersam, gut dokumentiert (RFC 5128) und funktioniert bei der großen Mehrheit der Verbraucher-NATs in freier Wildbahn. Die übrigen Fälle – symmetrisches NAT, CGNAT, Firmen-Firewalls – sind der Grund, warum es TURN überhaupt gibt.

Hole Punching ist kein Hack. Es ist der ausdrückliche Vertrag, um den NAT herum entworfen wurde: Ein ausgehendes Paket schafft eine eingehende Erlaubnis. P2P-Apps senden das ausgehende Paket nur absichtlich.

STUN: „Wie lautet meine öffentliche Adresse?“

Hole Punching hat eine Voraussetzung: Jede Gegenstelle muss ihre eigene öffentliche Adresse kennen, um der anderen Seite mitzuteilen, wohin sie Pakete senden soll. Diese Adresse ist von innen im Gerät nicht sichtbar. Ihr iPad sieht seine lokale WLAN-Adresse (192.168.1.42). Was der Rest des Internets sieht, nachdem der Router das Paket umgeschrieben hat, ist etwas völlig anderes.

STUN – Session Traversal Utilities for NAT, RFC 5389 – ist das winzige Protokoll, das dieses Problem löst. Der Ablauf ist beinahe peinlich einfach:

1. Die Gegenstelle sendet ein UDP-Paket an einen öffentlichen STUN-Server. (Remio nutzt zur Redundanz sowohl die öffentlichen STUN-Server von Cloudflare als auch die von Google.)
2. Der STUN-Server liest Quell-IP und Quellport von der Leitung ab – das ist per Definition die durch NAT übersetzte öffentliche Adresse der Gegenstelle.
3. Der STUN-Server antwortet mit dieser Adresse als Nutzdaten: „Soweit ich sehe, sind Sie 203.0.113.42:48291.“
4. Die Gegenstelle weiß nun, welche Adresse sie der anderen Seite mitteilen muss.

Diese öffentliche Adresse heißt in der ICE-Terminologie Server-Reflexive Candidate. Sie kostet praktisch nichts – eine Round-Trip-Zeit beim Verbindungsaufbau und danach weder Bandbreite noch zusätzliche Latenz. Die einzige Aufgabe von STUN ist es, zwei Gegenstellen einander vorzustellen; sobald sie miteinander sprechen, hat der STUN-Server keine Rolle mehr.

TURN: wenn Hole Punching scheitert

Hole Punching funktioniert bei den meisten NATs, aber nicht bei allen. Die Fehlerfälle sind real, und eine P2P-App, die so tut, als gäbe es sie nicht, scheitert bei einem nennenswerten Teil der Nutzer schlicht am Verbindungsaufbau.

Die Hauptschurken:

• Symmetrisches NAT. Ein NAT, das für jedes einzelne Ziel einen anderen öffentlichen Port vergibt. STUN teilt Ihrer Gegenstelle mit, Sie seien auf Port 48291 (weil der STUN-Server diesen Port gesehen hat), doch wenn Sie ein Paket an die Adresse Ihrer Gegenstelle senden, wählt Ihr Router einen anderen Port – etwa 48317. Der Router der Gegenstelle weist das Paket ab, weil es von einem unerwarteten Port kommt. Hole Punching bricht zusammen.
• Carrier-Grade NAT (CGNAT). Mobilfunk- und viele Provider-Netze legen auf Betreiberebene ein zweites NAT darüber. Sie könnten, ohne es zu wissen, hinter zwei NATs sitzen, die beide zusammenarbeiten müssen. CGNAT ist oft symmetrisch, und Sie haben keinen Administratorzugriff darauf.
• Restriktive Firmen-Firewalls. Manche Unternehmensnetze blockieren sämtliches ausgehende UDP oder erlauben es nur zu bestimmten Zielen. Hole Punching braucht einen UDP-Pfad; gibt es keinen, hat es keine Chance.

Für diese Fälle ist TURN die Rückfalloption – Traversal Using Relays around NAT, RFC 5766. Ein TURN-Server ist ein Relay, das beide Gegenstellen erreichen können, weil es eine öffentliche Adresse hat, die eingehenden Verkehr stets annimmt. Jede Gegenstelle baut eine normale ausgehende TLS-Verbindung zum TURN-Server auf (was jedes NAT erlaubt), und der Server leitet Bytes zwischen den beiden Seiten weiter.

TURN ist ein echter Kostenfaktor. Jedes Videopaket muss einen zusätzlichen Netzwerksprung zurücklegen. Bei einem regionalen TURN-Relay sind das etwa 30 bis 80 Millisekunden zusätzliche Round-Trip-Latenz. Über Regionen hinweg – etwa ein Relay in Frankfurt für eine Gegenstelle in Tokio und eine in São Paulo – können es 80 bis 200 Millisekunden sein. Auch der TURN-Betreiber zahlt für Bandbreite: Jedes Bit Ihres Streams läuft durch seine Leitungen.

Deshalb nutzt eine gut gestaltete App TURN nur, wenn Hole Punching nachweislich gescheitert ist. ICE trifft diese Entscheidung automatisch.

ICE: alle Kandidaten parallel ausprobieren

Interactive Connectivity Establishment, RFC 8445, ist die Choreografie, die all das zusammenhält. ICE legt sich nicht im Voraus auf eine Strategie fest. Es sammelt für jede Gegenstelle jede mögliche Kandidatenadresse, tauscht die vollständige Liste mit der anderen Seite aus und lässt dann beide Stacks jedes Kandidatenpaar parallel prüfen – ein Wettlauf darum, welches zuerst funktioniert.

Für jede Gegenstelle sammelt ICE typischerweise:

• Host-Kandidaten – jede lokale IP-Adresse auf jeder Netzwerkschnittstelle (Ethernet, WLAN, virtuelle Schnittstellen, IPv4 und IPv6).
• Server-Reflexive-Kandidaten – öffentliche Adressen, die von STUN-Servern ermittelt wurden.
• Relay-Kandidaten – Adressen, die auf einem TURN-Server zugewiesen wurden.

Die beiden Gegenstellen tauschen diese Listen über einen Signalisierungskanal aus – bei Remio ist das eine kleine WebSocket-Verbindung zu relay.remio.net, die die ICE-Kandidaten und die WebRTC-Sitzungsbeschreibung (das SDP) überträgt und danach nichts mehr zu tun hat, sobald die Medien fließen.

Sind beide Listen vorhanden, beginnt ICE mit den Konnektivitätsprüfungen. Jede Gegenstelle sendet in Prioritätsreihenfolge ein STUN-Binding-Request-Paket entlang jedes Kandidatenpaars. Die Prioritäten sind so ausgelegt, dass der Pfad mit der niedrigsten Latenz bevorzugt wird:

1. Host zu Host – beide Gegenstellen im selben lokalen Netzwerk. Das ist der Idealfall: einige hundert Mikrosekunden Latenz, kein Router beteiligt.
2. Host zu Server-Reflexive oder Server-Reflexive zu Server-Reflexive – Gegenstellen in verschiedenen Netzwerken, per Hole Punching durch ihre jeweiligen NATs verbunden. Das ist in der Praxis meist gemeint, wenn von „P2P übers Internet“ die Rede ist.
3. Alles mit einem Relay – letzter Ausweg, nur genutzt, wenn alle Pfade mit höherer Priorität ihre Konnektivitätsprüfungen nicht bestehen.

Das erste Kandidatenpaar, bei dem beide Richtungen gelingen, wird zum Sieger ernannt, und die Medien beginnen, entlang dieses Pfads zu fließen. Der ganze Vorgang ist typischerweise in deutlich unter einer Sekunde abgeschlossen.

ICE sammelt Kandidaten außerdem fortlaufend. Taucht mitten in der Sitzung ein besserer Pfad auf – etwa weil Ihr Smartphone den Mobilfunk verlässt und sich ins WLAN einbucht –, kann ICE auf den neuen Pfad umschalten, ohne den Anruf zu unterbrechen.

Warum Remio P2P so entschieden bevorzugt

Remio ist eine Remote-Desktop-App, kein Videoanruf. Das Latenzbudget ist gnadenlos. Damit sich eine Sitzung anfühlt, als säßen Sie am Host-Rechner, muss die gesamte Pipeline – Aufnahme, Kodierung, Netzwerk, Dekodierung, Darstellung – winzig sein: Im LAN kostet sie rund 8 ms, und der Rest ist der eigene 60-Hz-Bildtakt Ihres Displays (rund 16,7 ms pro Frame). Jeder zusätzliche Sprung ist eine Sünde.

Bei einer direkten P2P-Verbindung im LAN liegt der Netzwerkanteil dieses Budgets bei etwa 1 bis 5 Millisekunden Round-Trip. Es gibt kein Relay; die Bytes gehen direkt von einem Gerät zum anderen. Mit der Pipeline von Remio summiert sich das auf rund 8 ms Verarbeitung im LAN (intern gemessen; der Rest ist der eigene 60-Hz-Bildtakt Ihres Displays) – Ihre Eingabe kommt an, bevor der nächste Frame gezeichnet wird. Der entfernte Rechner fühlt sich nicht von einem lokalen unterscheidbar an.

Bei einer Verbindung über ein TURN-Relay – selbst ein regionales – springt der Netzwerkanteil auf 30 bis 80 Millisekunden. Die insgesamt wahrgenommene Latenz liegt dann bei 40 bis 100 ms. Für die meiste Arbeit immer noch brauchbar, aber bei einem schnellen Ziehen oder einer raschen Klickfolge spüren Sie es. Das Trackpad fühlt sich nicht mehr ganz wie Ihr eigenes an.

Dieser Unterschied ist der Grund, warum wir so viel Aufwand betreiben, Sitzungen auf P2P zu halten. Der WebRTC-Stack von Remio sammelt IPv4- und IPv6-Kandidaten, spricht parallel mit mehreren STUN-Servern und bevorzugt bei der Kandidatenpaar-Auswahl von ICE konsequent direkte Pfade. Intern nutzen wir sogar die gemessene Verbindungs-RTT, um das Netzwerk einzuordnen – unter 15 ms wissen wir, dass es ein LAN ist, sodass der Encoder hoch startet und deutlich mehr Bandbreite nutzen darf. Alles Langsamere wird als WAN behandelt und vorsichtiger abgestimmt.

Und – das lassen Mitbewerber oft stillschweigend weg – die Verbindung ist unabhängig vom Pfad Ende-zu-Ende-verschlüsselt. Ihr Bildschirm berührt nie unsere Server, und selbst ein TURN-Relay sieht immer nur Chiffretext: Die Schlüssel werden beim Handshake direkt zwischen den beiden Gegenstellen ausgehandelt, bevor sich auch nur ein Pixel bewegt. Ob die Bytes per P2P oder über TURN fließen – weder der Signalisierungsserver von Remio noch der TURN-Betreiber kann sie lesen. P2P bedeutet nur, dass sich überhaupt keine dritte Partei auf dem Datenpfad befindet.

Wenn ein Relay unvermeidlich ist (und das ist in Ordnung)

Manchmal sagen die Netzwerkgötter nein. Symmetrisches NAT auf beiden Seiten, doppeltes CGNAT bei einem Mobilfunkanbieter mit striktem Provider, eine Firmen-Firewall, die nur ausgehendes TLS zu bekannten Cloud-Anbietern erlaubt – das sind reale, häufige Konfigurationen. In diesen Fällen muss die Sitzung über ein Relay laufen, oder sie kommt gar nicht zustande.

Das TURN-Backend von Remio ist Cloudflare Calls, das uns ein globales Netz von Relays in der Nähe der meisten Nutzer bietet. Wählt ICE einen Relay-Pfad, verschlechtert sich das Erlebnis von „fühlt sich lokal an“ zu „fühlt sich an wie Splashtop“ – immer noch sehr gut nutzbar, aber man merkt es. Die zusätzliche Latenz liegt bei 30 bis 80 ms für ein regionales Relay; über Regionen hinweg können es 200 ms werden.

Das Wichtige: Die Daten sind weiterhin Ende-zu-Ende-verschlüsselt. Cloudflare sieht verschlüsselte UDP-Pakete in die eine und verschlüsselte UDP-Pakete in die andere Richtung. Es kann Bytes für die Abrechnung zählen. Es kann weder Ihren Bildschirm noch Ihre Tastatureingaben noch irgendeinen Sitzungsinhalt sehen. Auch auf Remio-Seite gibt es keinen Entschlüsselungspunkt, denn es gibt keine Remio-Cloud in der Pipeline – wir betreiben den TURN-Dienst über Cloudflare und berühren die Nutzdaten nie.

Das ist die Architektur, die unser Sicherheits-Whitepaper ausführlicher beschreibt. Kurzfassung: P2P oder Relay – das Bedrohungsmodell ist dasselbe.

Der IPv6-Notausgang

IPv6 bietet 340 Sextillionen Adressen (3,4 × 10³⁸) – genug, um jedem Sandkorn der Erde eine eigene öffentliche IP zu geben, mit ein paar Billionen als Reserve. In einer reinen IPv6-Welt ist NAT weitgehend überflüssig. Zwei IPv6-fähige Geräte können einander einfach Pakete an die jeweilige Adresse senden, und das einzige Hindernis ist die Host-Firewall auf beiden Seiten.

Wenn Sie zu Hause und bei Ihrem Mobilfunkanbieter IPv6 haben, ist Ihnen vielleicht aufgefallen, dass manche Apps schneller verbinden, wenn beide Seiten IPv6 nutzen – denn der ganze Tanz aus „Kandidaten sammeln, Paare prüfen“ hat weniger Hindernisse. Es gibt keine NAT-Übersetzung zu ermitteln, keinen STUN-Abstecher, nur direkte Adressen.

Aber hier der Haken: 2026 ist die weltweite Einführung noch immer unvollständig. Viele Heimrouter beherrschen IPv6 schlecht oder gar nicht. Viele Firmennetze blockieren eingehendes IPv6 standardmäßig. Manche Anbieter bieten IPv6 auf der Funkseite an, bridgen aber anderswo auf IPv4. Reine IPv6-zu-IPv6-Pfade gibt es, doch auf sie allein kann man sich nicht verlassen.

Deshalb sammelt Remio – wie jeder ernsthafte P2P-Stack – IPv4- und IPv6-Kandidaten und lässt ICE sie gegeneinander antreten. Existiert ein direkter IPv6-Pfad und funktioniert er, gewinnt er meist bei der Latenz. Wenn nicht, übernimmt IPv4 mit Hole Punching. Scheitern beide, kommt das Relay. Der Nutzer sieht von alledem nichts; die Verbindung steht einfach.

So erkennen Sie, welchen Pfad Ihre Sitzung nutzt

Neugierig, auf welchem Pfad Ihre Sitzung gelandet ist? Die Verbindungsanzeige von Remio zeigt den Typ in verständlicher Sprache – „Direkt“ für P2P, „Relay“ für TURN. Das Entwickler-Statistikfenster zeigt den vollständigen WebRTC-Zustand, einschließlich der Kandidatentypen des ausgewählten Paars (host, srflx, relay) und der gemessenen RTT.

Ein paar schnelle Deutungen:

• RTT unter 5 ms, Direkt – Sie sind im selben LAN wie der Host. Bestfall. Rund 8 ms Verarbeitung (der Rest ist der eigene 60-Hz-Bildtakt Ihres Displays) sind erreichbar.
• RTT 5 bis 15 ms, Direkt – dasselbe WLAN-Netzwerk, aber mit einem zusätzlichen Access-Point- oder Mesh-Sprung. Immer noch ausgezeichnet.
• RTT 15 bis 80 ms, Direkt – Sie sind in einem anderen Netzwerk als der Host, das Hole Punching war erfolgreich. Internet-P2P funktioniert.
• RTT 30 bis 80 ms, Relay (regional) – symmetrisches NAT oder Carrier-Grade NAT hat das Hole Punching vereitelt. Ein Cloudflare-TURN in der Nähe hat übernommen.
• RTT 80 bis 200 ms, Relay – TURN über eine größere geografische Distanz, oder Sie und der Host befinden sich in sehr unterschiedlichen Regionen.

Wenn Sie selbst zu Hause zuverlässig auf ein Relay zurückfallen, sind die üblichen Verdächtigen ein Provider-Modem mit symmetrischem NAT, IPv4-CGNAT an Ihrem Hausanschluss (bei Glasfaser-Wiederverkäufern häufiger, als man denkt) oder eine übereifrige Firewall, die eingehendes UDP blockiert. Unser Leitfaden zur Verringerung der Remote-Desktop-Latenz geht die häufigsten Ursachen durch, und die Seite zur direkten LAN-Verbindung ist der schnelle Weg, wenn beide Geräte in Ihrem Netzwerk sind.

Leistungszahlen aus der Praxis

Alles zusammengenommen, hier die Latenzwerte, die wir im Produktivbetrieb über die verschiedenen Pfade messen, die eine Remio-Sitzung nehmen kann:

• Direktes LAN-P2P: 1–5 ms Netzwerk-RTT. Ende-zu-Ende (Eingabeereignis bis Pixelaktualisierung): rund 8 ms Verarbeitung (der Rest ist der eigene 60-Hz-Bildtakt Ihres Displays), wenn der Rest der Pipeline mitspielt.
• WLAN im selben Netzwerk mit zusätzlichen Sprüngen: 5–10 ms Netzwerk-RTT.
• TURN-Relay, regional: 30–80 ms Netzwerk-RTT.
• TURN-Relay, über Regionen hinweg: 80–200 ms Netzwerk-RTT.
• 4G/5G-Mobilfunk, per Hole Punching verbundenes P2P: 40–100 ms Netzwerk-RTT.

Diese Werte decken sich mit den Zahlen in den Benchmarks von Remio und erklären, warum wir die Schwelle zwischen LAN und WAN bei 15 ms RTT ansetzen – sie trennt direkte Pfade sauber von jedem Relay (mindestens 30 ms) oder Mobilfunkpfad (mindestens 40 ms), mit sehr wenigen Fehlklassifizierungen.

NAT Traversal ist eines jener Themen, bei denen die Protokolle einzeln einfach sind, die Kombinatorik aber knifflig ist. Die meisten Nutzer werden nie erfahren müssen, dass es ICE, STUN und TURN gibt – sie erleben einfach eine App, die von überall nach überall schnell verbindet. Die Protokolle machen ihren Job, wenn man sie nicht bemerkt. Wenn Sie sie doch bemerken – eine Sitzung braucht einen Moment zu lang, oder aus „Direkt“ wird „Relay“ –, haben Sie jetzt das mentale Modell.

Mehr zur nativen Pipeline von Remio und den Entscheidungen, die aus 1–5 ms Netzwerklatenz rund 8 ms Verarbeitung machen (der Rest ist der eigene 60-Hz-Bildtakt Ihres Displays), lesen Sie unter Warum nativ zählt. Das Bedrohungsmodell für Relay-Pfade finden Sie im Sicherheits-Whitepaper. Oder stöbern Sie in den Funktionen und laden Sie Remio, um es selbst zu erleben.