PPTP (Point-to-Point Tunneling Protocol) remains in use in many legacy environments and smaller deployments due to its simplicity and wide client support. When paired with a RADIUS server for authentication, authorization and accounting (AAA), it becomes possible to manage VPN user credentials and policies centrally across multiple PPTP gateways. This article provides a practical, technically detailed walkthrough for setting up PPTP VPN with RADIUS authentication, aimed at site administrators, corporate IT teams, and developers tasked with centralized access control.

Why combine PPTP with RADIUS?

PPTP by itself handles tunneling and encryption (via MPPE) but typically relies on local user databases on each gateway. Adding a RADIUS server offers several benefits:

  • Centralized authentication: Users and policies are stored in one place, simplifying management across multiple VPN concentrators.
  • Flexible authorization: Return vendor-specific attributes (VSAs) or standard attributes (e.g., Framed-IP-Address, Filter-Id) to control IP assignment and access levels per user or group.
  • Accounting: Track session start/stop times, data transferred, and per-user usage for auditing or billing.
  • Integration: Leverage existing identity stores (LDAP/Active Directory) by authenticating against them through RADIUS.

Security considerations (brief)

Before diving into configuration, be explicit about security limitations: PPTP is considered weak by modern cryptographic standards. Vulnerabilities in the MS-CHAPv2 authentication protocol and the underlying MPPE encryption make PPTP unsuitable for highly sensitive data or compliance-heavy environments. Where possible, prefer modern VPN protocols (OpenVPN, IPsec, WireGuard). If PPTP must be used (legacy clients, specific app compatibility), mitigate risk with strong passwords, network segmentation, and strict monitoring.

Architecture overview

A typical deployment includes:

  • One or more PPTP gateways (Linux with pptpd, Windows RRAS, or dedicated appliances).
  • A RADIUS server (FreeRADIUS on Linux or Microsoft Network Policy Server (NPS)).
  • An identity backend (local RADIUS users, LDAP, Active Directory).
  • Network components: firewall rules, NAT, and optionally DHCP or static IP pools.

RADIUS attributes commonly used with PPTP

  • Framed-IP-Address (attr 8): Assigns a specific IP to client sessions.
  • Framed-IP-Netmask (attr 9): Specifies subnet mask.
  • Framed-Routing (attr 7): Controls routing characteristics.
  • Service-Type (attr 6): Can indicate Framed-User, etc.
  • Acct-Interim-Interval / accounting attributes: For granular accounting.

Preparing the PPTP gateway (Linux: pptpd example)

The following steps describe a common Linux setup using pptpd and FreeRADIUS for authentication.

1. Install required packages

On Debian/Ubuntu:

sudo apt update && sudo apt install pptpd freeradius freeradius-utils ppp

2. Configure pptpd

Edit /etc/pptpd.conf (or equivalent) to set local and remote IP ranges and DNS:

<example snippet>

localip 192.168.100.1
remoteip 192.168.100.201-192.168.100.254

Important: Do not put user credentials in /etc/ppp/chap-secrets if RADIUS will handle authentication.

3. Configure ppp options

Edit /etc/ppp/options.pptpd to enforce MPPE and set other PPP options:

require-mschap-v2
refuse-chap
refuse-mschap
ms-dns 8.8.8.8
mtu 1400
mru 1400

require-mschap-v2 forces MS-CHAPv2 which is required for MPPE. Note: MS-CHAPv2 has known weaknesses.

4. Enable RADIUS for PPP

Install and configure a RADIUS client for PPP. On Debian families, the package freeradius-client or the ppp radius plugin can be used. Edit /etc/ppp/chap-secrets to comment out local entries and configure radius plugin in /etc/ppp/.

Alternatively, configure /etc/pptpd.conf or the ppp daemon to use the RADIUS plugin by editing /etc/ppp/chap-secrets and /etc/ppp/pap-secrets appropriately and using radius.so plugin via /etc/ppp/ plugins configuration.

Setting up FreeRADIUS (Linux)

FreeRADIUS is a common choice for centralized authentication because it’s flexible and supports many backends.

1. Basic FreeRADIUS setup

Install and start the service:

sudo apt install freeradius freeradius-mysql

Edit /etc/freeradius/3.0/clients.conf to add the PPTP gateway as a client:

client pptp-gateway {
ipaddr = 192.168.100.10
secret = mysharedsecret
require_message_authenticator = no
}

