Port 1701 – L2TP (Layer 2 Tunneling Protocol)

Port 1701 is the default port for L2TP (Layer 2 Tunneling Protocol), which tunnels PPP frames across an IP network to build a VPN. The one thing worth knowing before anything else: L2TP on its own provides no encryption and no strong authentication — it just wraps and forwards PPP. In the real world it’s almost always deployed as L2TP/IPsec, where IPsec does the encrypting and authenticating and L2TP rides inside the protected tunnel. So the security of an “L2TP VPN” is really the security of its IPsec layer, which negotiates on UDP 500 (IKE) and UDP 4500 (NAT-Traversal). An open 1701 marks a remote-access VPN gateway, and the highest-value finding here is the simplest one: plain L2TP with no IPsec at all, tunneling credentials and data in cleartext.

Why It’s Open

L2TP is open on anything terminating a remote-access or site-to-site tunnel: Windows RRAS/RAS servers, VPN appliances and firewalls (Cisco, MikroTik, Fortinet, SonicWall, Juniper), routers, and Linux/BSD hosts running xl2tpd or l2tpd alongside strongSwan/Libreswan for the IPsec half. It’s a popular choice for remote access because L2TP/IPsec has a native client built into every major OS — Windows, macOS, iOS, and Android all dial it without extra software.

L2TP rarely travels alone. Because the real encryption and authentication live in IPsec, an L2TP/IPsec gateway usually answers on 1701 and on UDP 500 / UDP 4500 (with the encrypted payload riding ESP, IP protocol 50). That’s the tell for the whole VPN family: L2TP sits next to IPsec IKE on 500, OpenVPN on 1194, and legacy PPTP on 1723 — but L2TP, IPsec, OpenVPN, and PPTP are four distinct technologies. L2TP is just the tunnel; IPsec is what makes it safe.

Common Risks

• Plain L2TP with no IPsec — a cleartext tunnel. This is the headline finding, and it’s a configuration weakness, not a CVE. L2TP by itself encrypts nothing, so if a gateway runs L2TP on 1701 without IPsec (a misconfiguration, or an IPsec layer that silently failed to come up), the PPP session inside it — including the login exchange and every byte of tunneled traffic — crosses the wire in cleartext for anyone on the path to sniff. A “secure VPN” that turns out to be raw L2TP is a full compromise of confidentiality.
• The IPsec layer is the real attack surface. Where IPsec is present, the security of the “L2TP VPN” is the security of port 500. Every port 500 finding applies here — most importantly IKEv1 Aggressive Mode, which hands an unauthenticated attacker a crackable hash of the pre-shared key (ike-scan --aggressive → psk-crack).
• Shared / weak IPsec PSK. L2TP/IPsec is very often deployed with a single pre-shared key reused across every user, distributed in an MDM profile or a setup document. Leak that one string and half the authentication is gone; a weak PSK falls to offline cracking.
• Weak user auth and no MFA. The PPP layer inside L2TP typically authenticates with a username/password over MS-CHAPv2, which is offline-crackable if the IPsec wrapper is weak or absent. Without MFA, credential spraying against the VPN — or a single stolen login — is direct network access, a common ransomware initial-access route.
• Implementation bugs in the L2TP stack. L2TP packet parsers have carried remote code execution and denial-of-service bugs — the Windows RAS L2TP RCE cluster (CVE-2023-21543) and the Cisco IOS XE L2TP DoS (CVE-2023-20227) both reach the daemon over UDP 1701 with no authentication.
• Session hijacking on weak daemons. Old L2TP implementations with predictable tunnel/session IDs let an attacker hijack an established tunnel (the historic l2tpd RNG bug, CVE-2002-0872).

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

Check if it’s open and confirm it’s L2TP

# nmap's version probe sends an L2TP SCCRQ control message —
# a control reply confirms an L2TP LNS / VPN gateway
nmap -sU -sV -p 1701 <target>

Decide whether IPsec is actually there (the key question)

# Scan the whole L2TP/IPsec footprint at once
nmap -sU -p 500,1701,4500 <target>

If 1701 answers but 500 and 4500 do not, treat it as plain L2TP with no IPsec until proven otherwise — capture the handshake and confirm the PPP frames are in cleartext rather than wrapped in ESP:

tcpdump -n -i <iface> 'udp port 1701 or udp port 500 or udp port 4500 or ip proto 50'

