Port 1723 – PPTP (Point-to-Point Tunneling Protocol)

Port 1723 is the default port for PPTP (Point-to-Point Tunneling Protocol) VPNs — specifically the TCP control channel that sets up and tears down the tunnel, while the tunnelled data itself rides GRE (Generic Routing Encapsulation, IP protocol 47) rather than any TCP or UDP port. The one thing worth knowing before anything else: PPTP is cryptographically broken and should not be used. Its authentication — MS-CHAPv2 — can be reduced to a single DES key and cracked with 100% success regardless of how strong the password is, and its MPPE encryption offers no protection once that password is recovered. So an open 1723 doesn’t just mark a VPN gateway; it marks a legacy, weak one, where an attacker who can sniff or relay a single handshake walks away with the user’s credentials — and, because PPTP usually authenticates against Windows accounts, often the domain password behind them. PPTP sits in the VPN family next to L2TP on 1701, IPsec IKE on 500, and OpenVPN on 1194 — but it is the oldest of the four and the only one that is fundamentally broken.

Why It’s Open

PPTP is open on anything still terminating a legacy remote-access tunnel: Windows Server RRAS (Routing and Remote Access Service), Linux/BSD hosts running poptop/pptpd, and consumer or SMB routers and firewalls (MikroTik RouterOS, DrayTek, ZyXEL, older Cisco). It lingers because for two decades a PPTP client was built into every version of Windows, plus macOS and iOS, so it was the zero-install “just works” VPN — and old gear never got migrated off it. Apple removed the built-in PPTP client in macOS Sierra (10.12) and iOS 10, and Microsoft has long recommended replacing it, but the servers stay up.

A working PPTP tunnel needs two things through the network: TCP 1723 for the control channel and GRE / IP protocol 47 for the data. GRE is not a TCP/UDP port, so it needs explicit firewall/NAT handling (“PPTP passthrough”) — which means an open 1723 with GRE blocked is a control port that can be fingerprinted and attacked but can’t actually carry a tunnel. PPTP shares the “VPN gateway” role with L2TP (1701), IPsec IKE (500 / 4500), and OpenVPN (1194), but they are four distinct technologies — and PPTP is the only one whose crypto is broken by design rather than by misconfiguration.

Common Risks

• MS-CHAPv2 authentication is broken — the headline finding. This is a protocol design flaw, not a CVE, and no patch fixes it. In 2012 at DEF CON 20, Moxie Marlinspike and David Hulton showed that the security of MS-CHAPv2 reduces to the strength of a single DES key. Because DES’s 56-bit keyspace is exhaustively searchable, a captured MS-CHAPv2 handshake is 100% crackable to the NT hash / password — independent of password length or complexity — via CloudCracker (fed by the chapcrack tool) or offline with asleap. An attacker who sniffs or MITMs one PPTP login recovers the credential outright.
• No server authentication — trivial MITM / rogue endpoint. PPTP never authenticates the server to the client, so an attacker on the path (or one who lures a client to a rogue PPTP endpoint) can capture the MS-CHAPv2 handshake without ever touching the real gateway, then crack it offline.
• MPPE encryption adds nothing here. MPPE is keyed off the same (crackable) password, provides no integrity protection, and offers no confidentiality once the handshake has been broken — so “the traffic is encrypted” is not a defence.
• A cracked PPTP login is often a domain credential. PPTP typically authenticates against Windows/AD accounts, so recovering one password is frequently direct initial access and lateral movement, a classic ransomware entry route.
• Online brute-force is cheap. thc-pptp-bruter brute-forces the 1723 login and deliberately reuses the caller-ID to defeat the one-attempt-per-second rate limit Microsoft’s implementation relies on.
• Implementation bugs in the PPTP stack. Windows RRAS and poptop/pptpd have carried remote memory-corruption CVEs reachable over 1723 (see below) — independent of the MS-CHAPv2 problem.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and fingerprint the gateway

# -sV runs Nmap's built-in PPTP probe; the pptp-version NSE script reads the
# hostname, vendor name, and firmware version out of the control-setup packet
nmap -sV -p 1723 <target>
nmap -p 1723 --script pptp-version <target>

That fingerprint is what tells legacy Windows RRAS from poptop/pptpd from a MikroTik or DrayTek box — and points you at the right implementation CVEs.

Confirm the GRE data channel is actually reachable

