What Is Layer 2 Forwarding (L2F)?

Layer 2 Forwarding (L2F) shows up most often when a network team inherits a Cisco remote-access design that predates modern VPNs. The problem is simple: the old configuration still works, but almost nobody remembers why it was built that way, how the session flows, or what should replace it.

Topic	Layer 2 Forwarding (L2F)
Vendor Origin	Cisco®
Primary Function	Forwards PPP sessions across an intermediate network
Core Use Case	Legacy dial-up and early remote-access tunneling
Architecture Style	Layer 2 session preservation through encapsulation
Modern Status	Legacy design, largely replaced by newer VPN approaches as of October 2026
Related Concepts	PPP, tunneling, remote access, authentication, encapsulation

What Is Layer 2 Forwarding (L2F)?

Layer 2 Forwarding (L2F) is a Cisco-developed tunneling protocol designed to carry PPP sessions across an intervening network without tearing down the original Layer 2 connection. In plain terms, it lets a remote user dial in, authenticate, and keep a familiar PPP session while the traffic is forwarded to a home gateway or corporate edge device.

This mattered when remote access usually meant dial-up, modem banks, and branch connectivity over public lines. Instead of forcing the remote side to terminate locally and rebuild the session again at the destination, L2F preserved the session state and moved it across the network. That design gave administrators centralized control at a time when remote work was still tied to slow links and legacy access methods.

For network teams studying Cisco history or supporting older infrastructure, L2F is important because it shows an early attempt to separate access control from physical location. That idea still shows up in modern VPN, identity-based access, and zero trust designs, even though the protocol itself is now obsolete in most environments.

Legacy protocols often outlive the reasons they were built, but the design ideas behind them stay relevant. L2F is a good example of that pattern.

Cisco’s early remote-access work and the broader evolution of tunneling are documented in vendor and standards references, including Cisco documentation and the IETF’s later work on tunneling and remote access such as Cisco resources and the IETF’s Layer 2 Tunneling Protocol specifications at RFC Editor.

How Does Layer 2 Forwarding Work?

L2F works by preserving the remote user’s PPP session while wrapping that session inside another transport path to the corporate endpoint. The remote device establishes a local access connection first, then the access server forwards the session over the tunnel to the gateway that actually owns the user relationship and policy decisions.

The key detail is that the remote user does not have to “start over” at the far end. Authentication, session state, and link-layer behavior can be retained across the tunnel, which is why L2F was useful in early remote-access environments. That preserved experience mattered when users expected dial-up behavior, not modern always-on VPN clients.

Here is the basic session flow in practical terms:

1. The remote user connects to a local access point, often through dial-up infrastructure or an access server.

2. The access server negotiates PPP, which is the session type used to establish the link and exchange network-layer parameters.

3. The access server opens an L2F tunnel to the corporate-side endpoint, such as a gateway that centralizes authentication or network access control.

4. The PPP session is encapsulated and forwarded through the tunnel instead of being terminated locally.

5. The remote-side gateway applies policy, accepts the user session, and places the traffic onto the private network.

The difference from Layer 3 routing-based VPN approaches is straightforward. A Layer 3 design forwards packets based on IP routing decisions, while L2F focuses on moving the original Layer 2 session intact. That is why L2F is best understood as a transport-and-preservation mechanism rather than a general-purpose routed VPN.

For historical context on remote access architecture and tunneling, the National Institute of Standards and Technology guidance in NIST publications on remote access and VPN design is a useful baseline, especially when comparing older tunnel-preserving methods with current security expectations.

Why Was PPP So Important to L2F?

Point-to-Point Protocol (PPP) was central to L2F because it was the session format many remote-access systems already used for dial-up connectivity. PPP handled link setup, network-layer protocol negotiation, and authentication in a way that fit the constraints of the time.

