Introduction

PPTP (Point-to-Point Tunneling Protocol) remains in use in many environments despite newer VPN protocols. For administrators and developers who must maintain or integrate PPTP-based services, understanding the details of network addressing and routing is essential to ensure reliability, performance, and compatibility. This article dives into the addressing and routing specifics for PPTP VPNs, covering IP assignment mechanisms, routing models (full tunnel vs split tunnel), interaction with NAT and firewalls, MTU/MSS considerations, and practical configuration snippets for common server and client platforms.

PPTP Fundamentals Relevant to Addressing and Routing

PPTP encapsulates PPP frames in GRE (Generic Routing Encapsulation) and uses TCP port 1723 for control. The underlying PPP negotiation handles IP addressing and options such as DNS assignment, route pushes, and authentication. Because PPTP relies on PPP semantics, many of the routing behaviors derive from PPP configuration and the server’s network stack rather than a protocol-level routing protocol.

Key components that affect addressing and routing:

  • PPP/IPCP negotiation for IP address and DNS assignment.
  • Server pool allocation vs static/dedicated IP assignment.
  • Client-side route installation (default gateway override or specific routes).
  • NAT handling for clients behind NAT or when NATting client traffic to the Internet.
  • GRE passthrough and firewall rules for GRE and TCP 1723.

IP Assignment Methods

Proper IP assignment avoids address conflicts and eases routing. There are three common methods to assign IP addresses to PPTP clients:

Server-side Static Pool

The simplest approach is a server-managed pool. The VPN server maintains an IP subnet (for example, 10.10.10.0/24) and assigns addresses from this pool via PPP. This isolates VPN addresses from the LAN if desired and simplifies route configuration because the server knows the pool range.

  • Pros: Simple, centralized control, predictable ranges for firewall rules.
  • Cons: Lacks per-user dedicated IP unless static mappings are configured.

Per-user Static/Dedicated IP

Some deployments require each user to have a dedicated IP (useful for whitelisting, session persistence, or compliance). This can be implemented by mapping usernames to fixed IPs in the authentication subsystem (e.g., chap-secrets in Linux pptpd or RADIUS attributes).

  • On Linux pptpd, map users in /etc/ppp/chap-secrets and use ipparam / ip-up scripts to set routing/NAT behavior.
  • With RADIUS, use attributes like Framed-IP-Address to assign IPs centrally.

DHCP-Based Assignment

Less common for PPTP because PPP already negotiates IP, but some deployments bridge PPP interfaces to a LAN and use DHCP to assign addresses. This requires careful bridging and security considerations.

Routing Models: Full Tunnel vs Split Tunnel

The route policy determines how traffic flows from the client:

Full Tunnel (Default Route via VPN)

In a full-tunnel setup, the VPN server pushes a default route to the client through the PPP link. All client traffic, including Internet-bound packets, traverses the VPN and is NATted at the gateway or routed from the VPN server’s public exit interface.

  • Advantages: Centralized security policies, IP reputation masking, consistent egress IP (good for dedicated IP services).
  • Disadvantages: Higher bandwidth usage on the server side and potential latency increases.

Split Tunnel (Selective Routes)

With split tunneling, the server pushes only specific network routes (for example, corporate subnets like 192.168.100.0/24) while leaving the client’s default route pointing to the local ISP. This reduces server bandwidth but requires trust that client local traffic doesn’t need the VPN protection.

  • Push routes via pppd options or RADIUS attributes (e.g., Cisco vendor-specific attributes or RADIUS Framed-Route).
  • Client platforms (Windows, Linux, macOS) can be configured to accept or ignore default route pushes.

NAT, Firewall and GRE Considerations

Because PPTP uses GRE for tunneling, firewall and NAT rules must accommodate GRE (protocol 47) in addition to allowing TCP port 1723. Many consumer NAT devices perform PPTP passthrough, but enterprise firewalls require explicit rules.

  • Allow inbound TCP/1723 to the VPN server’s public IP.
  • Allow GRE (protocol 47) bi-directionally between client networks and server.
  • If the server performs NAT for client Internet traffic, configure MASQUERADE/SNAT appropriately for the VPN subnet.

Example iptables NAT rule to NAT VPN clients to the server’s public interface eth0:

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

Also ensure the FORWARD chain allows traffic from ppp interfaces (e.g., ppp0) to internal/external networks:

iptables -A FORWARD -i ppp+ -o eth0 -j ACCEPT

Routing Table Entries and Policy Routing