The shared secret must match the PPTP gateway’s RADIUS client setting.

2. Authentication backend

Configure the users file, LDAP, or SQL backend. Example SQL attributes in the radcheck/radreply tables allow you to return Framed-IP-Address and other attributes:

radreply example:

username | Framed-IP-Address | 10.10.10.50

3. Configure modules and authorize/authenticate flows

Edit /etc/freeradius/3.0/sites-enabled/default and ensure the mschap module is enabled for authentication. Confirm mschap module configuration in /etc/freeradius/3.0/mods-enabled/mschap points to correct NT-Password or uses the right realm for AD.

Windows RRAS with Microsoft NPS

For Microsoft environments, RRAS (Routing and Remote Access Service) on Windows servers can forward authentication requests to Microsoft NPS, which acts as a RADIUS server and can authenticate against Active Directory.

Key steps

  • Install RRAS role on the PPTP server, enable PPTP and NAT as needed.
  • Install NPS role on a domain-joined server, register NPS in Active Directory.
  • Add RRAS server as a RADIUS client in NPS with a shared secret.
  • Create Connection Request and Network Policies to allow PPTP connections. Specify authentication methods: enable MS-CHAP v2 (with strong passwords).

RADIUS attributes and authorization examples

When a user authenticates, RADIUS can return attributes to control session behaviour. Useful examples:

  • Framed-IP-Address: Assigns a static IP for the session.
  • Framed-Routing: Define routing behaviour.
  • Filter-Id or custom vendor attributes: Apply per-user firewall or QoS profiles on some gateways.
  • Acct-Interim-Interval: Request interim accounting updates, useful for usage tracking.

Sample radreply SQL insert for FreeRADIUS:

INSERT INTO radreply (username, attribute, value) VALUES ('alice','Framed-IP-Address','10.10.10.51');

Firewall and NAT considerations

PPTP uses TCP port 1723 and GRE (IP protocol 47). When placing a PPTP gateway behind NAT or a firewall, ensure:

  • TCP 1723 is allowed and forwarded to the PPTP server.
  • GRE (protocol 47) traffic is permitted and correctly forwarded—many consumer routers struggle with GRE + NAT and may need VPN passthrough enabled.
  • RADIUS traffic (UDP ports 1812 for authentication and 1813 for accounting, or legacy 1645/1646) must be allowed between gateway and RADIUS server.

Troubleshooting checklist

  • Check pptpd/pppd logs on the gateway (often in syslog or /var/log/syslog) for RADIUS request/response and PPP negotiation issues.
  • Use FreeRADIUS in debug mode: sudo freeradius -X to inspect incoming requests, attributes, and errors.
  • Verify shared secret and client IP in RADIUS clients config.
  • Confirm MS-CHAPv2 is being used by clients (Windows, macOS, mobile) and that require-mschap-v2 is set.
  • Ensure RADIUS server can reach the identity backend (LDAP/AD) and service accounts are correctly configured.

Logging and accounting

Enable RADIUS accounting to capture session start/stop and data usage. FreeRADIUS can write accounting records to SQL for later processing. Key fields include:

  • User-Name
  • Acct-Status-Type (Start/Stop/Interim)
  • Acct-Session-Id
  • Acct-Input-Octets / Acct-Output-Octets

These allow detailed reporting and session correlation across multiple PPTP gateways.

Best practices and operational tips

  • Use strong shared secrets and TLS for management access between components.
  • Isolate PPTP endpoints to a segmented network and restrict internal resource access via ACLs.
  • Monitor logs and enable alerting on repeated authentication failures to detect brute-force attempts.
  • Plan for migration to modern VPN protocols; treat PPTP+RADIUS as transitional or compatibility-focused.
  • Document per-user attributes in RADIUS (static IPs, custom filters) to avoid misconfigurations.

Conclusion

Combining PPTP with RADIUS provides a straightforward path to centralize VPN authentication, authorization, and accounting across multiple gateways. While PPTP’s cryptographic weaknesses mean it’s not recommended for highly sensitive applications, many organizations still rely on it for legacy compatibility. By following the configuration patterns above—using FreeRADIUS or Microsoft NPS, ensuring correct PPP and MPPE settings, returning appropriate RADIUS attributes, and enforcing rigorous firewall and logging practices—you can create a centrally managed, auditable PPTP VPN service.

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