Implementing a split-tunnel VPN with the Point-to-Point Tunneling Protocol (PPTP) remains relevant in legacy environments where compatibility and simplicity are prioritized. While PPTP has well-known security limitations, it can still serve certain administrative and development scenarios when combined with strict network controls. This article walks through a practical, technical, step-by-step approach to configuring PPTP VPN for split-tunnel access on a Linux server and common clients, with detailed network, firewall, and routing considerations.

Understanding split-tunnel with PPTP

Split-tunneling means only specific traffic (for example, traffic destined for corporate subnets) is routed through the VPN tunnel, while all other traffic uses the client’s normal Internet connection. For PPTP this behavior is achieved by controlling the routes pushed to the client and by manipulating local routing tables on the client. Key advantages include reduced load on your VPN gateway and lower latency for non-business traffic. Key disadvantages include reduced privacy and the possibility of split-path routing issues.

Security note

Before proceeding, be explicit: PPTP is considered cryptographically weak because of vulnerabilities in MS-CHAPv2 and the MPPE key management. For production environments requiring strong confidentiality and integrity, prefer modern protocols such as OpenVPN, WireGuard, or IKEv2. Use PPTP only for legacy client compatibility, testing, or when controlled compensating controls (e.g., strict firewall rules, network segmentation, application-layer access controls) are in place.

Prerequisites and environment assumptions

  • Linux server (Debian/Ubuntu or CentOS/RHEL) with public IP address.
  • Root or sudo access to install packages and modify sysctl and firewall rules.
  • PPTP client(s) running Windows, macOS (legacy), or Linux.
  • Network plan: decide which internal subnets should traverse VPN (e.g., 10.10.0.0/16) and which should not.
  • Firewall policy permitting GRE (protocol 47) and TCP port 1723 to the VPN server.

Server-side setup

The example below uses pptpd on a Debian/Ubuntu host. Adjust package names for other distributions (e.g., pptpd is common across major Linux distros).

Install and enable packet forwarding

Install pptpd and required utilities, enable IP forwarding, and ensure kernel parameters accept forwarding for IPv4.

Commands (example):

sudo apt-get update && sudo apt-get install -y pptpd iptables

Edit /etc/sysctl.conf (or echo to /proc temporarily):

net.ipv4.ip_forward = 1

Apply changes:

sudo sysctl -p

Configure PPTP daemon

Edit /etc/pptpd.conf and configure local and remote IP pools. The local IP is the server endpoint; remote IPs are assigned to clients.

Example snippet:

localip 192.0.2.1
remoteip 192.0.2.100-192.0.2.200

Choose an IP pool that does not conflict with existing networks.

Authentication and options

Define user credentials in /etc/ppp/chap-secrets:

username pptpd password *

Configure PPP options in /etc/ppp/pptpd-options. Important settings for split-tunnel behavior and reliability:

  • ms-dns 10.10.0.10 — push internal DNS server IP to clients if you want domain resolution to go over VPN.
  • mtu 1400 and mru 1400 — helps avoid fragmentation across tunnels.
  • nodefaultroute — critical for split-tunnel. This prevents pppd from altering the default route on the server-side; the primary point is the client controls which routes are added.
  • proxyarp — optional, enables ARP entry for the PPP client IP on the server’s LAN interface, useful in some bridging scenarios.

Push specific routes (server-initiated)

PPTP/PPP itself does not have an elegant “push route” mechanism like OpenVPN. However, you can use ip-up scripts on the client or configure pppd ms-dns and specific server-side configuration to instruct clients to add routes.

On Linux server create/modify /etc/ppp/ip-up script (runs when PPP interface is up). Example to push routes to a client via SSH/management scripts is possible, but simpler approach: instruct clients to add routes locally (described in client section). For Windows clients, the server can use DHCP-like options only by using vendor extensions; therefore manual/additional configuration on the client is typical.

Firewall and NAT

Allow GRE and TCP/1723 through the perimeter firewall:

sudo iptables -A INPUT -p tcp --dport 1723 -j ACCEPT
sudo iptables -A INPUT -p gre -j ACCEPT

To permit internal subnet access and NAT if required, set rules accordingly:

Enable NAT for traffic from VPN clients destined for the Internet only if you want tunneled Internet access for some clients (not required for split-tunnel):

sudo iptables -t nat -A POSTROUTING -s 192.0.2.0/24 -o eth0 -j MASQUERADE

