Welke VPN-poorten u op een firewall moet openen: protocol voor protocol

Twee afzonderlijke regels bepalen of een VPN-tunnel een firewall overleeft: de poort die de client kiest en het protocol dat de lading draagt. Open alleen de eerste en de tunnel authenticeert, maar verplaatst daarna geen data. Het minimum is één TCP-poort plus GRE voor PPTP, twee UDP-poorten plus ESP voor L2TP/IPsec en IKEv2, en één poort voor SSTP, OpenVPN en WireGuard. Richting, toestandstracking en NAT bepalen de rest.

Begin bij de poort die de client kiest

Elke familie heeft een ingangspunt dat de client als eerste benadert, en dat ingangspunt is wat uw toelatingsregel moet noemen. PPTP-clients verbinden met TCP 1723. L2TP/IPsec start IKE op UDP 500 en stapt over op UDP 4500 zodra NAT-traversal wordt gebruikt, terwijl het L2TP-frame zelf op UDP 1701 in de tunnel zit. SSTP wikkelt de sessie in TLS op TCP 443, IKEv2 onderhandelt op UDP 500 en 4500, OpenVPN gebruikt standaard UDP 1194 maar wordt vaak naar TCP 443 verplaatst, en WireGuard luistert op UDP 51820.

Behandel die nummers als standaardwaarden en niet als vaste eigenschappen. Een WireGuard-interface gebruikt welke luisterpoort zijn configuratie ook vermeldt, en een OpenVPN-server kan op elke poort staan die de beheerder koos. Lees de serverconfiguratie voordat u de regel schrijft, want een firewall die voor 1194 is geopend doet niets voor een server die naar 443 is verplaatst.

De derde kolom is waar de meeste wijzigingstickets misgaan. De regel bestaat, maar wijst naar de verkeerde bestemming, de verkeerde richting of het verkeerde transport.

GRE en ESP zijn protocolnummers, geen poorten

GRE en ESP hebben helemaal geen poorten, dus een firewallformulier dat alleen poortnummers accepteert kan ze niet uitdrukken. GRE is IP-protocol 47 en ESP is IP-protocol 50, beide worden gematcht via het protocolveld in de IP-header. Een regel die als TCP-poort 47 is geschreven matcht niets, en zo ziet een PPTP-beleid er correct uit en laat toch elk pakket na de handdruk vallen.

Consumentenrouters verbergen dit achter een doorgiftevakje dat de protocolregel installeert en, voor GRE, de NAT-helper die nodig is om de stroom in kaart te brengen. Op een echte firewall voegt u het protocol zelf toe: sta IP-protocol 47 toe naar de PPTP-server, sta IP-protocol 50 toe naar de IPsec-gateway. Waar het platform geen protocolveld biedt, is inkapseling de uitweg, daarom kan IKEv2 terugvallen op UDP 4500 en daarom lopen OpenVPN en WireGuard nooit tegen het probleem aan.

Controleer waar de regel werkelijk op matcht voordat u de client de schuld geeft. Een pakketteller die op de gateway op nul blijft staan zegt dat de regel nooit is afgegaan, en geen enkele herinstallatie aan de clientkant verandert dat.

Richting, toestand en NAT veranderen het antwoord

Een client die naar buiten kiest en een gateway die naar binnen luistert zijn verschillende eisen, en dezelfde poortenlijst kan in de ene richting kloppen en in de andere fout zijn. Een stateful firewall volgt de UDP-stroom op 500 en 4500 en laat antwoorden terug zonder tweede regel. ESP en GRE dragen geen poorten, dus een NAT-apparaat heeft niets om op aan te grijpen en heeft een helper of inkapseling nodig om de sessie te volgen.

NAT-traversal is het deel dat wordt vergeten. IKEv2 begint op UDP 500, detecteert een NAT-apparaat en gaat verder op UDP 4500, dus een beleid dat alleen 500 toestaat geeft een tunnel die opkomt en daarna stil wordt. L2TP/IPsec maakt dezelfde beweging. Als uw capture de eerste uitwisseling toont maar geen aanhoudend verkeer, zoek dan een regel die bij 500 stopt.

Noteer de richting bij elke regel. ‘UDP 4500 toestaan’ betekent niets tot u zegt van waar naar waar, en een regel die juist is voor een roamende client is meestal fout voor een site-naar-site-partner.

Controleer elk pad met een capture

Voer de capture uit op de gateway, niet op de client: een client registreert alleen wat is aangekomen. Deze filters dekken de families hierboven en tonen welke fase ontbreekt:

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

Lees de uitvoer als een reeks. Wanneer de onderhandeling verschijnt maar het ladingsprotocol niet, gebeurt de drop ergens tussen client en gateway. Wanneer beide verschijnen en de pagina toch faalt, is de firewall niet langer verdacht; kijk naar routing, DNS of de adrespool die de client kreeg.

Op een machine zonder tcpdump komen dezelfde bewijzen uit interface- en regeltellers. Bytes die binnenkomen maar niet weggaan op de tunnelinterface wijzen op de terugweg en niet op de oorspronkelijke toelatingsregel.

Laat een regelset achter die u kunt verdedigen

SSTP op TCP 443 is voor elk poortgebaseerd filter niet te onderscheiden van gewone HTTPS, en dat is precies de bedoeling wanneer een netwerk alleen webverkeer toestaat. Daarom moet de 443-regel de gateway als bestemming noemen in plaats van het hele internet. Verwijder tijdelijke regels van alles-naar-alles zodra de tunnel werkt. Noteer welke regel matchte, het protocolnummer waar dat er is, en de richting, zodat de volgende persoon met bewijs begint.

Cloudgateways van punt naar site maken de keuze zichtbaar: het gedownloade profiel gebruikt ofwel SSTP op 443 of IKEv2 op 500 en 4500, en u moet alleen openen wat het profiel werkelijk kiest. PPTP is de GRE-uitzondering in een modern netwerk niet waard, omdat mobiele providers protocol 47 vaak laten vallen ongeacht uw firewall. Bevestig voordat u het ticket sluit dat de regel overeenkomt met de poort in de serverconfiguratie, dat het protocolveld is ingesteld waar de familie het nodig heeft en dat de bestemming de gateway is en niet zomaar een adres.