IP forwarding should be disabled unless a virtual machine is intentionally acting as a router or firewall, because enabling it lets the host pass traffic it was not meant to handle. Attackers can abuse such instances for lateral movement, traffic relaying or network bypass. Check each VM’s intended role and flag unexpected forwarding.
What IP forwarding changes on a cloud VM
ip forwarding turns a virtual machine into a transit point for packets that are not addressed to it. That is normal only when the VM is deliberately acting as a router, NAT device, load balancer, or firewall. On ordinary workloads, the setting expands the machine’s role beyond its intended service boundary and makes the host part of the network path.
In Google Cloud and Azure, that matters because a VM with forwarding enabled can stop being just an endpoint and become an enabler for east-west movement or traffic relay. If the workload does not need to move packets for other systems, the safer assumption is that forwarding should stay off and the network path should be handled by purpose-built controls.
That distinction is why reviewing the VM’s design matters more than treating the setting as a generic hardening checkbox. A subnet design, firewall rule set, or hub-and-spoke pattern may depend on a router-style instance, but a standard application server should not inherit that capability by default.
Why disabling it reduces attack paths
When forwarding is enabled on an unexpected VM, an attacker who gains access to that host may be able to use it as a relay point to reach other systems or bypass intended segmentation. That can turn a single compromised instance into a bridge across zones, particularly where the host has broad network reach or privileged routing placement.
It also reduces ambiguity in investigations. If a VM is not supposed to forward traffic, unexpected forwarding activity is a useful signal that the host may be misconfigured, repurposed, or already under abuse. The control therefore protects both exposure and visibility.
For cloud environments, the operational risk is less about the feature itself and more about accidental trust expansion. A forwarding-capable VM can undermine assumptions about where traffic should originate, where it should terminate, and which controls are meant to enforce segmentation.
How to decide whether forwarding belongs on a workload
The right test is role-based. If the instance is an application server, database node, batch worker, or management host, forwarding is usually unnecessary. If it is a router, firewall, VPN endpoint, or similar network appliance, forwarding may be part of its legitimate function and should be documented as such.
That decision should align with the surrounding cloud design. In Google Cloud, route handling and firewall policy should reflect the intended network path. In Azure, the same principle applies to virtual machine networking and any use of the VM as a transit device. If the architecture does not explicitly need the VM to carry transit traffic, do not let the setting remain enabled by habit.
Where forwarding is required, treat the instance as infrastructure with network authority, not as a normal workload. That means narrower access, tighter change control, and clearer monitoring because the blast radius is larger than for a standard server.
Risk and Threat Considerations
Enabled forwarding on an ordinary VM creates a small configuration change with outsized security consequences, because it can convert an endpoint into a transit node. The main risk is not the packet feature itself, but the way it can weaken segmentation and hide lateral movement if the host is compromised.
Failure mechanism: An attacker or misconfiguration uses the VM as a relay, allowing traffic to pass through a system that was not meant to enforce routing, inspection, or zone boundaries. That can support lateral movement, traffic redirection, or bypass of controls that assume the host only serves its own workload.
Impact: The result can be broader internal exposure, harder detection of suspicious paths, and a larger containment problem if the instance is compromised or repurposed without review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Controls routing and segmentation boundaries that IP forwarding can weaken. |
| CM-7 — Least Functionality | Disables unnecessary host capabilities such as packet forwarding on standard workloads. | |
| Recommendation — Restrict VM transit paths and enforce boundary controls for any host allowed to forward traffic. Remove forwarding capability from VMs unless the role explicitly requires it. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity and Access Control | Supports limiting unintended access paths created when hosts can relay network traffic. |
| Recommendation — Limit network reach so non-router VMs cannot act as unintended transit points. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Covers hardened host configuration and disabling unnecessary networking features. |
| Recommendation — Harden VM templates so IP forwarding is disabled by default on non-transit systems. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Applies to controlling secure VM settings and preventing drift in network roles. |
| Recommendation — Track and enforce forwarding settings as part of configuration baselines. | ||
Practitioner Guidance
What to verify: Confirm whether each VM has a documented transit role before allowing forwarding. If the instance is not explicitly part of routing or firewall design, treat enabled forwarding as a misconfiguration.
What to prioritize: Review internet-facing, management, and hub-connected VMs first, because those are the instances most likely to provide useful pivot paths if forwarding is accidentally enabled.
Common mistake: Teams often leave forwarding enabled during testing or image reuse and never remove it. The safer pattern is to disable by default, then re-enable only for a clearly owned network function.
Practitioner takeaway: The control is effective because it preserves role boundaries, not because it blocks one specific attack. If the VM is not supposed to act as part of the network path, forwarding should be off.
Related resources from NHI Mgmt Group
- Guide: Cloud Network Security Guide
- Why should serial port access be disabled on cloud virtual machines such as Google Compute Engine?
- What breaks when security tools only cover AWS, Azure, and Google Cloud?
- How should security teams manage certificates consistently across AWS, Azure, and Google Cloud?
- How should security teams govern multi-cloud IAM across AWS, Azure, and Google Cloud without creating policy drift?
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