That mattered because early enterprise access was not just about moving IP traffic. Many organizations still had mixed protocol environments, and PPP could support multiple network-layer protocols, including IP, IPX, and AppleTalk. If you had to preserve old application access while moving a user across an untrusted network, keeping PPP intact was the practical choice.

PPP also brought useful operational features:

• Authentication support for confirming user identity before access was granted.
• Compression options that helped conserve scarce bandwidth on slower links.
• Protocol negotiation so the session could agree on network-layer behavior.
• Legacy compatibility for older enterprise systems that were not yet pure IP.

The important point is not that PPP was elegant by modern standards. It was that PPP matched the reality of the environment. L2F inherited that reality and tried to preserve it across a tunnel so the user experience stayed consistent from the remote side to the corporate side.

For a modern networking student, this is one of the most useful lessons in Cisco CCNA v1.1 (200-301) study work: protocols are often chosen because they fit a specific operational problem, not because they are forever solutions. Cisco’s official learning and network documentation remains the best place to verify current protocol behavior, while the historical design patterns are still useful for troubleshooting older sites.

How Do the L2F Components Fit Together?

L2F architecture typically involves four pieces: the remote user, the network access server, the tunnel endpoint, and the corporate gateway or home gateway. Each part has a narrow job, and the protocol depends on that separation to preserve access control while the traffic travels over another network.

The network access server is the first termination point for the remote connection. It receives the dial-in or remote session, negotiates PPP, and then forwards the session through the tunnel instead of fully owning the user connection. That makes the NAS the “front door” for the remote side.

The tunnel endpoint is where the forwarded session is finally handled by the corporate side. This endpoint applies policy, authenticates the user if needed, and connects the session to the internal environment. In older enterprise layouts, this separation allowed a company to centralize user management even when the physical access points were spread across different locations.

• Remote user initiates the connection from outside the private network.
• NAS receives and forwards the PPP session.
• Tunnel endpoint receives the encapsulated session and enforces policy.
• Corporate gateway places traffic into the internal network.

This model is valuable to understand because it cleanly separates access control from transport. That idea shows up in later VPN and identity architectures, even when the underlying protocol stack changes completely. The difference is that modern designs usually emphasize encryption, device posture, and centralized identity rather than just preserving a legacy session type.

For reference on broad remote-access principles and control placement, NIST SP 800 guidance on VPN and secure remote access is a strong source, and Cisco’s own documentation is the right place to verify platform-specific behavior in older deployments.

What Were the Main Use Cases for L2F?

L2F was built for the kinds of access problems enterprises faced before broadband and cloud-managed secure access became normal. The most common use case was dial-up remote access, where users connected from home, hotels, or small branch offices through public telephone infrastructure.

That made L2F attractive for companies that wanted a centralized access model without forcing every remote user to terminate directly on the corporate network. A user could connect locally, authenticate through the access server, and still be placed into a centrally managed environment. For administrators, that reduced the need to distribute policy across many disconnected sites.

Typical legacy scenarios included:

• Home workers using dial-up modems before always-on broadband was available.
• Branch offices that needed a consistent remote-access method across multiple locations.
• Mixed-protocol networks that still depended on older application or transport assumptions.
• Centralized authentication models where the corporate side needed to control session admission.

In practice, L2F also helped preserve a user experience that older help desk teams already knew how to support. That may sound minor, but it was a serious operational benefit when remote connectivity had to be reliable and familiar. The cost of changing the access model was often higher than the cost of keeping a legacy tunnel alive, at least for a while.

From a workforce perspective, the evolution away from dial-up remote access is reflected in labor and network administration trends tracked by the U.S. Bureau of Labor Statistics, which continues to show strong demand for network and systems skills as organizations modernize remote connectivity and security architecture.

Why Did L2F Matter in the Evolution of VPN Technology?

L2F mattered because it proved that a remote user’s session could be preserved across an untrusted network without rewriting the entire access model. That was one of the earliest practical demonstrations of what tunneling could do for enterprise networking.

