PPTP split tunneling not working: fix the GRE path first

Watch a PPTP connection come up and it is easy to believe the hard part is done: the client authenticates, a ppp0 adapter or WAN Miniport appears, and the status window turns green. Then the first request to an internal host times out, and the profile gets blamed. In practice there are two independent layers to clear, the outer transport that carries TCP 1723 and GRE, and the inner policy that decides which destinations use the PPP interface. A green status only proves the first layer negotiated; it says nothing about the second.

Follow the client from profile to control socket

Open the client log and find the point where it contacts the server. PPTP first opens a TCP connection to port 1723 and negotiates tunnel parameters over that channel. If this step fails, nothing later matters, and the error usually names the server address or a timeout.

Confirm the control connection on the wire before you touch any route. On the client or a mirror port, capture TCP 1723 for one connection attempt:

sudo tcpdump -ni any 'tcp port 1723' -c 20

A completed handshake and an established session mean the outer control channel works. A SYN that never draws a SYN-ACK points at a firewall, a wrong server address, or a provider that filters the port. A handshake followed by an immediate reset often means the server rejected the credentials or the tunnel type.

GRE is a second protocol, not a port

PPTP carries the PPP payload inside enhanced GRE, IP protocol 47, which has no port number for a router to track. That is why a rule allowing TCP 1723 can still leave the tunnel with no data path. Stateful NAT devices need to understand the call ID inside GRE to map replies back, and many do not. The PPTP specification keeps the control channel and the GRE payload as separate pieces, and so must your test plan.

Watch for protocol 47 in the same capture, then compare what leaves with what returns:

sudo tcpdump -ni any 'proto gre' -c 20

Packets leaving with no replies, while TCP 1723 stays healthy, is the classic blocked-GRE signature. PPTP passthrough on a consumer router is a feature of that specific firmware, so a working hotel network proves nothing about the next one. If the router offers no passthrough and you cannot change it, the protocol choice is the problem, not the route table.

Prove the tunnel moves one packet

Once GRE flows, PPP negotiation assigns an address to the client interface. Read the assignment rather than assuming it:

ip -4 addr show ppp0

Ping the peer address shown as the destination of the point-to-point link. A reply at this stage proves the encapsulated path works end to end and that the server answers inside the tunnel. If the peer answers but internal hosts do not, the outer transport is fine and the failure has moved inward.

Do this before adding any split route. A route change made while the transport is broken produces a second variable and hides the first.

Write the split policy, DNS included

Split routing is a list of decisions, not a checkbox. Each private prefix that must cross the tunnel needs a route through the PPP interface, and each prefix that must stay local needs to be absent from it. A route for an application subnet without a matching route to its private resolver is a common way to create an outage that looks like a broken app.

Check the decision the kernel makes for one address in each category:

ip route get 10.20.5.10
ip route get 203.0.113.25

The first should name ppp0, the second the ordinary gateway. If both name the same interface, the policy is not split at all. Add the DNS server's own address to the tunneled list, otherwise name resolution for internal hosts leaves through the local resolver and returns nothing useful.

A repeatable check in five steps

Run the layers in order and stop at the first one that fails: control channel, GRE visibility, PPP peer reply, split route for one internal address, and an application request over the tunnel. Each step has its own command, so a failure is attributable instead of mysterious.

A compact version for a Linux client looks like this:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

On Windows the same order applies with route print and the adapter status shown in the client. PPTP is a legacy protocol, and if the server offers SSTP or IKEv2, moving is usually a better use of time than tuning a path that depends on protocol 47 passing every hop. Check the replacement's certificate and authentication contract instead of copying an old profile into a new release.