WireGuard hinter CGNAT erreichbar machen: Erkennen, warum Port-Forwarding scheitert und welche Setups funktionieren

CGNAT eindeutig erkennen: Schritt für Schritt

Carrier-Grade NAT (CGNAT, auch NAT444 oder DS‑Lite‑AFTR im IPv6‑Umfeld) versteckt deine Anschluss‑IPv4 hinter einer weiteren NAT‑Schicht beim Provider. So findest du zuverlässig heraus, ob du betroffen bist:

1. Öffentliche IPv4 prüfen: Besuche eine Seite wie „ipv4.whatismyip.com“ oder „ipv4.icanhazip.com“. Notiere die dort gezeigte IPv4.
2. WAN/Internet‑IP im Router vergleichen: Öffne das Router‑Menü und lies die „WAN‑IP“ oder „Internet‑Adresse“ aus. Stimmen die Adressen nicht überein und liegt die WAN‑IP in 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 oder 100.64.0.0/10, dann sitzt du hinter CGNAT.
3. IPv6‑Status prüfen: Zeigt der Router „DS‑Lite“ oder erhältst du eine globale IPv6 (Beginn 2xxx:) aber keine öffentliche IPv4, ist eingehender Verkehr über IPv4 nicht möglich. Inbound geht dann nur nativ über IPv6 (sofern freigegeben).
4. Traceroute‑Indiz: Ein Traceroute zu einer externen IPv4 zeigt oft nach dem ersten/zweiten Hop Adressen aus 100.64.0.0/10 oder Hostnamen mit „aftr“. Das ist ein CGN/AFTR‑Knoten des Providers.
5. Port‑Test korrekt durchführen: Starte lokal einen Dienst (z. B. WireGuard auf Port 51820/UDP) und teste den Port von außen mit einem Port‑Checker. Bleibt der Port trotz laufendem Dienst „geschlossen/unsichtbar“, deutet das bei privater WAN‑IP stark auf CGNAT hin.

Wichtig: Ein fehlgeschlagener Port‑Test ist nur aussagekräftig, wenn der Dienst zur Testzeit aktiv lauscht. Andernfalls erhältst du unabhängig von CGNAT ein „geschlossen“.

Warum Port‑Forwarding hinter CGNAT technisch scheitert

Beim klassischen Port‑Forwarding setzt du im eigenen Router Regeln, die eingehende Pakete an ein internes Ziel weiterleiten. Hinter CGNAT existiert jedoch zusätzlich eine NAT‑Instanz im Netz des Providers. Diese Carrier‑NAT kennt keine Weiterleitungsregel für deinen Anschluss und verwirft alle aus dem Internet kommenden IPv4‑Pakete, die keinen bestehenden Verbindungszustand haben. UPnP/NAT‑PMP helfen hier nicht, weil sie nur deinen eigenen Router steuern – nicht die NAT‑Gateways des Providers.

Einige Provider unterstützen Port Control Protocol (PCP) an DS‑Lite‑AFTR‑Gateways, über das theoretisch öffentliche Ports dynamisch reserviert werden könnten. Im Massenmarkt ist PCP jedoch selten freigeschaltet und meist nicht dokumentiert. Ohne explizite PCP‑Freigabe oder gebuchte „öffentliche IPv4/Dual‑Stack“-Option bleibt eingehender IPv4‑Traffic blockiert – unabhängig davon, wie sauber deine lokalen Port‑Weiterleitungen konfiguriert sind.

Selbst wenn STUN/NAT‑Tests „Symmetric NAT“ melden, ist das allein kein Beweis für CGNAT – in Kombination mit einer privaten WAN‑IPv4 oder 100.64/10 ist es aber ein starkes Indiz, dass eingehende Verbindungen nicht aufgebaut werden können.

Typische Hinweise je Zugangstechnologie

