PPTP-passthrough ontbreekt: los Windows VPN-fout 807 op

Het doorsturen van TCP 1723 opent vaak het eerste deel van PPTP en laat de rest kapot, zodat Windows bij de poging nog steeds fout 807 teruggeeft. De volgende reflex is een regel voor poort 47 toevoegen, en juist die stap kost een middag: GRE is een protocolnummer in de IP-header, geen poort die een doorstuurtabel kan matchen. Tot de router protocol 47 doorlaat en aan dezelfde oproep koppelt, kan de tunnel niet starten. De secties hieronder scheiden de twee kanalen en testen ze daarna een voor een.

Een poorttabel heeft geen rij voor een protocolnummer

PPTP gebruikt twee gesprekken die op verschillende manieren mislukken. Dat op TCP 1723 start de oproep, geeft linkinformatie door en breekt het af wanneer de gebruiker de verbinding verbreekt. De payload-kant draait binnen GRE, dat de IP-header met protocolnummer 47 markeert, en binnen die tunnel onderhandelt PPP over de link terwijl MS-CHAPv2 de inloggegevens controleert.

Omdat GRE geen transportheader draagt, toont het geen poorten, dus een regel die voor poorten is geschreven heeft niets om te matchen. Een router die 1723 doorstuurt, maakt een mapping voor die TCP-sessie en stopt daar. Firmware die de tweede helft afhandelt, noemt de functie PPTP-passthrough of PPTP ALG, en sommige firmware biedt geen van beide en noemt de leemte nooit. Het label op het selectievakje is minder belangrijk dan of protocol 47 sowieso wordt herkend.

Wat Windows meldt wanneer het datapad sterft

Fout 807 zegt dat de verbinding niet tot stand kon worden gebracht, wat in de praktijk betekent dat de oproep de server bereikte en het datakanaal niet omhoogkwam. Het is een oordeel over het transport, niet over het account. Fout 691 is degene die wijst op inloggegevens of op een mismatch in het authenticatieprotocol, dus die stuurt je ergens heel anders heen.

Werk aan het transport voordat je het wachtwoord aanraakt. Inloggegevens wijzigen om 807 te achtervolgen laat de echte fout op zijn plaats en maakt de volgende poging moeilijker te lezen.

Waarom een tweede client een werkende tunnel breekt

Zonder poorten om ze te onderscheiden, kan een NAT-apparaat twee PPTP-clients niet scheiden zoals het twee HTTPS-sessies scheidt. Daarom staan veel consumentenapparaten één PPTP-oproep toe en volgen die op bronadres. Een laptop die alleen werkte, maakt niets meer af zodra een tweede machine belt, en vanaf de clientkant lijkt de storing willekeurig. Dat patroon hoort bij de firmware, en geen profielwijziging zal het veranderen.

Houd de verbindingstabel in het oog terwijl beide clients bellen. Als alleen de eerste host ooit een mapping heeft, heeft de router de grens van zijn ondersteuning bereikt en geen enkele instelling aan de clientkant verplaatst dat.

Bewijs welke helft faalt

Controleer dat TCP 1723 aankomt voordat je iets op de router wijzigt, want dat antwoord bepaalt welke helft je test. Voer deze uit vanaf de Windows-client tegen je eigen servernaam. De eerste drukt af of de poort antwoordde, en de tweede belt zonder dialoogvenster, wat herhaalde pogingen vergelijkbaar maakt.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

Een waar resultaat in de poorttest betekent dat het controlekanaal open is en dat GRE de resterende verdachte is. Een onwaar resultaat betekent dat routing, een filter of de doorsturing kapot is, en geen GRE-wijziging redt dat. De datakant moet worden geobserveerd waar die zichtbaar is, op de server of op de router.

tcpdump -ni any proto 47

Het equivalent in Wireshark is het weergavefilter ip proto 47, dat makkelijker is om aan iemand te geven die zich niet prettig voelt op een commandoregel. GRE dat aankomt zonder dat er iets in antwoord uitgaat, betekent dat de retourweg gerepareerd moet worden.

Wat de fout werkelijk verhelpt

Waar de router de instelling toont, schakel PPTP-passthrough in, of sta protocol 47 expliciet toe op firmware die regels accepteert. Op RouterOS matcht de doorstuurregel het protocol direct, wat een poortgebaseerde doorsturing nooit zou kunnen. Consumentenfirmware verbergt dezelfde beslissing meestal achter een selectievakje, soms onder beveiligingsinstellingen in plaats van onder poortdoorschakeling. Als zo'n controle niet bestaat, compenseert niets op de client dat.

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

PPTP vervangen is de andere optie en vaak de goedkoopste. Een router die de VPN zelf beëindigt, vermijdt dubbele NAT voor inkomende clients, en een protocol dat een poortgebaseerde NAT al aankan, heeft helemaal geen passthrough nodig: OpenVPN over UDP, SSTP over TCP 443 of L2TP/IPsec met NAT-T dat ESP in UDP 4500 verpakt. PPTP is ook afhankelijk van MS-CHAPv2, waarvan de gedocumenteerde zwaktes het een slechte keuze maken voor een nieuwe uitrol, zelfs nadat de fout verdwenen is.

Noteer welke regel het verschil maakte, want dezelfde locatie zal tegen dezelfde grens aanlopen wanneer de tweede gebruiker toegang vraagt. Een correctie op protocolniveau hoort in de netwerknotities, waar de volgende engineer zal kijken.