Its influence is mostly architectural. L2F helped establish the idea that access control could live somewhere other than the local physical connection. Later VPN technologies built on the same general concept but improved interoperability, standardization, and long-term deployment flexibility.

That shift mattered for three reasons:

• Broader interoperability became important as multi-vendor networks became normal.
• Standardization reduced dependence on one vendor’s remote-access stack.
• Security expectations changed as threats against remote access became more sophisticated.

Modern teams may never deploy L2F, but they still benefit from understanding its place in the timeline. It helps explain why later tunneling protocols focused so heavily on compatibility and why modern access designs increasingly emphasize identity and endpoint trust rather than location-based assumptions.

The IETF’s remote-access and tunneling work, especially the standards history around RFC Editor publications, shows how the industry moved from vendor-specific tunnel preservation toward more portable and widely implemented approaches. That history is useful when you need to explain why one protocol replaced another instead of just saying, “it is old.”

What Are the Limitations of L2F?

L2F’s limitations are easy to see once you compare it to modern remote access. The protocol was tied to older access models, especially dial-up and early enterprise remote-access infrastructure, so it was never designed for today’s internet-first, cloud-heavy environment.

One major limitation was interoperability. Proprietary or vendor-specific designs can work well inside one ecosystem, but they often create problems when organizations need to support mixed hardware, modern security platforms, or long-lived migrations. If a protocol only makes sense inside one vendor’s architecture, it becomes a maintenance burden later.

Security expectations also changed. Modern remote access is expected to provide strong encryption, strong authentication, device posture evaluation, and centralized logging. L2F was created before those requirements became the baseline for enterprise security planning, so it does not map cleanly to current threat models.

Operationally, L2F can become a problem simply because legacy dependencies are hard to remove. A small number of users, a forgotten branch, or an embedded network appliance can keep an outdated tunnel alive long after the rest of the environment has moved on. That is why legacy protocol support is often more expensive than the protocol itself.

For current security expectations, NIST guidance on secure remote access and the broader NIST Cybersecurity Framework are better planning references than any legacy tunneling design. They reflect how access control, trust, and monitoring are handled now, not how they were handled in the dial-up era.

How Does L2F Compare to Modern Remote Access and Zero Trust?

Modern remote access is built around encryption, interoperability, and identity-centric control. L2F, by contrast, was built to preserve a Layer 2 session and move it across another network, which was a useful answer to an old problem but not a full answer to current security needs.

The biggest design difference is trust. Traditional VPN thinking often assumed that once a user was inside the tunnel, the user could be treated more like an internal participant. Zero Trust takes the opposite view: network location does not create trust, and access should be granted based on identity, device posture, and policy enforcement for each request.

That shift is reflected in current guidance from NIST Cybersecurity Framework and NIST remote-access publications such as SP 800-77. These frameworks emphasize strong controls, continuous verification, and explicit policy enforcement instead of relying on the idea that a session is safe because it is inside a tunnel.

L2F Approach	Preserves a PPP session across a tunnel for legacy remote access
Modern Approach	Uses encrypted, policy-driven access with identity and device checks

That comparison is why L2F remains historically important even though it is no longer the preferred design for current secure access. It represents an earlier stage in the evolution of remote connectivity, where the main goal was continuity of session behavior rather than continuous verification of trust.

How Can You Recognize L2F in a Real Network?

Legacy L2F usually appears in aging Cisco environments, old documentation, or troubleshooting cases where remote-access behavior looks more like dial-up PPP forwarding than modern VPN termination. If you inherit an older site, the first clue is often not the protocol name itself but the architecture around it.

Look for configuration references, old diagrams, or archived change records that mention access servers, PPP forwarding, or corporate-side tunnel endpoints. If the network documentation includes modem banks, dial-in pools, or a separation between access termination and corporate authentication, that is a strong sign that a legacy tunneling design may still be in play.