When a PPTP client connects, a point-to-point interface (pppX) appears on the server. The server kernel configures a route for the remote peer. For multi-homed servers or complex topologies, policy-based routing may be required.

  • Use ip rule/ip route to direct traffic originating from specific VPN-assigned IPs through a particular egress interface.
  • Example: Create a routing table for VPN clients and add rules so packets with source 10.10.10.0/24 use that table to ensure proper routing and source selection.

Sample commands:

ip route add default via 203.0.113.1 dev eth0 table vpn

ip rule add from 10.10.10.0/24 lookup vpn

MTU, MSS, and Fragmentation

PPTP adds GRE and PPP overhead, which effectively reduces the available MTU for the inner IP packets. If not adjusted, Path MTU Discovery can help but many networks block ICMP, causing black-hole connections. Common mitigations:

  • Set the VPN interface MTU slightly lower (e.g., 1400) to accommodate overhead.
  • Apply MSS clamping for TCP flows via iptables to prevent fragmentation issues: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu.

Recommended default: lower MTU to 1400 and clamp MSS to 1360–1400 depending on observed path behavior.

DNS and Name Resolution

PPTP/PPP allows servers to push DNS server IPs to clients via IPCP (pppd options). For environments that require internal name resolution, push internal DNS IPs and ensure split tunnel or routing allows clients to reach those DNS servers.

  • For Windows clients, the VPN connection properties accept DNS and WINS assignments from the server if configured.
  • On Linux, configure pppd with ms-dns options or use scripts (ip-up) to adjust /etc/resolv.conf.

Authentication, RADIUS and Dedicated IPs

For large deployments, integrate with RADIUS for authentication and accounting. RADIUS supports attributes to assign framed IP addresses, routes, DNS, and session timeouts.

  • Use Framed-IP-Address for per-user IP allocation.
  • Use vendor-specific attributes to push split-tunnel routes when supported by client software.

Assigning dedicated (static) IPs per user via RADIUS simplifies whitelisting because each user always appears from the same source IP after authentication.

Multi-Subnet and Inter-VPN Routing

If PPTP clients must access multiple internal subnets, configure routing on the VPN server to route between ppp interfaces and internal LAN segments. This often requires:

  • Static routes on internal routers pointing to the VPN server for the VPN subnet.
  • Or, enable NAT on the VPN server if internal routers cannot be changed (less preferred).

When scaling to multiple VPN servers, advertise client subnets between servers or centralize IP assignment in a RADIUS server so routing decisions remain straightforward.

Troubleshooting Common Addressing and Routing Issues

Typical problems and checks:

  • No GRE traffic: check firewall for protocol 47 blocking; allow TCP 1723 and GRE.
  • IP conflicts: verify PPP pool doesn’t overlap LAN subnets; prefer using private subnet range dedicated to VPNs.
  • Client cannot reach internal resources: confirm server routing rules and ensure internal routers have return routes for the VPN subnet.
  • Fragmentation/timeouts: adjust MTU/MSS and enable TCPMSS clamping.
  • Clients not getting DNS: confirm IPCP options include DNS servers and client honors them.

Security and Best Practices

Although this article focuses on addressing and routing, security impacts addressing choices:

  • Avoid overlapping address spaces: use unique VPN subnets to prevent routing ambiguity.
  • Prefer per-user dedicated IPs when services require IP-based authentication.
  • Limit exposure of management interfaces and ensure authentication uses secure methods (e.g., MS-CHAPv2 with strong passwords and ideally combined with mschapv2-strengthening mechanisms or move to stronger protocols when possible).
  • Log and monitor RADIUS and PPP session activity to correlate IP assignments with user activity.

Practical Configuration Examples

Linux (pptpd + pppd) Basic

/etc/pptpd.conf contains localip and remoteip settings:

localip 203.0.113.10

remoteip 10.10.10.100-10.10.10.200

/etc/ppp/options file includes ms-dns entries and ip-up script that applies iptables MASQUERADE.

Windows Client Route Commands

To add a route for a corporate subnet via the VPN interface after connection:

route add 192.168.100.0 mask 255.255.255.0 metric 1

Use route print to inspect the routing table and confirm the VPN interface assignment.

Summary

PPTP addressing and routing hinge on PPP negotiation, server-side pool and mapping choices, and the routing policy (full vs split tunnel). Proper design ensures predictable IP assignment, correct routing for internal resources, and reliable egress behavior. Address overlap, GRE/firewall rules, MTU/MSS handling, and return route setup on internal routers are common failure points that require attention. For deployments that need consistent source IPs for whitelisting or compliance, per-user dedicated IPs (via RADIUS or server mappings) are a pragmatic approach.

For more in-depth guides and configuration templates tailored to dedicated IP assignments and enterprise PPTP scenarios, visit Dedicated-IP-VPN: https://dedicated-ip-vpn.com/.