Hairpin NAT: Interner Zugriff auf öffentliche Dienste

Hairpin NAT (auch NAT Loopback oder U-Turn NAT) löst ein typisches Praxisproblem: Interne Clients sollen einen Dienst über die öffentliche IP/FQDN erreichen, obwohl Server und Clients im gleichen LAN stehen. Ohne Hairpin NAT „läuft“ der Traffic oft ins Leere, weil die öffentliche Adresse intern nicht sinnvoll geroutet wird oder der Rückweg nicht stimmt. Mit einer sauberen Hairpin-Konfiguration auf Cisco Routern stellst du sicher, dass interne Nutzer denselben Hostnamen nutzen können wie externe Nutzer – ohne separate DNS-Sonderlösungen.

Was ist Hairpin NAT?

Hairpin NAT bedeutet, dass Traffic von innen nach außen gerichtet aussieht (Ziel = öffentliche IP), aber tatsächlich wieder nach innen „zurückgebogen“ wird, um einen internen Server zu erreichen. Der Router führt dafür eine NAT-Übersetzung durch, sodass Hin- und Rückweg konsistent bleiben.

• Inside Client → Public IP/FQDN → Router → Inside Server
• Router übersetzt Ziel (und ggf. Quelle), damit Rückweg passt
• Gleicher Hostname intern/extern möglich

Prinzipdarstellung

$\text{192.168.10.50} \to \text{203.0.113.10:443} \circlearrowleft \text{192.168.10.10:443}$

Typische Symptome ohne Hairpin NAT

Ohne Hairpin NAT ist der Dienst von außen erreichbar, intern aber nicht – obwohl intern alles „im gleichen Netz“ ist. Oft funktionieren interne Zugriffe auf die private Server-IP, aber nicht auf die öffentliche IP oder den öffentlichen DNS-Namen.

• Extern: https://203.0.113.10 funktioniert
• Intern: Zugriff auf https://203.0.113.10 hängt/timeout
• Intern: Zugriff auf https://192.168.10.10 funktioniert
• DNS-Namen intern nicht nutzbar ohne Split-DNS

Wann Hairpin NAT sinnvoll ist – und wann Split DNS besser ist

Hairpin NAT ist sinnvoll, wenn du intern und extern exakt dieselbe öffentliche Adresse/FQDN nutzen willst und keine separate DNS-Logik betreiben möchtest. Split DNS ist häufig sauberer, wenn du viele Dienste hast oder wenn interne Pfade grundsätzlich intern bleiben sollen.

• Hairpin NAT: einheitlicher FQDN ohne DNS-Sonderfälle
• Split DNS: intern direkt auf private IP (effizienter, weniger NAT)
• Bei vielen Services ist Split DNS oft wartungsärmer

Beispiel-Topologie

Ein interner Webserver wird extern über Port Forwarding veröffentlicht. Interne Clients sollen denselben öffentlichen FQDN nutzen.

• Inside LAN: 192.168.10.0/24
• Client intern: 192.168.10.50
• Server intern: 192.168.10.10 (HTTPS)
• Public IP: 203.0.113.10 (externes Ziel)
• Router Inside: 192.168.10.1
• Router Outside: 203.0.113.2, Provider GW 203.0.113.1

Voraussetzung: Dienst ist extern per Port Forwarding erreichbar

Hairpin NAT baut auf einem bestehenden Static PAT/Port Forwarding auf. Prüfe zunächst, ob die externe Veröffentlichung korrekt ist.

Port Forwarding (Static PAT) für HTTPS

Router# configure terminal
Router(config)# ip nat inside source static tcp 192.168.10.10 443 203.0.113.10 443
Router(config)# end

Verifikation externes NAT-Mapping

Router# show ip nat translations | include 203.0.113.10
Router# show running-config | include ip nat inside source static tcp

Hairpin NAT Umsetzung: Ziel-Übersetzung plus konsistenter Rückweg

