PPTP Passthrough Missing: Fix Windows VPN Error 807

Forwarding TCP 1723 often clears the first part of PPTP and leaves the rest broken, so Windows still returns error 807 on the attempt. The next instinct is to add a rule for port 47, and that is the step that wastes an afternoon: GRE is a protocol number in the IP header, not a port a forwarding table can match. Until the router passes protocol 47 and ties it to the same call, the tunnel cannot start. The sections below separate the two channels, then test them one at a time.

A port table has no row for a protocol number

PPTP uses two conversations that fail in different ways. The one on TCP 1723 starts the call, passes link information and tears it down when the user disconnects. The payload side runs inside GRE, which the IP header labels with protocol number 47, and inside that tunnel PPP negotiates the link while MS-CHAPv2 checks the credentials.

Because GRE carries no transport header, it exposes no ports, so a rule written for ports has nothing to match. A router that forwards 1723 creates a mapping for that TCP session and stops there. Firmware that handles the second half calls the feature PPTP passthrough or a PPTP ALG, and some firmware offers neither and never mentions the gap. The label on the checkbox matters less than whether protocol 47 is recognised at all.

What Windows reports when the data path dies

Error 807 says the connection could not be completed, which in practice means the call reached the server and the data channel did not come up. It is a transport verdict rather than a verdict on the account. Error 691 is the one that points at credentials or at an authentication protocol mismatch, so it sends you somewhere else entirely.

Work on the transport before touching the password. Changing credentials to chase 807 leaves the real fault in place and makes the next attempt harder to read.

Why a second client breaks a working tunnel

With no ports to distinguish them, a NAT device cannot separate two PPTP clients the way it separates two HTTPS sessions. Many consumer devices therefore allow one PPTP call and track it by source address. A laptop that worked alone stops completing once a second machine dials out, and from the client side the failure looks random. That pattern belongs to the firmware, and no profile change will alter it.

Watch the connection table while both clients dial. If only the first host ever holds a mapping, the router has reached the edge of what it supports and no client-side setting will move it.

Prove which half is failing

Confirm that TCP 1723 arrives before changing anything on the router, because that answer decides which half you are testing. Run these from the Windows client against your own server name. The first prints whether the port answered, and the second dials without a dialog, which makes repeated attempts comparable.

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

A true result on the port test means the control channel is open and GRE is the remaining suspect. A false result means routing, a filter or the forward is broken, and no GRE change will rescue that. The data side has to be watched where it can be seen, at the server end or at the router.

tcpdump -ni any proto 47

The Wireshark equivalent is the display filter ip proto 47, which is easier to hand to someone who is not comfortable on a shell. GRE that arrives with nothing leaving in reply means the return path needs fixing.

What actually fixes the error

Where the router exposes the setting, enable PPTP passthrough, or permit protocol 47 explicitly on firmware that accepts rules. On RouterOS the forward rule matches the protocol directly, which is what a port-based forward could never do. Consumer firmware usually hides the same decision behind a checkbox, sometimes under security settings rather than under port forwarding. If no such control exists, nothing on the client will compensate.

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

Replacing PPTP is the other option and often the cheaper one. A router that terminates the VPN itself avoids double NAT for inbound clients, and a protocol a port-based NAT already handles needs no passthrough at all: OpenVPN over UDP, SSTP over TCP 443, or L2TP/IPsec with NAT-T wrapping ESP in UDP 4500. PPTP also depends on MS-CHAPv2, whose documented weaknesses make it a poor choice for a new deployment even after the error clears.

Write down which rule made the difference, because the same site will meet the same limit when the second user asks for access. A protocol-level fix belongs in the network notes, where the next engineer will look.