IKEv2 nutzt UDP 500 und 4500: Welcher Port trägt die Daten?

Wenn UDP 500 in der Firewall geöffnet wird, kann der Tunnel aushandeln, und danach hört die Verbindung auf, Verkehr durchzulassen. Die Portliste war unvollständig, nicht falsch. IKEv2 beginnt auf einem Socket und setzt sich in vielen realen Umgebungen auf einem anderen fort, während die Nutzlast überhaupt kein Port sein muss. Die Phasen der Reihe nach zu lesen erklärt, welche Regel fehlt.

Zwei Ports, zwei Aufgaben

IKEv2 beginnt mit einem Schlüsselaustausch auf UDP 500, bei dem sich die Peers authentifizieren und eine Sicherheitsassoziation für den Tunnel aufbauen. Der folgende Datenpfad ist eine separate Sache: Er kann natives ESP sein, also eine IP-Protokollnummer statt eines Ports, oder in UDP gekapselter Verkehr auf 4500. Diese Trennung in einer Firewall-Prüfung beizubehalten ist der Unterschied zwischen einem Tunnel, der aushandelt, und einem Tunnel, der funktioniert. Ein Socket trägt die Steuerung, der andere die Nutzlast.

Deshalb erzeugt eine Regel, die nur 500 erlaubt, das verwirrendste Symptom der ganzen Protokollfamilie: Die Aushandlung gelingt, und nichts Nützliches folgt. Der Status zeigt einen Peer, das Protokoll zeigt eine etablierte IKE SA, und die Anwendung läuft trotzdem in einen Timeout. Die fehlende Freigabe gehört zu einem anderen Fluss als dem, der gerade erfolgreich war.

Warum 4500 überhaupt existiert

Viele NAT-Geräte können kein anderes Protokoll als TCP oder UDP weiterleiten, und manche schreiben Adressen so um, dass die Integritätsprüfung von ESP bricht. ESP in UDP zu kapseln löst beide Probleme, zum Preis eines zusätzlichen Headers und eines zweiten freizugebenden Ports. Diese Kapselung ist der Grund, warum der zweite Port überhaupt existiert.

Sobald NAT erkannt wird, wechselt auch IKE selbst auf 4500, damit der gesamte Verkehr einen Pfad durch den Übersetzer teilt. Ein Marker aus vier Bytes, der kein ESP ist, unterscheidet Steuernachrichten von Daten auf diesem Socket. Der Wechsel ist eine Protokollentscheidung, keine Administratorvorliebe.

Wo sich der Quellport ändert

Ein Übersetzer kann den Quellport des Clients umschreiben, sodass das am Server sichtbare Tupel nicht mit dem Tupel am Client übereinstimmt. Betrachten Sie beide Seiten jedes NAT-Hops, bevor Sie schließen, dass eine Regel ignoriert wird. Fehlersuche nur am Client kann eine Regel ergeben, die korrekt aussieht und trotzdem scheitert.

MOBIKE-fähige Implementierungen können auch ohne erkanntes NAT auf 4500 wechseln, und manche Umgebungen erzwingen diesen Pfad bewusst. 4500 zu sehen ist daher ein Beleg für eine Entscheidung, kein Beweis für einen Heimrouter.

Beide Flüsse an jeder Grenze prüfen

Gehen Sie die drei Grenzen durch: das Clientnetz, jede zwischengeschaltete Firewall und den Server. Jede braucht die Flüsse, die die Umgebung dokumentiert, nicht die Flüsse aus einem Beitrag über einen anderen Fall.

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

Die ESP-Zeile in einer Firewall-Auflistung ist ein Protokolltreffer, daher deckt eine Portregel sie nie ab. Wenn der Betreiber einen eigenen Port verwendet, folgen Sie der dokumentierten Konfiguration an beiden Enden, denn ein Client kann keinen Listener auf dem Server erzeugen, indem er eine vertraute Nummer wählt.

Halten Sie fest, wo die Aushandlung stoppte und ob eine untergeordnete Sicherheitsassoziation installiert wurde, denn dieses Paar trennt einen blockierten Pfad von einem Authentifizierungs- oder Richtlinienfehler. Wiederholen Sie dann den Test mit aktivierter Serverprüfung, denn Erreichbarkeit ist keine Authentifizierung. Dieser letzte Schritt trennt einen erlaubten Port von einem vertrauenswürdigen Peer.