• Kabel/FTTH: Häufig DS‑Lite (öffentliche IPv6, keine öffentliche IPv4). Im Router steht „DS‑Lite“, „AFTR“ oder die WAN‑IPv4 liegt in 100.64/10.
• Mobilfunk (4G/5G): Quasi immer CGNAT für IPv4. Öffentliche IPv6 oft vorhanden; IPv4 inbound nicht.
• Satellit: Weit verbreitetes CGNAT für IPv4; IPv6‑Verfügbarkeit variiert je Anbieter und Region.
• DSL: Je nach Provider/Tarif Dual‑Stack oder DS‑Lite. Wenn WAN‑IPv4 öffentlich ist, funktioniert Port‑Forwarding grundsätzlich; bei DS‑Lite nur über IPv6.
• Stadtwerke/Altnetz‑FTTH: Häufig standardmäßig CGNAT/DS‑Lite; teils buchbare Option „öffentliche IPv4/Dual‑Stack“.

Woran du es im Router-Menü sofort siehst

Öffne die Verbindungsübersicht deines Routers und prüfe: Steht bei IPv4 eine Adresse aus den privaten Bereichen oder 100.64/10, ist es CGNAT. Formulierungen wie „DS‑Lite aktiv“, „AFTR‑Gateway verbunden“ oder „NAT beim Anbieter“ sind klare Hinweise. Ein „Bridge‑Modus“ ist bei vielen CGNAT‑Anschlüssen nicht verfügbar; selbst wenn vorhanden, ändert er nichts an der fehlenden öffentlichen IPv4 – die Port‑Weiterleitung bleibt am Provider‑NAT hängen.

1) Outbound‑Only‑Tunnel: ohne eingehende Ports erreichbar

Wenn der Anschluss hinter CGNAT steckt, hilft ein reiner ausgehender Tunnel: Der Host baut selbst die Verbindung zu einem öffentlichen Knoten auf; eingehender Verkehr läuft über NAT‑Traversal oder einen Relay‑Fallback. In der Praxis löst das z. B. Tailscale (WireGuard‑basiert) mit STUN/UDP‑Hole‑Punching und DERP‑Relays. Headscale (self‑hosted Control‑Plane) oder Netmaker (Mesh mit Gateways/Relays) sind Alternativen.

Kurzsetup Tailscale (Beispiel): Paket installieren, dann tailscale up. Für Dienste ohne Portfreigabe nutzbar: tailscale serve (lokale HTTP/TCP‑Dienste veröffentlichen) und optional tailscale funnel aktivieren, um den Dienst über eine öffentliche Tailscale‑Domain erreichbar zu machen – trotz CGNAT.

2) Relay/Hub: zentrales Routing ohne direkte Peer‑Öffnung

Ein Relay/Hub ist ein Knoten mit öffentlicher IP, zu dem alle Peers ausgehend verbinden. Der Hub routet die Pakete zwischen den WireGuard‑Peers. Umsetzungsmöglichkeiten: ein eigener Linux‑Host mit WireGuard und aktiviertem IP‑Forwarding (net.ipv4.ip_forward=1, net.ipv6.conf.all.forwarding=1) oder eine Overlay‑Lösung mit integriertem Relay (z. B. Netmaker‑Relay, Tailscale‑DERP wenn direkte Verbindung scheitert).

Wichtig sind saubere Routen: Auf dem Hub erhält Peer A in AllowedIPs die WG‑Subnetze aller anderen Peers, und umgekehrt. Hinter CGNAT stehende Peers nutzen PersistentKeepalive=25, damit die NAT‑Zuordnung offen bleibt.

3) Eigener VPS‑Endpoint: voller Zugriff trotz CGNAT

Ein kleiner VPS mit öffentlicher IPv4/IPv6 dient als WG‑Server. Der Heim‑Host (CGNAT) stellt die Verbindung nach außen her; alle eingehenden Anfragen landen zunächst auf dem VPS und werden darüber ins Heimnetz getunnelt.

• VPS vorbereiten: UDP‑Port (z. B. 51820) in Firewall öffnen. Kernel‑Forwarding aktivieren.
• WireGuard konfigurieren: Server‑Interface z. B. 10.10.0.1/24, Heim‑Peer 10.10.0.2/24. Am Heim‑Peer Endpoint auf vps.example.tld:51820, PersistentKeepalive=25.
• Routen/NAT: Dienste durchreichen, z. B. per DNAT auf dem VPS (nftables) von :2222 auf 10.10.0.2:22 oder per Reverse‑Proxy (HTTP/S) zum internen Host.
• Optional: Exit‑Node/Bore‑Setup für ausgehenden Traffic über den VPS (Policy‑Routing/Split‑Tunnel je nach Bedarf).