Für Hairpin NAT brauchst du typischerweise eine zusätzliche NAT-Regel, damit interne Clients beim Zugriff auf die öffentliche IP auf die interne Server-IP umgesetzt werden. Je nach IOS/NAT-Variante wird dafür häufig eine Policy-NAT/Route-Map genutzt, um gezielt „Inside→Inside“ Traffic zu übersetzen.

Schritt 1: ACL für Hairpin-Traffic definieren (Client → Public IP)

Die ACL matcht internen Client-Traffic, der als Ziel die öffentliche Service-IP hat. So wird Hairpin nur für diesen Spezialfall aktiv.

Router# configure terminal
Router(config)# ip access-list extended ACL-HAIRPIN
Router(config-ext-nacl)# permit tcp 192.168.10.0 0.0.0.255 host 203.0.113.10 eq 443
Router(config-ext-nacl)# end

Schritt 2: Policy-NAT (Hairpin) mit Route-Map aktivieren

Dieses Muster sorgt dafür, dass der Router den Zielzugriff auf die öffentliche IP intern passend behandelt. Das konkrete Verhalten kann je nach IOS/NAT-Engine variieren; das Prinzip ist: Match via Route-Map und gezielte Übersetzung.

Router# configure terminal
Router(config)# route-map RM-HAIRPIN permit 10
Router(config-route-map)# match ip address ACL-HAIRPIN
Router(config-route-map)# end

Schritt 3: Inside→Inside NAT-Regel setzen (Prinzipmuster)

Ein gängiger Ansatz ist, die öffentliche IP intern auf die private Server-IP abzubilden, damit Client-Traffic den Server erreicht und der Rückweg über den Router konsistent bleibt.

Router# configure terminal
Router(config)# ip nat inside source static tcp 192.168.10.10 443 203.0.113.10 443 extendable
Router(config)# end

Praktischer Best Practice: Split DNS als Alternative (oft einfacher)

Wenn Hairpin NAT in deiner Plattform/IOS-Variante komplex wird oder Seiteneffekte erzeugt, ist Split DNS häufig die sauberste Lösung: Intern zeigt der FQDN auf die private IP, extern auf die öffentliche IP.

• Internes DNS: service.example.com → 192.168.10.10
• Externes DNS: service.example.com → 203.0.113.10
• Vorteil: weniger NAT, bessere Performance im LAN

Verifikation: Hairpin funktioniert wirklich?

Du prüfst (1) DNS-Auflösung intern, (2) Zugriff vom Client auf die öffentliche IP/FQDN und (3) NAT-Translations auf dem Router. Zusätzlich testest du, ob Server-Logs die interne Client-IP oder eine NAT-IP sehen – je nach Design kann sich das unterscheiden.

Client-Test intern (FQDN/Public IP)

Client$ nslookup service.example.com
Client$ curl -vk https://203.0.113.10/
Client$ curl -vk https://service.example.com/

Router: NAT-Translations beobachten

Router# show ip nat translations | include 203.0.113.10|192.168.10.10
Router# show ip nat statistics

Typische Fehler und Stolperfallen bei Hairpin NAT

Hairpin NAT scheitert häufig an drei Dingen: fehlendes/unklares Match (Hairpin-ACL), falsche NAT-Reihenfolge (No-NAT vs. PAT), oder Security-Policies, die Inside→Inside Traffic anders behandeln als erwartet.

• Hairpin-ACL matcht nicht (falsches Ziel/Port)
• PAT-Regel greift „vor“ Hairpin-Regel (Policy-Reihenfolge)
• Inside-ACLs blockieren den Zugriff auf die public IP
• Server-Firewall blockiert Quellnetze oder SNI/Host Header passt nicht
• Mehrere NAT-Regeln konkurrieren (Static NAT + Pool + PAT)

Quick-Checks

show ip nat translations
show ip nat statistics
show running-config | include ip nat
show access-lists ACL-HAIRPIN
show route-map RM-HAIRPIN
show ip route 203.0.113.10
show ip route 192.168.10.10

Konfiguration speichern

Wenn interne Clients den öffentlichen FQDN stabil erreichen und die NAT-Translations wie erwartet erscheinen, speichere die Konfiguration.

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.