Welche VPN-Ports in einer Firewall zu öffnen sind: Protokoll für Protokoll

Zwei getrennte Regeln entscheiden, ob ein VPN-Tunnel eine Firewall übersteht: der Port, den der Client anwählt, und das Protokoll, das die Nutzlast trägt. Öffnet man nur den ersten, authentifiziert sich der Tunnel und überträgt danach keine Daten mehr. Das Minimum ist ein TCP-Port plus GRE für PPTP, zwei UDP-Ports plus ESP für L2TP/IPsec und IKEv2 sowie ein einziger Port für SSTP, OpenVPN und WireGuard. Richtung, Zustandsverfolgung und NAT entscheiden über den Rest.

Beginne mit dem Port, den der Client anwählt

Jede Familie hat einen Einstiegspunkt, den der Client zuerst kontaktiert, und genau diesen Einstiegspunkt muss die Allow-Regel benennen. PPTP-Clients verbinden sich mit TCP 1723. L2TP/IPsec startet IKE auf UDP 500 und wechselt auf UDP 4500, sobald NAT-Traversal im Einsatz ist, während der L2TP-Rahmen selbst auf UDP 1701 im Tunnel liegt. SSTP packt die Sitzung in TLS auf TCP 443, IKEv2 verhandelt auf UDP 500 und 4500, OpenVPN nutzt standardmäßig UDP 1194, wird aber oft auf TCP 443 verschoben, und WireGuard lauscht auf UDP 51820.

Behandle diese Zahlen als Vorgaben und nicht als feste Eigenschaften. Eine WireGuard-Schnittstelle verwendet den Lauschport, den ihre Konfiguration angibt, und ein OpenVPN-Server kann auf jedem Port sitzen, den der Administrator gewählt hat. Lies die Serverkonfiguration, bevor du die Regel schreibst, denn eine Firewall, die für 1194 geöffnet wurde, bewirkt nichts für einen Server, der auf 443 umgezogen ist.

Die dritte Spalte ist der Punkt, an dem die meisten Change-Tickets schiefgehen. Die Regel existiert, zeigt aber auf das falsche Ziel, die falsche Richtung oder den falschen Transport.

GRE und ESP sind Protokollnummern, keine Ports

GRE und ESP haben überhaupt keine Ports, daher kann ein Firewall-Formular, das nur Portnummern annimmt, sie nicht ausdrücken. GRE ist IP-Protokoll 47 und ESP ist IP-Protokoll 50, beide werden über das Protokollfeld im IP-Header abgeglichen. Eine als TCP-Port 47 geschriebene Regel trifft nichts, und so sieht eine PPTP-Richtlinie korrekt aus und verwirft trotzdem jedes Paket nach dem Handshake.

Consumer-Router verstecken das hinter einem Passthrough-Kästchen, das die Protokollregel installiert und bei GRE den NAT-Helfer, der zum Abbilden des Flusses nötig ist. Auf einer echten Firewall fügst du das Protokoll selbst hinzu: erlaube IP-Protokoll 47 zum PPTP-Server, erlaube IP-Protokoll 50 zum IPsec-Gateway. Wo die Plattform kein Protokollfeld bietet, ist Kapselung der Ausweg, weshalb IKEv2 auf UDP 4500 zurückfallen kann und weshalb OpenVPN und WireGuard nie auf das Problem stoßen.

Prüfe, worauf die Regel tatsächlich passt, bevor du den Client beschuldigst. Ein Paketzähler, der am Gateway auf null bleibt, sagt, dass die Regel nie ausgelöst wurde, und keine Menge an Neuinstallation auf Clientseite ändert das.

Richtung, Zustand und NAT ändern die Antwort

Ein Client, der hinauswählt, und ein Gateway, das eingehend lauscht, sind verschiedene Anforderungen, und dieselbe Portliste kann in der einen Richtung richtig und in der anderen falsch sein. Eine zustandsbehaftete Firewall verfolgt den UDP-Fluss auf 500 und 4500 und lässt Antworten ohne zweite Regel zurück. ESP und GRE tragen keine Ports, daher hat ein NAT-Gerät nichts, woran es ansetzen kann, und braucht einen Helfer oder eine Kapselung, um der Sitzung zu folgen.

NAT-Traversal ist der Teil, der übersehen wird. IKEv2 beginnt auf UDP 500, erkennt ein NAT-Gerät und fährt auf UDP 4500 fort, sodass eine Richtlinie, die nur 500 erlaubt, einen Tunnel liefert, der sich aufbaut und dann verstummt. L2TP/IPsec macht denselben Schritt. Wenn dein Mitschnitt den ersten Austausch zeigt, aber keinen anhaltenden Verkehr, suche nach einer Regel, die bei 500 endet.

Halte die Richtung bei jeder Regel fest. „UDP 4500 erlauben“ bedeutet nichts, solange du nicht sagst, von wo nach wo, und eine Regel, die für einen roaming Client richtig ist, ist für einen Site-to-Site-Peer meist falsch.

Prüfe jeden Pfad mit einem Mitschnitt

Führe den Mitschnitt am Gateway aus, nicht am Client: ein Client zeichnet nur auf, was angekommen ist. Diese Filter decken die obigen Familien ab und zeigen, welche Stufe fehlt:

sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50

Lies die Ausgabe als Abfolge. Wenn die Aushandlung auftaucht, das Nutzlastprotokoll aber nicht, passiert der Verlust irgendwo zwischen Client und Gateway. Wenn beides erscheint und die Seite weiterhin scheitert, ist die Firewall nicht mehr verdächtig; schau auf Routing, DNS oder den Adresspool, den der Client erhalten hat.

Auf einer Kiste ohne tcpdump liefern Interface- und Regelszähler dieselben Belege. Bytes kommen herein, gehen aber nicht hinaus auf der Tunnelschnittstelle — das deutet auf den Rückweg hin und nicht auf die ursprüngliche Allow-Regel.

Hinterlasse einen Regelsatz, den du verteidigen kannst

SSTP auf TCP 443 ist für jeden portbasierten Filter nicht von gewöhnlichem HTTPS zu unterscheiden, und genau das ist der Sinn, wenn ein Netz nur Webverkehr erlaubt. Deshalb sollte die 443-Regel das Gateway als Ziel nennen statt das ganze Internet. Lösche temporäre Regeln von irgendwo nach überall, sobald der Tunnel läuft. Notiere, welche Regel gepasst hat, die Protokollnummer, wo es eine gibt, und die Richtung, damit die nächste Person mit Belegen beginnt.

Cloud-Gateways für Punkt-zu-Standort machen die Wahl sichtbar: das heruntergeladene Profil nutzt entweder SSTP auf 443 oder IKEv2 auf 500 und 4500, und du solltest nur das öffnen, was das Profil tatsächlich wählt. PPTP ist die GRE-Ausnahme in einem modernen Netz nicht wert, da Mobilfunknetze Protokoll 47 oft verwerfen, unabhängig von deiner Firewall. Bevor du das Ticket schließt, bestätige, dass die Regel zum Port in der Serverkonfiguration passt, dass das Protokollfeld dort gesetzt ist, wo die Familie es braucht, und dass das Ziel das Gateway und nicht irgendeine Adresse ist.