PPTP Error 800 vs 812 and Drops After a Minute

Three failure messages from one PPTP client usually describe three different faults. Error 800 means the tunnel never formed, error 812 means the server rejected the authentication method, and a drop after a minute is a keepalive timer deciding that a healthy peer has gone away. Each stage fails for its own reason, so each one needs its own check.

Error 800 means the tunnel never formed

Windows raises error 800 when it cannot build the tunnel at all, and the text about an unreachable server or unsuitable security parameters is a summary rather than a diagnosis. PPTP needs two separate things from the network before any credential is examined. TCP 1723 carries the control channel, and IP protocol 47, GRE, carries the encapsulated payload.

Test that outer path from outside your own LAN, because a connection that works inside the office proves nothing about the edge:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

If 1723 answers and the capture stays empty while the client tries to connect, the path is dropping protocol 47. A router with 1723 forwarded but PPTP passthrough switched off produces exactly that pattern: the TCP handshake completes, then the GRE packets disappear, so the failure reads like a credential problem even though no logon was attempted.

Point the forward at the server's current LAN address, enable PPTP passthrough where the router offers it, and retry from the same outside vantage point. When GRE is filtered upstream and you cannot change that, SSTP over TCP 443 or L2TP/IPsec over UDP 500 and 4500 has a better chance than any change you can make on the Windows side.

Error 812 is the server rejecting your authentication method

Error 812 comes back after the tunnel is up, which is why it feels like a password problem. The server is refusing the authentication method negotiated for the connection, not necessarily the password itself. On the client, open the VPN entry, go to the Security tab, set the type to Point-to-Point Tunneling Protocol, choose the explicit protocol list, and tick Microsoft CHAP Version 2.

You can read the current setting without clicking through the dialog:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

A server that requires MS-CHAP v2 rejects a client left on PAP or on an automatic type that negotiates something weaker, and the error arrives before any user password is evaluated. The account format is the other half of the same rejection. In one case Windows sent a Microsoft account identity of the shape MicrosoftAccount\[email protected] while the server wanted a local or domain account. Typing SERVERNAME\username told Windows which account store to consult and cleared the error. Enter the name by hand instead of letting a saved credential replay a previous format.

Drops after a minute are a keepalive decision

When the tunnel connects, passes a little traffic and then disconnects, look at the server's LCP echo behaviour before you touch the client. The daemon periodically asks the peer to confirm it is still there. If too few replies arrive inside the configured budget, the session is torn down even though the user still has a working link.

On a Linux pptpd server those values live in /etc/ppp/options.pptpd, and the usual repair is to widen the budget rather than shorten the interval:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

Thirty misses at a five second interval forgive a brief stall rather than declaring the peer gone. Shrinking the count to one or two turns ordinary jitter on a translated path into a disconnect roughly every minute. If your server is Windows RRAS rather than pptpd, look at the PPP session timeout and the idle disconnect policy instead. Those live in a different place, and editing a pppd file that does not exist will change nothing.

Overlapping subnets break the data path

A PPTP tunnel can authenticate cleanly and still reach nothing when both sites use the same private range, for example 192.168.1.0/24 at the office and at home. The client cannot tell which host a given address refers to, and some stacks decline to install the route at all rather than pick one.

Treat that as a design fault and renumber one side, or hand the client a deliberately translated access range. Debugging the PPTP client cannot fix an address space that exists twice, and the symptom will keep looking like a random drop.

Start with the stage that failed: GRE for 800, the method and account string for 812, echo settings for a tunnel that dies on schedule.