Administrators should check for:

• Old Cisco remote-access configs with tunnel-related references.
• PPP-based access notes in historical diagrams or runbooks.
• Dial-up or legacy branch dependencies that survived modernization.
• Authentication flows that terminate on a central gateway instead of the local device.

The practical mindset is simple: treat every unknown remote-access dependency as a change-risk item until proven otherwise. Before replacing equipment or redesigning authentication, map how users actually connect, which systems terminate the session, and what policies depend on the old path.

If you are studying for Cisco CCNA v1.1 (200-301), this is the kind of legacy-troubleshooting thinking that still pays off. You may not deploy L2F in a modern lab, but you will absolutely inherit network behavior that only makes sense once you understand how older access models were structured.

How Do You Migrate Away from L2F?

Migration away from L2F starts with inventory, not replacement. You need to know who depends on the tunnel, what kind of access they use, which authentication methods are involved, and whether the current business process assumes a PPP-based path.

After inventory, compare the legacy design to current requirements. If the real need is secure user access from outside the network, a modern VPN or secure access solution may be a better fit. If the real need is policy-controlled access to a few internal applications, a zero trust or application-specific design may be even better.

1. Document all remote users, gateways, and endpoint dependencies.

2. Identify authentication systems, including local accounts, RADIUS, or external identity providers.

3. Map traffic flows so you know where sessions terminate and where policy is enforced.

4. Test a replacement path in a lab or pilot group before touching production.

5. Plan a rollback path in case a specialized user group depends on the old tunnel behavior.

Change management matters here more than the protocol itself. The hardest migration failures usually come from undocumented dependencies, not from the technology swap. A branch office printer, a legacy application, or an old authentication rule can break a cleanup project if no one tested the edge cases.

For practical planning, review current vendor guidance and security frameworks first, then align the migration with business continuity needs. NIST guidance, Cisco documentation, and your internal change-control process should all be part of the same plan.

What Does L2F Teach Network Teams Today?

L2F teaches a simple lesson: network architecture is often about preserving user experience while changing the transport underneath it. That lesson still matters when teams redesign remote work, branch access, and identity-based security.

Even though L2F is obsolete in production for most organizations, it is still useful as a design example. It shows why session preservation was a big deal, why centralized policy was valuable, and how remote-access problems were solved before always-on broadband and cloud access tools became standard.

Modern teams can apply the same thinking in a different way:

• Preserve policy even if the transport changes.
• Centralize identity rather than scattering access rules across devices.
• Design for migration so a legacy path can be retired safely.
• Verify dependencies before assuming a protocol is no longer important.

That is why historical protocols are still worth learning. They help engineers recognize design patterns, not just memorize product names. Once you understand why L2F existed, it becomes easier to understand why modern VPNs, secure access gateways, and zero trust controls look the way they do.

Authoritative guidance on modern access architecture can be found in CISA resources on secure connectivity and in NIST’s cybersecurity publications. Those sources are better for current implementation decisions, while L2F remains useful as a historical reference point and troubleshooting clue.

Conclusion

Layer 2 Forwarding is a Cisco-developed tunneling protocol that forwarded PPP sessions across untrusted networks so remote users could keep their original Layer 2 connection intact. It mattered in the era of dial-up access, early branch connectivity, and centralized remote-access control, but it was eventually replaced by more interoperable and security-focused VPN approaches.

For modern network teams, L2F is mainly a legacy protocol. Its real value today is historical and operational: it helps explain how remote-access architecture evolved, and it gives administrators a reference point when they inherit older Cisco environments that still depend on PPP-based tunneling concepts.

If you are working in an environment with legacy remote access, identify the session flow, document the dependencies, and plan the migration before making changes. If you are studying for Cisco CCNA v1.1 (200-301), use L2F as a reminder that protocol design always reflects the business and security constraints of its time.

Cisco® is a registered trademark of Cisco Systems, Inc.