Post-S4 Hibernate Resume Routing Thrash with Fast Wi-Fi (AX55/NDIS)

Is it a bug?

• I know this is an issue with the app, and contacting Mullvad support is not relevant.

I have checked if others have reported this already

• I have checked the issue tracker to see if others have reported similar issues.

Current Behavior

On ACPI S4 resume, high-throughput 802.11ax links re-associate and assert default gateway routes faster than wireguard-nt re-evaluates socket binding and WFP (Windows Filtering Platform) filter weight synchronization. The daemon enters a rhythmic handshake retry / drop loop, requiring manual adapter/daemon restart.

This analysis and fix ideas to come are from Gemini Pro, after shakedown on clues.

Expected Behavior

Mullvad should simply connect as laptop wifi comes up, as it has for years, until I installed a fast wifi router, Tp-link AX55, connecting from a fast laptop, Lenovo Legion Slim 7 g7..

The problem them immediately showed up, requiring me to drop wifi, drop mullvad, then reconnect wifi, then after ten seconds or more pause, connect Mullvad. I must do this every time the machine comes up, whether from power on, or lid raise engaging lid-close hibernation.

Steps to Reproduce

1. Have wifi and mullvad connected during a session
2. close lid or power down
3. raise lid or power up
4. observe wifi cycling and mullvad connection cycling on maybe 1 minute interval once wifi starts, never going stable

Failure Logs

Operating system version

Windows 11 Home, very up to date, has been doing this across at least one second tuesday update to present.

Mullvad VPN app version

Occurred on prior version, recent betas, and now 2026.5-beta 2

Additional Information

continuing here with Gemini Pro analysis with fix suggestion;

Proposed Engineering Remediation:

Decouple ACPI Resume from Socket Re-binding: Do not trigger immediate UDP retransmission or socket polling on PBT_APRESUMEAUTOMATIC alone.

Hook IP Helper Route Settlement: Bind wireguard-nt endpoint re-assertion to Windows IP Helper notifications (NotifyRouteChange or NotifyIpInterfaceChange) to confirm default gateway route metric stability and NDIS media-sense readiness before poking the socket.

Explicit Winsock Handle Flush: On resume, issue a clean local socket teardown/rebind (closesocket / re-create WinTUN session handle) rather than attempting to ride out a half-open UDP binding on a shifting interface index.

Platform-Specific WFP Weight Re-evaluation: Ensure WFP enforcement layers re-query interface index binding explicitly after route metric settlement rather than clamping drop-rules to a stale adapter GUID during the 500ms NDIS bring-up window.

Happy to test a beta if you can't duplicate the problem with kit in your lab. It's a very hard fail.