IKEv2 gebruikt UDP 500 en 4500: welke draagt de data?

UDP 500 openzetten in de firewall laat de tunnel onderhandelen, en daarna stopt de verbinding met het doorgeven van verkeer. De poortenlijst was onvolledig, niet fout. IKEv2 begint op de ene socket en gaat in veel echte implementaties verder op een andere, terwijl de payload helemaal geen poort hoeft te zijn. De fasen in volgorde lezen verklaart welke regel ontbreekt.

Twee poorten, twee taken

IKEv2 begint met een sleuteluitwisseling op UDP 500, waar de peers zich authenticeren en een beveiligingsassociatie voor de tunnel opzetten. Het datapad daarna is een aparte zaak: het kan native ESP zijn, een IP-protocolnummer en geen poort, of verkeer dat in UDP op 4500 is ingekapseld. Die twee gescheiden houden in een firewallbeoordeling is het verschil tussen een tunnel die onderhandelt en een tunnel die werkt. De ene socket draagt de besturing, de andere de payload.

Daarom levert een regel die alleen 500 toestaat het meest verwarrende symptoom in de hele protocolfamilie: de onderhandeling slaagt en er volgt niets nuttigs. De status toont een peer, het log toont een gevestigde IKE SA, en de toepassing loopt alsnog in een time-out. De ontbrekende toestemming hoort bij een andere stroom dan degene die zojuist slaagde.

Waarom 4500 überhaupt bestaat

Veel NAT-apparaten kunnen geen ander protocol dan TCP of UDP doorsturen, en sommige herschrijven adressen op manieren die de integriteitscontrole van ESP breken. ESP in UDP inkapselen lost beide problemen op, tegen de prijs van een extra header en een tweede poort die moet worden toegestaan. Die inkapseling is de reden dat de tweede poort überhaupt bestaat.

Zodra NAT wordt gedetecteerd, verhuist IKE zelf ook naar 4500 zodat al het verkeer één pad door de vertaler deelt. Een markering van vier bytes die geen ESP is, onderscheidt besturingsberichten van data op die socket. De overstap is een protocolbeslissing, niet een voorkeur van de beheerder.

Waar de bronpoort verandert

Een vertaler kan de bronpoort van de client herschrijven, waardoor de tuple die de server ziet niet overeenkomt met de tuple op de client. Kijk naar beide kanten van elke NAT-hop voordat je concludeert dat een regel wordt genegeerd. Problemen zoeken alleen op de client kan een regel opleveren die er juist uitziet en toch faalt.

MOBIKE-compatibele implementaties kunnen ook naar 4500 gaan zonder gedetecteerde NAT, en sommige implementaties forceren dat pad bewust. 4500 zien is daarom bewijs van een beslissing, geen bewijs van een thuisrouter.

Controleer beide stromen bij elke grens

Ga langs de drie grenzen: het clientnetwerk, elke tussenliggende firewall en de server. Elk heeft de stromen nodig die de implementatie documenteert, niet de stromen uit een artikel over een ander geval.

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

De ESP-regel in een firewalllijst is een protocolovereenkomst, dus een poortregel dekt die nooit. Als de beheerder een eigen poort gebruikt, volg dan de gedocumenteerde configuratie aan beide uiteinden, omdat een client geen listener op de server kan maken door een bekend nummer te kiezen.

Noteer waar de onderhandeling stopte en of een onderliggende beveiligingsassociatie is geïnstalleerd, want dat paar scheidt een geblokkeerd pad van een authenticatie- of beleidsfout. Herhaal daarna de test met serververificatie aan, want bereikbaarheid is geen authenticatie. Die laatste stap scheidt een toegestane poort van een vertrouwde peer.