Skip to content

Est. 2011ยทMicrosoft Partner 7033487ยทDelivery under 3 minยทSupport 7 days a week

Your vault is empty.

License Error 806

VPN error 806: GRE protocol 47 blocked, and why PPTP should be retired

11 min read Updated October 4, 2026 Networking, Sharing & Printing

Fix it now

The PPTP control connection opened and the data channel never did. PPTP carries control traffic over TCP 1723 and its data over GRE, which is a protocol rather than a port, and networks drop GRE routinely. You can usually restore the tunnel by permitting GRE along the path, but Microsoft does not recommend PPTP and new Windows Server 2025 RRAS setups do not accept it.

Run this on the failing client, in PowerShell

Test-NetConnection vpnserver.example.com -Port 1723
  1. If the control port does not open either, stop here. The problem is broader than GRE and this is the wrong article.
  2. If TCP 1723 opens and the connection still dies, GRE is being filtered somewhere between the two machines. On the router in front of the client, enable whatever it calls PPTP or GRE passthrough; on the network in front of the server, permit the GRE protocol inbound.
  3. Prove where the filtering sits by testing the same laptop from a phone hotspot. Carrier networks performing large-scale address translation frequently cannot pass GRE at all, and there is no client-side fix for that.
  4. Treat any of that as a stopgap. On the VPN server, open the Routing and Remote Access console, expand the server, right-click Ports and choose Properties to see which tunnel types are configured and how many ports each has.
  5. Configure IKEv2 or SSTP on the server instead, update the client profiles, then disable the PPTP ports so nobody quietly falls back to them.

For a tunnel over TCP 443 the server needs a certificate whose subject or alternative name matches the address clients dial, and that port published to it. Sort the certificate before you move any users.

If the tunnel is up you can stop here. If it is not, or you want to know why this keeps happening on some networks and not others, the next section explains what makes GRE different.

Why it happens

Almost everything you permit through a firewall is TCP or UDP and you permit it by port number. GRE is neither. It is its own protocol number, so a rule that forwards ports does nothing for it, and a device performing address translation has to track GRE sessions specially in order to know which internal machine a reply belongs to. That special handling is what routers advertise as PPTP passthrough, and it is why the same tunnel works from one network and fails from the next.

The tracking also has a practical limit that surprises people. Simple translation devices commonly follow only one PPTP session at a time behind a single public address, so the first person to connect works and the second does not, and it clears the moment the first person disconnects. That is a property of how GRE is tracked, not a licence limit or a server capacity problem, and no setting on the VPN server changes it.

There is a larger reason to stop patching this. Microsoft’s own guidance for Routing and Remote Access says it does not recommend L2TP or PPTP due to their lack of security features, and that beginning with Windows Server 2025, new RRAS setups do not accept VPN connections based on PPTP and L2TP. Existing configurations keep working, including across an in-place upgrade, so nothing breaks under you – but you are maintaining something the vendor has pointed away from, on networks that are enforcing that view for you by dropping GRE.

The client’s own network drops GRE

You have this one if The same profile works from another network and fails from this one, with TCP 1723 reachable from both.

  1. Enable PPTP or GRE passthrough on the local router, usually a single option in its firewall or NAT section.
  2. Where somebody else manages the network, ask for the GRE protocol to be permitted outbound by name.
  3. Where it is a guest network, accept that it will not change and move to a tunnel that travels over TCP.

The carrier or provider will not pass it

You have this one if It fails on mobile data and on some home broadband regardless of the router, and works from a corporate line.

  1. Confirm by testing the same laptop on two different carriers.
  2. Accept that there is no client-side fix. Providers doing large-scale address translation frequently cannot pass GRE at all.
  3. Publish IKEv2 or SSTP and move the affected users onto it.

Two people are behind one public address

You have this one if Whoever connects first works, everybody after them gets 806, and it clears when the first person disconnects.

  1. Confirm it by having the first user disconnect and the second retry.
  2. Move to a tunnel that carries its data inside UDP or TCP, which several clients can share behind one address.
  3. Do not try to work around it with port forwarding. The limit is in how GRE is tracked, not in any port.

The server is no longer offering PPTP

You have this one if Everything looks configured, no port answers, and the server has recently been rebuilt or upgraded.

  1. In the Routing and Remote Access console, open the Ports node and read which tunnel types have inbound ports configured.
  2. Where PPTP was removed deliberately, leave it removed. Configure IKEv2 or SSTP and update the client profiles.
  3. Confirm the certificate and the published port for the replacement before moving anyone across.

On Windows Server 2025 a new RRAS installation does not accept PPTP or L2TP connections. That is the documented default, not a fault.

GRE is flowing and the failure is later in the sequence

You have this one if Codes 718, 731 or 628 rather than 806.

  1. Check that client and server agree on an authentication method, and that the protocol the connection needs is enabled in its networking settings.
  2. Check the server has free ports for the tunnel type in use. An exhausted pool produces an abrupt close.
  3. Read the server’s remote access log for the matching attempt, which names the stage that failed.

Full reference

What Microsoft actually says about PPTP now

Two statements, both from the Routing and Remote Access documentation, are worth having in front of you when somebody asks why the tunnel has to move. Beginning with Windows Server 2025, new RRAS setups do not accept VPN connections based on PPTP and L2TP protocols, though you can still enable them if necessary. And, in the same guidance: Microsoft does not recommend that you use L2TP or PPTP, due to their lack of security features. IKEv2 is the recommendation, with SSTP as the alternative.

