Network Interface Has IP Forwarding Enabled on Azure

IP forwarding on an Azure network interface is one of those settings that looks harmless in the portal but quietly changes the security posture of an entire subnet. By default it is off, and for the vast majority of workloads it should stay that way. When Lensix raises defender_ipforwarding, it has found a NIC that is allowed to forward packets whose source or destination IP does not belong to the VM itself.

That behavior is exactly what a network virtual appliance needs, and exactly what an attacker wants.

---

What this check detects

Every Azure network interface has an enableIPForwarding property. When it is set to true, the Azure host network stops dropping packets where the source IP does not match the NIC's assigned IP, or where the destination IP belongs to a different machine. In plain terms, the VM is permitted to act as a router and pass traffic on behalf of other addresses.

The Lensix check inspects each network interface across your subscriptions and reports any NIC where enableIPForwarding is true. It does not assume the setting is always wrong. It surfaces it so you can confirm whether the VM is a legitimate appliance or an accidental misconfiguration.

---

Why it matters

The legitimate use case is narrow. Firewalls, NAT gateways, software routers, VPN concentrators, and third-party network virtual appliances (NVAs) need IP forwarding so they can sit in the traffic path and relay packets. If you point a user-defined route at one of these VMs, forwarding has to be on or the appliance silently drops everything.

Outside of that, an enabled flag usually means one of three things, and none of them are good.

1. Lateral movement and pivoting

If an attacker compromises a VM that has IP forwarding enabled, they can turn it into a stepping stone. The host becomes a relay that lets them reach subnets or machines they could not address directly. Combined with a misconfigured route table or a permissive NSG, a single foothold turns into network-wide reach.

2. Bypassing network segmentation

Network security groups and user-defined routes assume traffic follows predictable paths. A VM that forwards arbitrary traffic can route packets around controls that were meant to isolate workloads. Your carefully drawn subnet boundaries stop meaning much if one box inside them is happy to ferry packets across.

3. Leftover configuration

Sometimes a VM was an appliance, or was being tested as one, and the route table got deleted while the NIC setting stayed. Now you have a forwarding-capable host with no operational reason to forward, which is pure attack surface for zero benefit.

---

How to fix it

The fix is to disable IP forwarding on any NIC that does not belong to a network appliance. Before you do, confirm the VM's role.

Step 1: Identify why forwarding is enabled

Check whether any route table sends traffic to this VM as a next hop. If nothing routes through it, it almost certainly does not need forwarding.

# List route tables and their routes that point at virtual appliances
az network route-table list \
  --query "[].{name:name, routes:routes[?nextHopType=='VirtualAppliance'].{prefix:addressPrefix, nextHop:nextHopIpAddress}}" \
  -o json

Cross-reference the next-hop IPs against the private IP of the flagged NIC. A match means the VM is acting as an appliance. No match is a strong signal the flag is unnecessary.

Step 2: Confirm the current NIC setting

az network nic show \
  --resource-group myResourceGroup \
  --name myNic \
  --query "enableIpForwarding" -o tsv

Step 3: Disable IP forwarding

az network nic update \
  --resource-group myResourceGroup \
  --name myNic \
  --ip-forwarding false

The change applies immediately and does not require a VM restart. Re-run the check or the show command to confirm enableIpForwarding is now false.

Console steps

1. Open the Azure Portal and navigate to Network interfaces.
2. Select the flagged NIC.
3. Under Settings, choose IP configurations.
4. Set IP forwarding to Disabled.
5. Click Save.

Step 4: Disable forwarding in the guest OS (optional cleanup)

If the VM was previously a router, the guest OS may still have kernel forwarding on. Turning it off removes the second half of the capability.

# On a Linux guest
sudo sysctl -w net.ipv4.ip_forward=0
# Persist it
sudo sed -i 's/^net.ipv4.ip_forward.*/net.ipv4.ip_forward=0/' /etc/sysctl.conf

# Find every NIC with forwarding enabled
az network nic list \
  --query "[?enableIpForwarding].{name:name, rg:resourceGroup}" -o tsv \
  | while read name rg; do
      echo "Disabling IP forwarding on $name in $rg"
      az network nic update --resource-group "$rg" --name "$name" --ip-forwarding false
    done