# PPTP's data rides GRE (IP protocol 47), not a port — no GRE, no real tunnel
tcpdump -n -i <iface> 'tcp port 1723 or proto gre'

Capture and crack the MS-CHAPv2 handshake (the real attack)

# Extract the MS-CHAPv2 challenge/response from a captured (or MITM'd) handshake
chapcrack parse -i handshake.pcap
# Offline dictionary attack on the same handshake with asleap
asleap -r handshake.pcap -W /usr/share/wordlists/rockyou.txt

chapcrack produces the token that historically went to CloudCracker for a guaranteed single-DES key recovery — the “100% crackable” result from the 2012 break — while asleap runs a local dictionary attack against the captured challenge/response.

Brute-force the login online

# thc-pptp-bruter reads candidate passwords from stdin and beats the
# caller-ID rate limit by reusing IDs across attempts
cat passwords.txt | thc-pptp-bruter -u <user> <target>

Every reachable 1723, confirmed GRE path, cracked handshake, and valid credential is a finding — keep it with the engagement so it lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

One scoping rule keeps this honest: the load-bearing PPTP weakness — the MS-CHAPv2 / MPPE break — is a design flaw, not a CVE. There is no patch; the fix is to stop using PPTP. The genuine CVEs on 1723 are implementation bugs in specific PPTP stacks (Windows RRAS, poptop/pptpd):

• CVE-2022-23270 — Windows Point-to-Point Tunneling Protocol Remote Code Execution. Crafted packets to a Windows RRAS server running PPTP reach remote code execution with no authentication. Part of the May 2022 Patch Tuesday cluster of Windows PPTP bugs, affecting Windows 7 through 11 and Server 2008–2022. CVSS 8.1 (High), AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H — genuinely scoped to the PPTP service on 1723.
• CVE-2022-21972 — Windows Point-to-Point Tunneling Protocol Remote Code Execution, the companion bug from the same May 2022 cluster and the same affected Windows/Server range. CVSS 8.1 (High), AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H — unauthenticated RCE against the RRAS PPTP driver.
• CVE-2002-1214 — Buffer overflow in the Microsoft PPTP Service on Windows XP and Windows 2000 (SP1–SP3). A PPTP control packet with malformed control data causes a denial of service (hang) and possibly code execution. CVSSv2 7.5 (High), AV:N/AC:L/Au:N/C:P/I:P/A:P — the original Windows PPTP memory-corruption bug (fixed in MS02-063).
• CVE-2003-0213 — poptop/pptpd buffer overflow (the Linux PPTP daemon before 1.1.4-b3). A length field of 0 or 1 in ctrlpacket.c feeds a negative value into a read operation, overflowing a buffer — a denial of service, with potential code execution per the advisory. CVSSv2 7.5 (High), AV:N/AC:L/Au:N/C:P/I:P/A:P, with a public exploit at Exploit-DB 22479.

Scope note: the previous version of this page listed three CVEs that have nothing to do with PPTP and have been removed: CVE-2012-4445 is a heap overflow in hostapd’s EAP-TLS server, CVE-2002-0124 is a directory-traversal bug in MDG Web Server 4D/eCommerce, and CVE-1999-0506 is a generic Windows NT blank/default account password finding. None is a PPTP vulnerability. And to say it once more: the famous MS-CHAPv2 break (Marlinspike & Hulton, 2012) is a protocol design flaw with no CVE and no patch — the answer is migration, not an update.

Mitigation

• Do not use PPTP — migrate. This is the only real fix. Replace it with WireGuard, OpenVPN, or IKEv2/IPsec. PPTP’s MS-CHAPv2/MPPE crypto cannot be patched or configured back to safety.
• If it must exist temporarily, treat every PPTP credential as already exposed. Isolate the gateway on its own segment, put MFA on a fronting layer, and never reuse PPTP passwords elsewhere — especially not as domain passwords, since a captured handshake gives them up regardless of length. “Strong passwords” do not save a broken handshake.
• Block 1723 and GRE (IP protocol 47) from untrusted networks. Firewall both the control port and the GRE data channel to known peers, or drop them at the perimeter — blocking only 1723 while GRE stays open still leaks a fingerprintable service.
• Patch the implementation stack. Keep Windows RRAS current for CVE-2022-23270 / CVE-2022-21972, and poptop/pptpd current for CVE-2003-0213 — while remembering that patching closes the memory-corruption bugs but does nothing about the MS-CHAPv2 design flaw.
• Rescan and confirm closure. Once PPTP is retired, verify 1723 is closed and GRE is no longer forwarded.