Existing behaviour is preserved. If a Windows Server 2019 machine accepting PPTP is upgraded in place to Windows Server 2025, PPTP connections are still accepted afterwards. That is worth knowing before you plan a migration around a break that will not happen, and it is also why estates end up carrying PPTP for years after anyone chose it.

Reading the four companion codes

Code Published meaning What it tells you
721 Remote PPP peer is not responding The data channel is not reaching the far end, or nothing is answering on it
628 The port was disconnected The connection ended at the port; the log on the server says by whom
718 PPP timeout The link negotiation started and stalled, so traffic is flowing
731 The protocol is not configured A protocol the connection needs is not enabled on the client

The useful split is between 806 and the rest. 806 means the data channel never opened at all, which points at the path. The other four mean traffic reached the far end and something later went wrong, which points at configuration on one of the two machines.

Choosing the replacement

IKEv2 SSTP
Transport UDP 500 and UDP 4500 TCP 443
Survives restrictive networks Often not, because IPsec is widely filtered Usually, because it looks like ordinary TLS traffic
Reconnection after a network change Fast, which suits roaming laptops Slower, since the TLS session has to be rebuilt
What the server needs A machine certificate and the IPsec ports published A certificate matching the dialled name and TCP 443 published

Most organisations publish both and let the client choose, because the two fail in different circumstances. Where you have to pick one for roaming users on networks you do not control, the TLS-based tunnel is the pragmatic answer for exactly the reason this article exists: a tunnel that travels over a single common TCP port has far less to be blocked.

Retiring the old tunnel cleanly

  1. Stand up the new tunnel type alongside PPTP and test it from outside with a real user.
  2. Update the client profiles, by management tool where you have one, and leave PPTP configured while people move.
  3. Watch the server’s ports and remote access logs until nothing is connecting over PPTP.
  4. Set the PPTP ports to zero inbound connections in the Ports properties, so a stale profile fails cleanly rather than silently working.
  5. Remove the perimeter rule for TCP 1723 and any GRE permission you added, so the exception does not outlive its reason.

Do not leave GRE permitted through the perimeter once the tunnel has moved. The rule was added for one protocol on one path, it is easy to forget, and it is the kind of leftover that turns up in an audit years later with nobody able to say who asked for it.

When a licence is the actual fix

Where you control the path, permitting GRE costs nothing and buys you time, so do that and move on. The purchase question appears when the PPTP endpoint is a consumer router or a server old enough that it will never receive another security update, because neither can be moved to a tunnel type Microsoft still recommends. There the honest answer is a supported host for the remote access role: Windows Server 2022 Standard includes Routing and Remote Access, so IKEv2 or SSTP is a configuration exercise rather than another purchase, and it is licensed on the usual server plus client access licence model. Arco can check whether your existing CAL position already covers it. If your firewall appliance already offers a modern tunnel type, use that and buy nothing.

Every code this article covers

Code What it points at Source
806 Reported by the Windows VPN client when a PPTP connection’s data channel never opens, which in practice means GRE is filtered along the path. Microsoft publishes no meaning for the number itself not published by the vendor
721 Remote PPP peer is not responding Microsoft Learn
628 The port was disconnected Microsoft Learn
718 PPP timeout Microsoft Learn
731 The protocol is not configured Microsoft Learn

Confirm the fix worked

  1. Connect and confirm an internal address is issued and internal resources open by name.
  2. Have a second user connect from the same network at the same time, which the old tunnel could not manage behind one address.
  3. Test from a mobile hotspot, since that is the network most likely to have blocked the old tunnel.
  4. In the Routing and Remote Access console, confirm the session appears on the tunnel type you intended.
  5. Once everyone has moved, confirm the PPTP ports accept no inbound connections and the perimeter rule for TCP 1723 has been removed.

Questions people ask about this

Can I forward GRE like a port?

No. GRE has no ports, so port forwarding rules do not apply to it. A translation device has to track GRE sessions specially, which is what routers call PPTP passthrough, and many networks simply do not offer it.

Is PPTP really that bad?

Microsoft’s own Routing and Remote Access guidance says it does not recommend L2TP or PPTP due to their lack of security features, and new Windows Server 2025 RRAS setups do not accept either. That is the vendor pointing away from it, which is a better reason to move than any argument about the cryptography.

What should I move to?

Microsoft recommends IKEv2, with SSTP as the alternative. A TLS-based tunnel over TCP 443 travels through almost any network and suits roaming users; IKEv2 reconnects faster where the network permits it. Publishing both and letting the client choose is common.

Will upgrading the server break my existing PPTP tunnel?

Not by itself. Microsoft states that existing configurations retain their behaviour, so a Windows Server 2019 machine that accepts PPTP still accepts it after an in-place update to Windows Server 2025. It is new setups that do not.

Does moving away from PPTP mean buying a new server?

Only if the current endpoint cannot do anything else. A supported Windows Server or an existing firewall appliance can usually be configured for IKEv2 or SSTP without new hardware. Check what you already own before assuming a purchase.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

License Error Error 0x80070047: no more connections can be made to this remote computer License Error 0x80070032 and SMB1 shares: why old NAS boxes stop working in Windows Free Fix Remote Desktop cannot verify the identity: certificate error 0x80090325 Free Fix Error 0x80070052: the directory or file cannot be created on a share
โ† Back to Knowledge Base