nf_tables and iptable_filter kernel modules fail with "Operation not permitted" on Trusted Launch VM despite Secure Boot disabled

Question

VM: Standard_D4as_v5, Trusted Launch, Debian 12, kernel 6.1.0-52-cloud-amd64, region westeurope

Timeline:

• 2026-08-09: emergency-mode boot failure, VM resized D2as_v5 to D4as_v5
• Since then: nf_tables and iptable_filter kernel modules fail to load with "Operation not permitted" on modprobe/insmod

Troubleshooting performed (all ruled out as cause):

• Secure Boot: securityProfile.uefiSettings.secureBootEnabled=false set via az vm update, followed by full deallocate/start cycle. Confirmed directly in serial console boot log: "secureboot: Secure boot disabled"
• Kernel lockdown: /sys/kernel/security/lockdown shows [none] (inactive)
• No relevant /etc/modprobe.d/ blacklist entries
• Tomoyo LSM active but 0 enforcement violations logged
• Module signatures (modinfo -F signer/sig_key) identical between working (ip_tables, x_tables) and failing (nf_tables, iptable_filter) modules, both signed with "Build time autogenerated kernel key"
• Reinstalled linux-image-6.1.0-52-cloud-amd64 package plus regenerated initramfs, issue persists identically after reboot
• Root has cap_sys_module capability confirmed via capsh --print
• GuestAttestation extension installed successfully but no corresponding service/logs found on the guest

Additional finding possibly related:

• Serial console boot log shows: "tpm_crb VTPM0101:00: [Firmware Bug]: Bad ACPI memory layout" and "Disabling hwrng" despite vTpmEnabled=true in the VM security profile

Impact:

ufw.service fails to start (iptables-restore: unable to initialize table 'filter'). fail2ban partially functional (can add bans via direct iptables calls but lacks full nf_tables/iptable_filter infrastructure).

Question: Is this a known issue with vTPM/attestation state inconsistency following a VM resize on Trusted Launch VMs, or something else? What is the recommended remediation path?

Answer 1

Hello @Michal Hrcka

Yes, known bug - vTPM state corruption after resize on Trusted Launch.

Your boot log tpm_crb: Bad ACPI memory layout + Disabling hwrng = vTPM NVRAM got out of sync when you resized D2as -> D4as. When vTPM is broken, Debian cloud kernel blocks nf_tables/iptable_filter with EPERM even though lockdown says [none] and Secure Boot says disabled. GuestAttestation extension installs but never starts for same reason.

Fix:

Don't troubleshoot modules - fix vTPM:

Bash

# 1. Remove attestation extensionaz vm extension delete -g RG -n VM --name GuestAttestation
# 2. Disable vTPM + SecureBoot fully and force re-create TPMaz vm update -g RG -n VM --set securityProfile.uefiSettings.vTpmEnabled=false securityProfile.uefiSettings.secureBootEnabled=falseaz vm deallocate -g RG -n VMaz vm update -g RG -n VM --set securityProfile.uefiSettings.vTpmEnabled=true securityProfile.uefiSettings.secureBootEnabled=falseaz vm start -g RG -n VM

If still Bad ACPI layout -> VM is stuck in Trusted Launch with broken TPM. Only clean fix is redeploy to Standard security type - you can't downgrade Trusted Launch in place:

Create snapshot of OS disk > create new disk > create new VM with --security-type Standard - then nf_tables loads fine.

For prod, avoid resizing Trusted Launch VMs - always deallocate before resize.

---

If this answers your query, do click Accept Answer and Up-Vote for the same. And, if you have any further query do let us know.

Answer 2

Hello Michal Hrcka, 

Thank you for the detailed troubleshooting notes. 

From the information shared so far, we cannot confirm a known vTPM or attestation state inconsistency after the VM resize. In Azure Trusted Launch, vTPM supports boot-chain measurement and remote attestation, while Secure Boot verifies signed boot components and kernel drivers. Because Secure Boot is disabled and kernel lockdown shows [none], the current evidence does not point directly to Azure Trusted Launch or vTPM preventing the nf_tables or iptable_filter modules from loading. 

At this point, the issue appears more likely to be within the guest OS/kernel/module-loading path. The next step is to capture the exact kernel-side denial reason immediately after reproducing the failure: 

sudo modprobe -v nf_tables

 sudo modprobe -v iptable_filter 

sudo dmesg -T | egrep -i "nf_tables|iptable_filter|module|lockdown|signature|tomoyo|apparmor|secure|permission|denied|taint" 

sudo journalctl -k -b | egrep -i "nf_tables|iptable_filter|module|lockdown|signature|tomoyo|apparmor|secure|permission|denied"

 

Please also confirm whether the issue is limited to the current kernel by booting into an earlier installed kernel, if available, or by testing with another supported Debian kernel package. You can also compare the behavior with a newly deployed Debian 12 Trusted Launch VM in the same region and with the same VM size. 

Recommended remediation path: 

• Take a snapshot or back up the OS disk before making any further changes. 
• Try booting into an earlier known-good kernel, if one is available. 
• Reinstall or install an alternate supported Debian kernel, then regenerate initramfs. 
• If the issue remains specific to this VM, test with a clean Debian 12 Trusted Launch VM in the same region and size. 
• If the clean VM works, continue with guest OS repair using a rescue VM or migrate the workload to the clean VM. 

Keep the TPM-related serial console message as a data point, but on its own it does not confirm that vTPM or attestation is blocking the kernel modules. The key evidence we need is the kernel log entry generated at the time modprobe or insmod fails.