PPTP Through a Hotspot: TCP 1723 Is Only Half

Work through the checks in order: whether the control connection opens, whether GRE survives the path, whether the server accepts the call, and whether authentication completes. A PPTP client needs both a TCP session on 1723 and a GRE path carrying the data, and a hotspot can pass one while dropping the other. Doing them in order tells you which boundary to investigate instead of guessing. Windows error numbers do not do that for you.

GRE is IP protocol 47. It is not TCP or UDP port 47, and that distinction explains most of the confusion about firewalls.

Two Paths, One Connection

The control connection is an ordinary TCP session to destination port 1723, which most networks permit without complaint. The data path is GRE, protocol 47, and a firewall that allows the first can be completely unaware of the second. That combination produces a client which appears to start and then carries nothing, a far less informative symptom than a refused connection. Test both paths separately before concluding anything about the carrier.

Translation adds its own requirement. Port-sharing gateways often need a PPTP-aware ALG to rewrite call identifiers along with addresses, and one without it can mangle the session in ways that look like packet loss. That behaviour is common but implementation-specific, so treat any vendor limit as an example rather than as a property of every hotspot.

The Hotspot Adds Two More Boundaries

Client traffic usually crosses the phone's own sharing NAT and then a carrier-grade translation before reaching the server. A rule on the office router cannot repair a middlebox belonging to somebody else, which is why home-side port forwarding rarely helps. An outgoing client does not need an inbound port opened for it either; replies to a translated connection return through the state the gateway created. A server hosted behind NAT has a different set of requirements entirely.

A menu item labelled PPTP passthrough, where one exists, governs how that device handles this protocol. It is not the same feature as hosting a VPN on the phone or forwarding every protocol unconditionally, and enabling it is not a general permission to pass GRE.

Read 807 as an Interruption, Not a Verdict

Windows reports 807 as an interrupted connection, which describes the outcome rather than a cause. Its error table treats 806 separately as the GRE-related category, and that difference is worth knowing before building a theory. Neither number reveals whether the carrier filtered protocol 47, whether the server ran out of capacity, or whether the credentials were right. The error says the session ended; the path says where.

A browser test that succeeds on the hotspot only proves an ordinary application path works. It says nothing about GRE.

Isolate the Stage That Failed

Keep the laptop, the server and the profile fixed, then change only the access network to another approved one. If the result changes, capture the TCP and GRE exchanges at the boundaries you control and find the earliest stage that never happens: control establishment, call setup, data delivery, or PPP authentication. Each leaves a different signature in a capture. Comparing a working network against a failing one is far more informative than reading the error text again.

All of this diagnoses a deployment that already exists. It is no argument for standing up a new PPTP service, and the protocol cannot be negotiated around: installing a different client does not make an unchanged server speak something else.

For ongoing access, agree a supported migration with whoever owns the VPN. The checklist ends with a decision rather than a workaround.