Real-World Example

The cleanest illustration of why an internet-facing 1723 deserves a hard look is the 2012 DEF CON 20 talk by Moxie Marlinspike and David Hulton. They showed that the entire security of MS-CHAPv2 — the authentication protocol behind essentially every PPTP VPN — collapses to the strength of a single DES key. Because DES’s 56-bit keyspace is exhaustively searchable, they built CloudCracker (fed by the chapcrack tool) to guarantee recovery of that key from any captured handshake, in under a day, for a flat fee — 100% success, independent of how long or random the user’s password was. The practical consequence is stark: an attacker who can capture one PPTP handshake — by sniffing a shared segment, or by standing up a rogue endpoint, since PPTP never authenticates the server — recovers the user’s NT hash and password outright, and with it the VPN and usually the Windows domain account behind it. There was no bug to patch and no configuration to harden; Microsoft’s own guidance after the talk was to stop using PPTP and move to a real VPN. It’s the whole lesson of this port in one talk: on 1723, the question isn’t whether the VPN is up — it’s how quickly its captured handshake becomes a domain credential.

FAQ

What is port 1723 used for?

Port 1723 carries the control channel of PPTP (Point-to-Point Tunneling Protocol), the connection that sets up and manages a PPTP VPN tunnel. The tunnelled data itself doesn’t use port 1723 — it travels over GRE (IP protocol 47). An open 1723 marks a legacy Microsoft-style VPN gateway.

Is port 1723 TCP or UDP?

TCP. The PPTP control channel runs over TCP 1723. PPTP’s data does not use a TCP or UDP port at all — it rides GRE (Generic Routing Encapsulation, IP protocol 47), which is why a working PPTP tunnel needs both TCP 1723 and GRE allowed through the network.

Is PPTP secure? Should I still use it?

No. PPTP is cryptographically broken and should not be used. Its MS-CHAPv2 authentication reduces to a single DES key, so a captured handshake is 100% crackable to the password regardless of its strength; MPPE encryption adds nothing once that password is recovered; and PPTP never authenticates the server, making MITM trivial. Migrate to WireGuard, OpenVPN, or IKEv2/IPsec.

What’s the difference between PPTP (1723), L2TP (1701), IPsec (500), and OpenVPN (1194)?

They’re four different VPN technologies. PPTP on 1723 is the oldest — an obsolete Microsoft VPN with broken MS-CHAPv2 crypto, data over GRE. L2TP on 1701 is just a tunnel with no crypto of its own, almost always wrapped in IPsec. IPsec IKE on UDP 500/4500 is the encryption layer L2TP rides in. OpenVPN on 1194 is a self-contained SSL/TLS VPN. They share the VPN-gateway role but none of the underlying machinery — and only PPTP is broken by design.

How do I secure or close port 1723?

Retire PPTP and migrate to WireGuard, OpenVPN, or IKEv2/IPsec — that’s the fix. Until then, block TCP 1723 and GRE (IP protocol 47) from untrusted networks, patch Windows RRAS and poptop/pptpd for the implementation CVEs, put MFA on a fronting layer, and treat all PPTP credentials as exposed. Once nothing uses it, stop the service and confirm the port is closed with a rescan.

TL;DR

• Service: PPTP (Point-to-Point Tunneling Protocol) — a legacy Microsoft VPN; port 1723 is its control channel
• Default port: 1723/TCP (control); the data channel rides GRE / IP protocol 47 (no UDP, no data port)
• Biggest risk: PPTP is cryptographically broken — MS-CHAPv2 reduces to a single DES key, so a captured handshake is 100% crackable to the password (a design flaw, not a CVE; chapcrack/CloudCracker/asleap offline, thc-pptp-bruter online), and a cracked login is often a domain credential
• Also watch: implementation CVEs — Windows RRAS PPTP RCE (CVE-2022-23270 / CVE-2022-21972, CVSS 8.1), the classic Windows PPTP overflow (CVE-2002-1214), and the poptop/pptpd overflow (CVE-2003-0213)
• Mitigation: don’t use PPTP — migrate to WireGuard / OpenVPN / IKEv2-IPsec; block 1723 + GRE, patch the stack, and treat every PPTP credential as already exposed