To forward traffic from VPN clients to internal networks:

sudo iptables -A FORWARD -i ppp+ -o eth1 -d 10.10.0.0/16 -j ACCEPT
sudo iptables -A FORWARD -i eth1 -o ppp+ -s 10.10.0.0/16 -j ACCEPT

Replace eth0/eth1 with your public and internal interface names.

Client configuration for split-tunnel

Split-tunnel configuration differs by client OS. The general idea is to ensure the VPN connection adds only specific routes (internal networks) and does not change the default gateway.

Windows (10/11)

  • Create a new VPN connection in Settings → Network & Internet → VPN (legacy PPTP option may require Control Panel → Network and Sharing Center → Set up a new connection).
  • After creating the connection, open Network Connections → right-click the VPN adapter → Properties → Networking → Internet Protocol Version 4 (TCP/IPv4) → Properties → Advanced.
  • Uncheck Use default gateway on remote network. This prevents the VPN from becoming the default route and enables split-tunneling.
  • Manually add persistent routes if necessary so that only corporate subnets go over the VPN. Use an elevated command prompt:
  • route add 10.10.0.0 mask 255.255.0.0 192.0.2.1 metric 1 -p
  • Here, 192.0.2.1 is the server-side PPP IP used as next-hop from the client perspective. Adjust for your addressing.

macOS (legacy PPTP client)

macOS removed native PPTP support in recent versions — you’ll need a third-party PPTP client. The client should allow disabling “Send all traffic over VPN” or “Use default gateway on remote network”. If not, add static routes using the route command after the VPN connects:

sudo route -n add -net 10.10.0.0/16 192.0.2.1

Linux (network-manager or manual)

NetworkManager’s PPTP plugin provides a checkbox labeled “Use this connection only for resources on its network” — enabling that creates split-tunnel behavior. For manual pppd-based connections, create route entries in /etc/ppp/ip-up on the client to add the needed routes:

Example in client /etc/ppp/ip-up (runs with arguments):

#!/bin/sh
/sbin/ip route add 10.10.0.0/16 via $5 dev $1

Where $1 is the interface name (e.g., ppp0) and $5 is the server IP on the PPP link or gateway; adjust as required.

DNS considerations

Split-tunnel scenarios often need DNS resolution for internal hostnames to go across the VPN. There are two approaches:

  • Push internal DNS via PPP options using ms-dns (server-side) and allow the client to accept it. Some clients will use the pushed DNS server only for the VPN connection.
  • Configure client DNS settings or use conditional forwarding (e.g., set the OS to resolve particular domains against the internal DNS server). On Windows, you can use netsh interface ip add dns on the VPN adapter.

Test DNS resolution explicitly after connecting (e.g., nslookup internal-host or dig @10.10.0.10 internal-host).

Troubleshooting checklist

  • Verify GRE and TCP/1723 reachability from client to server (use tcpdump on server and packet capture on client).
  • Check /var/log/syslog or /var/log/messages for pppd/pptpd logs and authentication traces.
  • Confirm IP forwarding is enabled on the server: sysctl net.ipv4.ip_forward.
  • Use ip route and route print to inspect client routing table and ensure the default route was not overwritten (unless intended).
  • Test reachability: ping 10.10.0.1 (internal host) and curl ifconfig.me to verify public IP remains client’s home IP when split-tunnel is active.
  • If DNS fails, try querying the internal DNS server directly to isolate the issue.

Advanced operational tips

To harden and stabilize your PPTP split-tunnel deployment:

  • Use firewall rules to restrict which internal resources each VPN user or subnet can access. This mitigates PPTP’s weak encryption by limiting sensitive attack surfaces.
  • Implement multi-factor authentication and strong password policies where possible, even for legacy protocols.
  • Log and monitor VPN sessions with syslog/central logging. Keep track of authentication failures and anomalous source IPs.
  • Adjust MSS/MTU settings if you observe fragmentation or application issues over the tunnel. Lowering MTU to 1400 is a common fix.
  • Consider routing policies or policy-based routing on the server to selectively NAT or route traffic from different client pools.

Conclusion and migration advice

PPTP can be configured for split-tunnel access using a combination of pppd options, server-side firewalling, and client routing configuration. While it offers simplicity and broad compatibility, it should be considered a legacy solution. Plan a migration path to modern VPN protocols that support secure route pushing, stronger cryptography, and better cross-platform tooling.

For further resources and managed options, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.