1701

Port 1701 is dual-registered with IANA under two service names — l2f (Layer 2 Forwarding) and l2tp (Layer 2 Tunneling Protocol) — across both TCP and UDP. In the IANA registry the l2f rows carry no assignee, contact, or reference, while the l2tp rows are assigned to Andy Valencia; the Registration Date, Modification Date, and Reference columns are blank for all four 1701 rows, so no RFC is cited in the registry itself. The operationally important point for an analyst is that L2TP runs exclusively over UDP, not TCP. L2TP (RFC 2661, August 1999) and its Cisco-origin predecessor L2F (RFC 2341) encapsulate PPP frames for transport across IP networks, building VPN tunnels between an L2TP Access Concentrator (LAC) and an L2TP Network Server (LNS); UDP is chosen deliberately to avoid the TCP-in-TCP meltdown problem of nested tunnels. UDP 1701 carries the L2TP control channel, and L2TPv3 (RFC 3931, 2005) extended the data-link support. TCP 1701 exists only as the IANA parallel reservation: no RFC defines a TCP use, and TCP connections to port 1701 on public infrastructure are essentially all scanner probes or misconfigured clients rather than legitimate traffic. L2TP provides no encryption of its own, so production deployments pair it with IPsec (L2TP/IPsec), which additionally uses UDP 500 (IKE) and UDP 4500 (NAT-T); without IPsec the tunnel travels in cleartext. CVE-2019-14899 (December 2019) let an adjacent attacker infer a VPN client's virtual IP and in some cases inject into tunneled TCP connections — a broad VPN-class flaw in OS networking stacks rather than an L2TP protocol defect. Microsoft deprecated L2TP (and PPTP) for incoming Windows Server RRAS VPN connections in October 2024, steering operators toward SSTP and IKEv2, though L2TP/IPsec remains in wide use on non-Windows appliances and mobile OSes.

IANA assignment

dual service registration l2f (Layer 2 Forwarding) and l2tp (Layer 2 Tunneling Protocol); l2f rows blank assignee/contact, l2tp rows assigned to Andy Valencia; Reference, Registration Date, and Modification Date columns all blank; registered on both TCP and UDP

[Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry lines 3152-3155

Range class

registered (1024–49151)

IANA Reference

blank in the registry — no RFC is cited by IANA (RFC 2661 / RFC 2341 are the protocol definitions but are not listed in the Reference column) [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry lines 3152-3155

Related ports

UDP 500 (IKE) and UDP 4500 (IPsec NAT-T) for L2TP/IPsec; contrast modern VPN ports (OpenVPN, WireGuard)

Primary use

L2TP/L2F VPN tunneling — encapsulates PPP frames between a LAC and an LNS; L2TP runs over UDP exclusively (RFC 2661; L2F RFC 2341; L2TPv3 RFC 3931)

Common software

Windows Server RRAS, MikroTik RouterOS, Cisco IOS/ASA, Ubiquiti UniFi/EdgeOS, pfSense/OPNsense, strongSwan, xl2tpd, native macOS/iOS/Android VPN clients

Security implications

L2TP has no native encryption — paired with IPsec (UDP 500 + UDP 4500) for confidentiality; without IPsec, traffic is cleartext; CVE-2019-14899 (2019) is a VPN-class adjacent-network inference/injection flaw in OS stacks, not an L2TP protocol defect

Typically seen on

VPN concentrators, routers, and firewalls (UDP); responsive TCP 1701 on public hosts is anomalous and likely a scanner probe

TCP vs UDP

TCP 1701 is an IANA parallel reservation only; no RFC defines a TCP transport for L2TP, and legitimate L2TP traffic is UDP — TCP/1701 sees essentially no real traffic [Likely] — https://www.connected.app/ports/1701

Deprecation

Microsoft deprecated L2TP/PPTP for incoming Windows Server RRAS VPN connections in October 2024, recommending SSTP and IKEv2; L2TP/IPsec remains widely used on non-Windows appliances and mobile OSes [Confirmed] — https://techcommunity.microsoft.com/blog/windowsservernewsandbestpractices/pptp-and-l2tp-deprecation-a-new-era-of-secure-connectivity/4263956

Analyst note

Treat 1701 as a VPN signal but verify transport — legitimate L2TP is UDP. TCP/1701 hits are most likely reconnaissance or misconfiguration, not a working service.

Port 1701/udp carries two overlapping IANA registrations in the Service Name and Transport Protocol Port Number Registry: l2f (Layer 2 Forwarding, with a blank assignee) and l2tp (Layer 2 Tunneling Protocol, assignee Andy Valencia). Both appear identically on 1701/tcp as well, and the IANA Reference column is blank for each — so although L2TP is standardized in RFC 2661 (L2TPv2, August 1999) and RFC 3931 (L2TPv3, March 2005), those RFCs are not cited in the registry CSV and the registration/modification date columns are empty. In practice the port is used almost exclusively for L2TP, which originated as a merger of Cisco's L2F and Microsoft's PPTP. All L2TP traffic — both the control channel that establishes and tears down tunnels and the data channel that carries encapsulated PPP payloads — rides on 1701/udp. L2TP by itself provides no confidentiality or strong authentication, so it is normally paired with IPsec as L2TP/IPsec (RFC 3193), where IKE on 500/udp and NAT-T on 4500/udp do the encryption and 1701 carries the inner tunnel. For an analyst, an exposed 1701/udp is worth scrutiny: it is heavily probed for credential brute-forcing, it can be abused as a UDP reflection/amplification vector because misconfigured servers answer unauthenticated control messages, and a tunnel running without IPsec leaks plaintext. CVE-2019-14899 (2019) let an on-path attacker infer that a victim held an L2TP/IPsec VPN connection, learn the assigned VPN IP, and inject data into the active connection across Linux/Unix/BSD; CVE-2003-1029 was a remote DoS in tcpdump's L2TP parser (3.8.1 and earlier). Hosts acting only as VPN clients do not need 1701 open inbound.

IANA assignment

dual registration on this port — l2f (Layer 2 Forwarding; assignee blank) and l2tp (Layer 2 Tunneling Protocol; assignee Andy Valencia); both also registered on 1701/tcp; Reference column blank (no RFC cited in IANA registry); registration/modification dates blank [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1701)

Range class

registered (1024–49151)

Related ports

500/udp (IKE) and 4500/udp (IPsec NAT-T) for L2TP/IPsec; 1723/tcp (PPTP) and 1701/tcp (same dual registration)

Primary use

Layer 2 Tunneling Protocol (L2TP) — carries both control and data messages; L2TPv2 in RFC 2661, L2TPv3 in RFC 3931; commonly run as L2TP/IPsec (RFC 3193)

Other/unofficial uses

legacy L2F (Layer 2 Forwarding, Cisco precursor to L2TP) shares the registration; in ISP networks L2TP carries PPP sessions between LACs (L2TP Access Concentrators) and LNSs (L2TP Network Servers)

Common software

Windows Server RRAS and built-in Windows/macOS/iOS/Android L2TP/IPsec clients; Linux xl2tpd and accel-ppp; SoftEther; MikroTik RouterOS; Cisco ASA/IOS, Juniper SRX, Fortinet FortiGate, DrayTek, Ubiquiti EdgeRouter

Security implications

L2TP offers no encryption alone — must be paired with IPsec; risks include plaintext interception when run bare, credential brute-forcing of exposed services, UDP reflection/amplification (unauthenticated control messages elicit responses), and weak-PSK offline dictionary attacks; CVE-2019-14899 (on-path VPN connection inference + data injection, Linux/Unix/BSD) and CVE-2003-1029 (tcpdump L2TP-parser remote DoS, ≤3.8.1)

Typically seen on

VPN concentrators, ISP edge (LAC/LNS), routers and firewalls offering remote-access VPN

Scanning notes

probed via nmap -sU -sV -p 1701; IPsec/IKE companion checks via ike-scan -M and nmap --script ike-version -sU -p 1701; appears in UDP reflection DDoS toolkits [Likely] — pentestpad port 1701 exploit page (https://www.pentestpad.com/port-exploit/port-1701-l2tp-layer-2-tunneling-protocol)

Analyst note

An open 1701/udp usually means an L2TP/IPsec VPN endpoint. Confirm IPsec is enforced (only ESP-wrapped 1701 traffic accepted); a bare L2TP listener answering unauthenticated control messages is both a confidentiality risk and a reflection-DDoS liability.