Attack the IPsec layer (where the real crypto/auth lives)

# Fingerprint the IKE gateway and test for Aggressive Mode — see the port 500 page
ike-scan -M --showbackoff <target>
ike-scan -M -A --id=vpngroup --pskcrack=psk.txt <target>
psk-crack -d /usr/share/wordlists/rockyou.txt psk.txt

Full IKE/IPsec enumeration — Aggressive Mode PSK capture, group-ID guessing, and cracking — is covered on the IPsec IKE (port 500) page; on an L2TP/IPsec target that’s where the offline-crackable material comes from.

Every open 1701, missing-IPsec downgrade, shared PSK, and cracked credential you confirm 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

Two scoping rules keep this honest. First, most “L2TP VPN” auth and crypto CVEs are really the IPsec/IKE layer (port 500) or the vendor appliance — check them on the port 500 page. Second, the genuine L2TP-on-1701 bugs are implementation flaws in specific L2TP stacks (Windows RAS, Cisco, MikroTik, l2tpd):

• CVE-2023-21543 — Windows L2TP Remote Code Execution. A crafted L2TP packet to a Windows RAS server reaches remote code execution with no authentication. Part of the January 2023 Patch Tuesday cluster of Windows L2TP bugs (which also included CVE-2023-21546, -21555, -21556, and -21679). Affects 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 L2TP service on 1701.
• CVE-2023-21757 — Windows L2TP Denial of Service. A NULL-pointer dereference (CWE-476) in the same Windows L2TP implementation lets a remote attacker crash the service with crafted input. Affects Windows 10/11 and Server 2019/2022. CVSS 7.5 (High) — unauthenticated DoS against the VPN gateway.
• CVE-2023-20227 — Cisco IOS XE L2TP Denial of Service. Improper handling of certain L2TP packets lets an unauthenticated, remote attacker send crafted L2TP traffic to an affected device and force an unexpected reload. CVSS 7.5 (NIST) / 8.6 (Cisco) — a reminder that the daemon parsing 1701 is itself an attack surface. See Cisco’s advisory.
• CVE-2017-6297 — MikroTik RouterOS L2TP client fails to activate IPsec after a restart (CWE-311, Missing Encryption of Sensitive Data). The tunnel silently comes back up as plain L2TP in cleartext, letting an on-path attacker read the traffic and lift the L2TP credentials. CVSS 5.9 (Medium) — the textbook illustration of the “L2TP without IPsec” finding.
• CVE-2002-0872 — l2tpd 0.67 does not initialize its random number generator, making tunnel/session identifiers predictable and letting a remote attacker hijack L2TP sessions. CVSS 7.5 (High, CVSSv2) — old, but a clean example of session hijacking against a bare L2TP daemon.

Scope note: CVE-2019-14899 — “inferring and hijacking VPN-tunneled TCP connections” — is frequently miscredited to L2TP/IPsec. It is actually an operating-system-level routing side-channel (Linux, FreeBSD, OpenBSD, macOS, iOS, Android) that lets an adjacent attacker inject into the TCP stream of any VPN, OpenVPN and WireGuard included. It is not an L2TP bug and not tied to port 1701 — the fix is in the OS, not the tunnel. (The previous version of this page also listed CVE-2002-1139, a Windows Compressed Folders ZIP bug, and CVE-2020-15778, an OpenSSH scp command-injection flaw — neither has anything to do with L2TP, and both have been removed.)

Mitigation

• Never run plain L2TP without IPsec. This is the first rule. L2TP encrypts nothing on its own, so require L2TP/IPsec (or drop L2TP for a modern VPN) and verify the IPsec layer actually comes up — including after reboots and failovers, the exact condition CVE-2017-6297 exploited.
• Harden the IPsec layer. Use a strong, unique IPsec PSK (long and random, never one key shared across all users) — or better, certificate/IKEv2 authentication — and disable IKEv1 Aggressive Mode. All of this is detailed on the IPsec IKE (port 500) page.
• Strong per-user auth + MFA. Put multi-factor authentication in front of the username/password login so a cracked MS-CHAPv2 hash or a stolen credential isn’t enough on its own.
• Patch the L2TP/IPsec stack. Keep Windows RAS, Cisco IOS XE, and xl2tpd/strongSwan/Libreswan current for the L2TP RCE/DoS CVEs above.
• Restrict and monitor. Firewall UDP 1701/500/4500 to known peer ranges where the deployment allows (site-to-site links especially), and log tunnel establishment and teardown to catch spraying and downgrade attempts.
• Consider a modern VPN. OpenVPN, WireGuard, or plain IKEv2/IPsec avoid the L2TP layer entirely. Some teams also distrust L2TP/IPsec after 2013 Snowden-era speculation that IPsec may have been deliberately weakened — there is no public proof that L2TP/IPsec is broken, but the lower-complexity, better-audited alternatives are a reasonable default for new deployments.