Vorteil: volle Kontrolle, feste öffentliche Adresse, Port‑Mapping nach Wunsch. Achte auf Hardening (SSH‑Zugang, Firewall, automatische Updates) und Monitoring des Datenvolumens.

4) DDNS richtig einsetzen (inkl. IPv6)

DDNS löst das Problem nur, wenn der Zielhost tatsächlich öffentlich erreichbar ist. Hinter CGNAT hilft DDNS allein nicht – in Kombination mit einem VPS/Hub aber sehr wohl: Nutze für Endpoint einen Hostnamen, damit IP‑Änderungen des VPS automatisch greifen.

• Provider mit IPv4/IPv6‑Support wählen (z. B. deSEC, Cloudflare, dynv6).
• Bei nativem IPv6 ohne CGNAT kann der Heim‑Host direkt per AAAA‑Record erreichbar sein; Firewall und Privacy‑Extensions beachten.
• Tools: ddclient, inadyn oder API‑Script des DNS‑Providers.

Parameter, MTU und Always‑On‑Profile

• Keepalive: Für Peers hinter CGNAT PersistentKeepalive=25 setzen.
• MTU/MSS: Startwert MTU=1280, wenn Pfad unklar (Mobilfunk/PPPoE). Andernfalls 1420 üblich. TCP‑MSS clamping aktivieren (--clamp-mss-to-pmtu), um Fragmentierung zu vermeiden.
• Android Always‑On: Einstellungen → Netzwerk & Internet → VPN → Zahnrad beim WG‑Profil → „Immer‑aktiv‑VPN“ und optional „Verbindungen ohne VPN blockieren“.
• iOS On‑Demand: In der WireGuard‑App im Profil „On‑Demand“ aktivieren, „WLAN + Mobilfunk“ wählen und vertrauenswürdige SSIDs als Ausnahme definieren.
• Split‑Tunnel: Mit AllowedIPs steuern, welche Netze durch den Tunnel gehen (z. B. nur 10.10.0.0/24 und interne Dienste).

MTU korrekt wählen und MSS sauber klemmen

WireGuard kapselt IP über UDP. Die nutzbare MTU des Tunnels ergibt sich aus der Pfad‑MTU minus Kapselungs‑Overhead. Praxistaugliche Richtwerte: ca. 60 Byte Overhead bei IPv4‑Außenverbindung, ca. 80 Byte bei IPv6. Ein robuster Startwert, der in gemischten Netzen (IPv4/IPv6, DSL, Mobilfunk, CGNAT) sehr selten fragmentiert, ist MTU = 1420. Fällt ein Netz auf, das kleinere MTUs braucht (häufig bei Mobilfunk oder verschachtelten Tunneln), reduziere schrittweise in 20er‑Schritten bis 1280.

So gehst du vor, wenn Verbindungen hängen, Downloads abbrechen oder Webseiten nur teilweise laden (klassische MTU/MSS‑Probleme):

1. Setze in der Tunnel‑Datei (wg-quick) auf beiden Seiten explizit MTU = 1420. Bei DSL/PPPoE testweise MTU = 1412.
2. Aktiviere MSS‑Clamping auf dem Router/Gateway, das den Tunnel‑Verkehr routet, damit SYN‑Pakete eine zur MTU passende MSS aushandeln. Mit nftables z. B.: nft add rule inet filter forward tcp flags syn tcp option maxseg size set clamp to pmtu (sinngemäß für input/output, falls der Host selbst Endpunkt ist).
3. Wenn weiterhin Probleme bestehen: reduziere die WireGuard‑MTU in 20er‑Schritten (1400 → 1380 → 1360 → 1340 → 1320 → 1280) und teste erneut.
4. Optional: Prüfe die Pfad‑MTU mit ICMP‑Tests vom Tunnel‑Endpunkt zum Peer, z. B. IPv4 ping -M do -s 1472 <peer-public-ip> (1472+28=1500). Reduziere die Paketgröße, bis keine Fragmentierung mehr gemeldet wird, und leite daraus die Tunnel‑MTU ab (Außen‑PMTU minus 60/80).

