Layer 2 Forwarding is a virtual private network tunnelling protocol that carries Layer 2 frames across an IP network to extend link-level connectivity. It is often paired with IPsec for confidentiality and integrity. Defenders should restrict who can build tunnels, authenticate peers and watch for bridged traffic that bypasses segmentation controls.
What Layer 2 Forwarding actually does
layer 2 forwarding extends a local Ethernet domain across an IP network by encapsulating Layer 2 frames inside a transport tunnel. That makes two endpoints behave as if they are on the same link, so broadcasts, broadcasts-based discovery, and link-level adjacency can traverse a routed backbone. It is a connectivity mechanism first, not a security control.
The practical consequence is that network design choices at the edge matter more than the tunnel name itself. If the tunnel is used to join sites, extend VLAN-like reach, or support legacy systems, the operator is effectively choosing to preserve Layer 2 semantics across a network that is otherwise segmented by Layer 3 boundaries.
How the encapsulation and delivery path works
A Layer 2 Forwarding session takes each incoming frame, wraps it in a tunnel header, and sends it across the IP path to the peer endpoint. The receiving side removes the tunnel wrapper and injects the original frame into the local Layer 2 domain. When the tunnel is up, each endpoint forwards traffic as though the remote side were a directly attached switch port.
Because the tunnel preserves Ethernet behavior, it also preserves Ethernet problems. Broadcast traffic, unknown unicast flooding, and some discovery protocols can cross the tunnel unless the platform or policy constrains them. That is why deployments often pair the tunnel with IPsec for confidentiality and integrity, and why the tunnel endpoints themselves become high-value control points.
In a broader remote-access or site-connectivity design, the tunnel endpoint should be treated like an infrastructure trust boundary. NHIMG's VPN Security Guide is useful here because the same operational questions recur: who may establish the tunnel, how it is hardened, and how it is monitored after deployment.
Why Layer 2 forwarding changes the security posture
The main security issue is not the encapsulation itself, but the trust expansion it creates. A bridge that spans sites can let traffic bypass segmentation assumptions, especially when teams expect Layer 3 policy boundaries to contain lateral movement. If an endpoint is compromised, the tunnel can become a path for exposure that looks “internal” to downstream systems.
That is also why the authentication and authorization model around the tunnel matters. If peers are not strongly authenticated, an attacker may try to impersonate a trusted endpoint, join the link, and inherit the bridged network relationship. If the tunnel is over-permissive, the compromise of one side can expose services, discovery traffic, and management interfaces that were never meant to be reachable across that boundary.
For defenders, this is a segmentation and trust problem as much as it is a transport problem. The tunnel should be designed so that its existence does not quietly undo the security assumptions made elsewhere in the network.
Risk and Threat Considerations
Layer 2 Forwarding can undermine segmentation when operators assume the tunnel is only a transport detail. The risk increases if the bridged domain carries sensitive workloads, management traffic, or legacy protocols that were never intended to traverse a wide-area path.
Failure mechanism: A trusted tunnel endpoint or bridged host can become a pivot point, allowing attackers or misconfigured systems to move Layer 2 reachability across an IP network and bypass controls that were built around routed boundaries.
Impact: Unauthorized adjacency, wider broadcast exposure, and lateral movement opportunities can follow, especially when the bridged segment contains assets that were presumed isolated by design.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Asset Management | Layer 2 forwarding changes network trust boundaries and reachable assets. |
| PR.SC-07 — Boundary Protection | The tunnel extends connectivity across a network boundary that must be protected. | |
| Recommendation — Inventory bridged segments and restrict tunnel paths to approved assets. Enforce boundary controls on tunnel endpoints and filter unintended bridged traffic. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Layer 2 tunnelling can bypass segmentation unless flows are explicitly controlled. |
| IA-2 — Identification and Authentication (Organizational Users) | Tunnel endpoints should authenticate trusted administrators and operators. | |
| Recommendation — Apply flow controls to limit which traffic can traverse the bridged link. Require strong authentication before allowing tunnel administration. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | The subject concerns secure network connectivity and segmentation across a tunnel. |
| Recommendation — Define and enforce network security controls for any bridged tunnel path. | ||
Practitioner Guidance
What to verify: Confirm exactly which networks, VLANs, or subnets are being extended and whether that adjacency is still justified. If the answer is “only because the tunnel exists,” treat that as a design smell and challenge the requirement.
Decision rule: If the tunnel is needed only to connect applications, prefer a routed or more tightly scoped design; if Layer 2 extension is unavoidable, keep the bridged domain as small as possible and tightly bound to a documented business need.
What good looks like: Peer authentication is mandatory, tunnel creation is restricted to approved systems, and monitoring can distinguish expected bridged traffic from broadcast or discovery patterns that should not appear across the link.
Practitioner takeaway: Treat Layer 2 Forwarding as a trust-expanding architecture choice, not just a transport feature, because the main danger is usually the security boundary it removes rather than the tunnel itself.
Related resources from NHI Mgmt Group
- Why do hybrid fraud controls work better than a single detection layer?
- Why do browser-layer controls matter more as work shifts into SaaS and GenAI apps?
- How should security teams implement human layer security in hybrid work environments?
- What happens when agencies layer new cloud and remote work requirements on top of post-SolarWinds security changes?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org