Real-World Example

CVE-2017-6297 is the cleanest illustration of why an internet-facing 1701 deserves a hard look — and why “we use L2TP/IPsec” isn’t the same as “our tunnel is encrypted.” On affected MikroTik RouterOS builds, the L2TP client failed to re-enable IPsec after a restart. The tunnel came back up looking healthy, users reconnected, and traffic flowed — but the IPsec wrapper that was supposed to encrypt everything was simply gone. What had been an L2TP/IPsec VPN was now plain L2TP in cleartext, quietly exposing the PPP login and every tunneled byte to anyone on the path, who could read the traffic and lift the VPN credentials outright. No exploit chain, no memory corruption — just a tunnel that silently downgraded itself to the cleartext protocol L2TP is underneath. It’s the whole lesson of this port in one bug: on 1701, the question is never “is L2TP up?” but “is IPsec actually protecting it?”

FAQ

What is port 1701 used for?

Port 1701 carries L2TP (Layer 2 Tunneling Protocol), which tunnels PPP frames over an IP network to build a VPN. It’s used for remote-access VPNs (roaming users dialing into a corporate network) and site-to-site links, almost always in the L2TP/IPsec combination where IPsec supplies the encryption.

Is port 1701 TCP or UDP?

UDP. L2TP runs over UDP 1701. In a real L2TP/IPsec deployment you’ll also see UDP 500 (IKE key exchange) and UDP 4500 (NAT-Traversal), with the encrypted payload travelling as ESP (IP protocol 50).

Does L2TP encrypt traffic?

No — not by itself. L2TP provides no encryption and no strong authentication; it only tunnels PPP. All of the confidentiality in an “L2TP VPN” comes from IPsec in the L2TP/IPsec pairing. Plain L2TP on 1701 with no IPsec is a cleartext tunnel, which is exactly the misconfiguration worth hunting on this port.

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

They’re four different VPN technologies. L2TP on 1701 is just a tunnel with no crypto of its own. IPsec IKE on UDP 500/4500 is the encryption layer L2TP is usually wrapped in. OpenVPN on 1194 is a self-contained SSL/TLS VPN. PPTP on 1723 is an obsolete Microsoft VPN with broken MS-CHAPv2 crypto. They share the “VPN gateway” role but none of the underlying machinery.

How do I secure or close port 1701?

Never expose plain L2TP — require L2TP/IPsec and confirm IPsec actually comes up (including after reboots). Use a strong, unique IPsec PSK or certificates, disable IKEv1 Aggressive Mode, add MFA on the user login, and patch the L2TP stack. Firewall UDP 1701/500/4500 to known peers where possible, or migrate to OpenVPN/WireGuard/IKEv2. If nothing uses the VPN, stop the service and confirm the port is closed with a rescan.

TL;DR

• Service: L2TP (Layer 2 Tunneling Protocol) — tunnels PPP for remote-access and site-to-site VPNs
• Default port: 1701/UDP (real deployments also use UDP 500 + 4500 for the IPsec layer, ESP on IP protocol 50)
• Biggest risk: L2TP encrypts nothing on its own — plain L2TP with no IPsec is a cleartext tunnel leaking credentials and data (a config weakness, not a CVE)
• Also watch: the security of an “L2TP VPN” is the IPsec layer on port 500 (Aggressive Mode PSK cracking, weak/shared PSKs), plus L2TP-stack CVEs (Windows RAS RCE CVE-2023-21543, Cisco IOS XE DoS CVE-2023-20227, MikroTik cleartext-downgrade CVE-2017-6297)
• Mitigation: never run plain L2TP; strong unique IPsec PSK or certs + IKEv2, MFA on user auth, patch the stack, restrict 1701/500/4500, or move to OpenVPN/WireGuard/IKEv2