Bei WireGuard‑Clients, die nur über den Tunnel surfen, genügt MSS‑Clamping auf der Seite, die den Verkehr ins Internet NATet. Für Site‑to‑Site‑Tunnels ist Clamping in beide Richtungen sinnvoll.

Keepalive‑Tuning hinter CGNAT

NATs und CGNAT vergessen UDP‑Zuordnungen nach kurzer Inaktivität. Setze auf der Seite hinter dem (C)GNAT im betreffenden [Peer] die Direktive PersistentKeepalive = 25. 25 Sekunden halten in der Praxis nahezu alle Carrier‑NATs offen, ohne den Akku spürbar zu belasten. In besonders aggressiven Netzen sind 15–20 s möglich; unter Heim‑NATs genügen 25–30 s. Keepalive nur dort setzen, wo die Verbindung nicht von außen initiiert werden kann – doppelt gesetzte Keepalives sind unnötig.

In Hub‑/Spoke‑Topologien (z. B. Clients → VPS‑Hub) reicht es, die Spokes (Clients, Relays hinter CGNAT) mit Keepalive auszustatten. Der Hub benötigt es nicht.

UDP‑Portwahl: unauffällig und kollisionsfrei

Der Standardport 51820/UDP ist technisch einwandfrei, aber oft von Scannern im Blick. Für öffentliche Endpunkte empfiehlt sich ein zufälliger hoher Port aus 49152–65535. 443/UDP funktioniert in Netzen, die nur “Web” erlauben, kollidiert aber mit HTTP/3 (QUIC). Nutze 443/UDP nur, wenn auf derselben IP kein HTTP/3 angeboten wird oder wenn ein separater Host/IPv4/IPv6 dafür reserviert ist.

Beachte zudem WLANs/Hotspots, die UDP pauschal drosseln oder blocken. Dort hilft nur ein alternativer Pfad (anderes Netz) oder ein Relay/VPS, das ausgehend erreichbar ist und den Verkehr weiterleitet.

• Öffentlicher VPS/Hub: hoher zufälliger UDP‑Port; bei HTTP/3 auf derselben IP nicht 443/UDP verwenden.
• Heimserver hinter CGNAT: freie Portwahl lokal egal; Portfilter sind nur am ausgehenden Pfad relevant, Keepalive ist entscheidend.

Always‑On‑Profile für Android und iOS

Für mobile Geräte lohnt sich ein Always‑On‑Setup, damit der Tunnel bei Netzwechseln (WLAN ↔ Mobilfunk) stabil bleibt und NAT‑Mappings nicht verfallen.

• Android (ab Android 8):
  • WireGuard‑App installieren und Tunnel einrichten.
  • Einstellungen → Netzwerk & Internet → VPN → Zahnrad am WireGuard‑Profil → “Immer‑aktiv‑VPN” einschalten.
  • Optional “Verbindungen ohne VPN blockieren” aktivieren (System‑Kill‑Switch).
  • Akkuschonung für die WireGuard‑App deaktivieren, damit Keepalives im Hintergrund laufen.
• iOS/iPadOS:
  • WireGuard‑App öffnen → Tunnel → “Bearbeiten”.
  • “On‑Demand” aktivieren und nach Bedarf konfigurieren: “Bei Mobilfunk verbinden”, “Bei WLAN verbinden”, SSID‑Ausnahmen/‑Whitelist.
  • Für Volltunnel AllowedIPs = 0.0.0.0/0, ::/0; für Split‑Tunnel nur benötigte Netze eintragen.

Für Roaming‑Stabilität auf Mobilgeräten ist zusätzlich PersistentKeepalive = 25 im Peer‑Block des Geräts sinnvoll. Kombiniert mit einer konservativen MTU (z. B. 1380) minimiert das Paketverluste beim Zellwechsel.