MikroTik PPTP Drops? Fix the Route to the Server

A RouterOS PPTP client connects, moves a little traffic, and then goes dead, and the log looks like a credential or server problem. It is usually neither. The tunnel is carrying its own transport packets because the route to the server also matches the route the tunnel installed. The peer stops hearing from the router, and the session dies while the interface still claims to be up.

The fix is one route, or one setting, that keeps the server reachable over the physical WAN. Which one depends on whether the router is meant to be a full-tunnel gateway.

The symptom: connects, moves traffic, dies

The pattern repeats on every reconnect, which is the first useful clue. A rejected password fails before the interface comes up, a firewall misconfiguration usually blocks one direction, and a routing loop lets the interface establish and then strangles it. Watch the counters: the tunnel shows a burst of initial packets and then nothing, while the WAN interface keeps transmitting encapsulated copies. That is a router feeding its own output back into itself.

PPTP makes this easy to trigger because the transport is plain IP to the server's address, not a tunnel whose far end sits on another subnet. Anything that redirects that address redirects the transport with it.

Why the tunnel swallows its own packets

When the client connects, it installs a route whose gateway is the tunnel interface. If the profile also installs a default route, then every destination without a more specific match, including the server's public address, resolves to the tunnel. The router encapsulates the packet, addresses the outer packet to the server, and looks up the route again: same destination, same default, same tunnel. Depending on the release, that recursion is dropped, queued, or looped until the peer gives up and tears the session down.

Appliance vendors often add a host route for their own server automatically, precisely to avoid this. RouterOS does not assume it, so the operator has to express the exception or avoid the default route in the first place.

Pin the server address to the WAN

Add the narrowest possible route: a /32 for the server's public address, with the ISP gateway as next hop, on the interface that reaches the internet. A /32 beats any default by prefix length, and a lower distance wins if another route for the same prefix already exists. Then reconnect and confirm the route is active rather than merely present in the list.

/ip route add dst-address=198.51.100.10/32 gateway=192.0.2.1 distance=10

If the ISP gateway is learned by DHCP, use the gateway address that DHCP installed, or bind the route to the interface if the release supports it. A hardcoded gateway that changes on the next lease is a delayed failure. Check the address after a WAN reconnect, because that is when a stale gateway shows up and the tunnel starts dropping again.

Or stop the tunnel claiming the default

A branch that needs a single remote LAN should keep the PPTP profile away from the default route entirely. Turn that option off in the client profile and add a specific route for the remote prefix through the tunnel interface instead. Ordinary traffic stays on the WAN, the tunnel's own transport keeps its natural path, and the routing table becomes easier to explain. This is the better design for a branch that needs one subnet, not for a router that is supposed to be the site's exit.

Full tunnel has its own requirements: policy routing for selected sources, a plan for return traffic, and a decision about what happens when the tunnel drops. None of that is solved by the host route, which only keeps the transport alive.

Verify in layers, then close the management hole

Test in layers: ping the server's public address before connecting, ping the remote gateway after connecting, then ping a host on the remote LAN. Add masquerade on the tunnel interface if hosts behind the router need replies to come back through it.

/ip firewall nat add chain=srcnat out-interface=pptp-out1 action=masquerade

Then reboot the router or force a WAN reconnect and repeat the three pings, because a route that only exists in the running configuration will not survive. A configuration exported to a backup file and restored later is the other place this breaks, since the route may be missing from the export if it was added at runtime.

Finally, restrict Winbox and web management to known source addresses before publishing any VPN or route change. A router that terminates tunnels is a management target, and port 80 open to the world is a bigger finding than the route you just fixed.