---

Fixing it in infrastructure as code

If your NICs are managed by Terraform, the property lives on the azurerm_network_interface resource. Set it explicitly so drift does not creep back in.

resource "azurerm_network_interface" "app" {
  name                  = "app-nic"
  location              = azurerm_resource_group.main.location
  resource_group_name   = azurerm_resource_group.main.name
  ip_forwarding_enabled = false   # default, but be explicit

  ip_configuration {
    name                          = "internal"
    subnet_id                     = azurerm_subnet.app.id
    private_ip_address_allocation = "Dynamic"
  }
}

For your actual appliance NICs, set it to true and leave a comment explaining why. That comment is the difference between a reviewer trusting the setting and a reviewer reverting it six months later.

resource "azurerm_network_interface" "fw" {
  name                  = "firewall-nic"
  location              = azurerm_resource_group.main.location
  resource_group_name   = azurerm_resource_group.main.name
  ip_forwarding_enabled = true   # required: this VM is the NVA next hop for rt-app

  ip_configuration {
    name                          = "internal"
    subnet_id                     = azurerm_subnet.transit.id
    private_ip_address_allocation = "Static"
    private_ip_address            = "10.0.255.4"
  }
}

---

How to prevent it from happening again

Manual fixes do not scale. The goal is to make an unintended forwarding NIC impossible to ship, or at least loud when it appears.

Azure Policy

Write a policy that audits or denies network interfaces with forwarding enabled, then exempt the resource groups or NICs that genuinely host appliances. Start in audit mode so you can see scope before you enforce.

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Network/networkInterfaces"
      },
      {
        "field": "Microsoft.Network/networkInterfaces/enableIPForwarding",
        "equals": true
      }
    ]
  },
  "then": {
    "effect": "audit"
  }
}

Once you have confirmed only appliances trip the policy, switch the effect to deny and add exemptions for the appliance resource groups. New NICs that flip the flag without an exemption get rejected at deploy time.

CI/CD gates

If you use Terraform, run a plan-time check that fails the pipeline when a NIC sets forwarding to true without an approved exception. Tools like Checkov, tfsec, or a small OPA Conftest policy can do this. A Conftest rule looks like this:

package main

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "azurerm_network_interface"
  resource.change.after.ip_forwarding_enabled == true
  not approved_appliance(resource.change.after.tags)
  msg := sprintf("NIC %s enables IP forwarding without role=nva tag", [resource.address])
}

approved_appliance(tags) {
  tags.role == "nva"
}

Now a developer who accidentally copies an appliance NIC config into an app VM gets a failed build with a clear message instead of a silent misconfiguration in production.

Continuous monitoring with Lensix

Policy and CI catch new resources. Continuous scanning catches the ones changed out of band, through the portal, an emergency fix, or a script someone ran at 2am. Keep defender_ipforwarding running on a schedule so a NIC that gets flipped after deployment shows up in your findings within the next scan cycle rather than during an incident.

---

Best practices

• Treat forwarding as appliance-only. If a NIC has it enabled and the VM is not a documented firewall, router, NAT box, or NVA, the answer is to disable it.
• Document every exception. Tag appliance NICs and leave a comment in IaC. An undocumented true is indistinguishable from a mistake.
• Pair forwarding with tight NSGs. Appliances that legitimately forward traffic should still have network security groups that constrain what they can route, so a compromised appliance has limited reach.
• Check route tables alongside NICs. A forwarding NIC with no route pointing to it is dead weight. A route pointing to a NIC without forwarding is a silent outage. Audit them together.
• Minimize the number of NVAs. Where Azure Firewall, NAT Gateway, or managed routing can replace a self-managed appliance, you remove a forwarding-enabled VM and the maintenance burden that comes with it.
• Re-validate after migrations. Lift-and-shift and disaster recovery copies often carry forwarding settings into environments where they no longer make sense.

IP forwarding is a small flag with outsized consequences. Keep it off everywhere except the handful of appliances that earn it, gate it in your pipelines, and let continuous scanning catch the drift. That combination turns a quiet pivot path into a non-issue.