Share via

Windows Server 2025: Firewall Blocks All Traffic from a specific routed subnet when Network Profile is 'Private', despite explicit 'Allow' and IPsec Bypass rules.

Karol Boguski 0 Reputation points
2025-06-09T19:47:48.3033333+00:00

I. Problem Summary

A clean installation of Windows Server 2025 (Standard, non-domain-joined) on a virtual machine (Proxmox VE + VirtIO drivers) systematically and repeatedly blocks all network traffic from a specific, correctly routed VPN subnet (10.7.2.0/24).

Crucially, the connection works for a period of time (e.g., an hour) after the firewall profile is toggled (disabled and then re-enabled), but then inexplicably stops working. This behavior is not exclusive to the "Private" profile and occurs on any active profile.

At the same time, traffic from another, more distant routed VPN subnet (10.8.0.0/24) is handled correctly and remains stable, regardless of the firewall's state. The problem is resolved instantly and temporarily by toggling the active firewall profile off and on again.

II. Network Architecture Description

  • Virtualization Host: Proxmox VE 8.x
  • Virtual Machine: Clean installation of Windows Server 2025 Standard (with the latest VirtIO drivers).
  • VM Network Configuration:
    • Single network interface on the 10.10.60.0/24 network (Proxmox vmbr1).
      • VM IP Address: 10.10.60.20
        • Subnet Mask: 255.255.255.0
          • Default Gateway: 10.10.60.1 (the Proxmox host's bridge address).
          • VPN & Routing Topology:
            • Subnet 10.7.2.0/24 (The Problematic Subnet): This is a WireGuard VPN network terminated within an LXC container on the same Proxmox host (P2). The VPN container's IP is 10.10.60.4. A static route exists on the host: ip route add 10.7.2.0/24 via 10.10.60.4. From the VM's perspective, traffic from this subnet arrives from its default gateway (10.10.60.1).
              • Subnet 10.8.0.0/24 (The Working Subnet): This is a WireGuard VPN network terminated on a remote host (M-1) in a different geographical location. Traffic from this network is routed over a Site-to-Site tunnel, a vRack, and multiple hops before reaching the VM.

III. Observed Behavior (The "Firewall Glitch" Cycle)

  1. A connection from the problematic subnet 10.7.2.0/24 (e.g., RDP or SQL) initially fails.
  2. We disable the active firewall profile on the Windows Server VM (Set-NetFirewallProfile -Enabled False).
  3. The connection from 10.7.2.0/24 can now be established successfully.
  4. We immediately re-enable the firewall profile (Set-NetFirewallProfile -Enabled True).
  5. The existing connection remains active and works correctly for a period of time (e.g., one hour).
  6. After this period, the connection is dropped, and all new connection attempts from the 10.7.2.0/24 subnet are blocked again, returning to step 1.
  7. Throughout this entire cycle, connections from the 10.8.0.0/24 subnet remain stable and unaffected.

IV. Troubleshooting & Remediation Steps Performed

All of the following advanced troubleshooting steps have been performed and have failed to provide a permanent solution:

  1. Network Path Verification: End-to-end network connectivity has been confirmed with ping and tcpdump. Packets from 10.7.2.0/24 correctly arrive at the VM's network interface.
  2. TCP Checksum Offloading Disabled: All checksum offloading features have been disabled on the VM's VirtIO network adapter.
  3. Specific Allow Rules Created: Precise Allow rules for RDP/SQL ports from the 10.7.2.0/24 source, assigned to all profiles, were created. Result: No effect. The block still occurs after a period of time.
  4. Default Rules Disabled: All default "Remote Desktop" group rules were disabled to eliminate conflicts. Result: No effect.
  5. Overarching Allow Rule Created: A single, powerful "MASTER ALLOW" rule permitting any protocol and any port from the 10.7.2.0/24 source was created. Result: No effect. The block still occurs.
  6. IPsec Bypass Rule Created: A New-NetIPsecRule of type Bypass (-Mode None -InboundSecurity None) was implemented to instruct the filtering engine to ignore default policies for the 10.7.2.0/24 subnet. Result: No effect. The block still occurs.

V. Key Question for Microsoft Support

  1. What underlying mechanism in Windows Server 2025, likely related to Network Location Awareness (NLA) or the Base Filtering Engine (BFE), could cause the firewall to "forget" or begin ignoring a valid, existing Allowrule for a specific subnet after a period of time?
  2. Why does this behavior only affect traffic from a locally routed subnet (10.7.2.0/24) and not from a remote, multi-hop routed subnet (10.8.0.0/24), and what undocumented policy could be causing this discrepancy?
  3. Is this a known issue, and is there a registry key, group policy, or other advanced method to permanently designate a specific subnet as "fully trusted" to prevent this periodic re-evaluation and blocking?I. Problem Summary A clean installation of Windows Server 2025 (Standard, non-domain-joined) on a virtual machine (Proxmox VE + VirtIO drivers) systematically and repeatedly blocks all network traffic from a specific, correctly routed VPN subnet (10.7.2.0/24). Crucially, the connection works for a period of time (e.g., an hour) after the firewall profile is toggled (disabled and then re-enabled), but then inexplicably stops working. This behavior is not exclusive to the "Private" profile and occurs on any active profile. At the same time, traffic from another, more distant routed VPN subnet (10.8.0.0/24) is handled correctly and remains stable, regardless of the firewall's state. The problem is resolved instantly and temporarily by toggling the active firewall profile off and on again. II. Network Architecture Description
    • Virtualization Host: Proxmox VE 8.x
    • Virtual Machine: Clean installation of Windows Server 2025 Standard (with the latest VirtIO drivers).
    • VM Network Configuration:
    • Single network interface on the 10.10.60.0/24 network (Proxmox vmbr1).
    • VM IP Address: 10.10.60.20
    • Subnet Mask: 255.255.255.0
    • Default Gateway: 10.10.60.1 (the Proxmox host's bridge address).
    • VPN & Routing Topology:
    • Subnet 10.7.2.0/24 (The Problematic Subnet): This is a WireGuard VPN network terminated within an LXC container on the same Proxmox host (P2). The VPN container's IP is 10.10.60.4. A static route exists on the host: ip route add 10.7.2.0/24 via 10.10.60.4. From the VM's perspective, traffic from this subnet arrives from its default gateway (10.10.60.1).
    • Subnet 10.8.0.0/24 (The Working Subnet): This is a WireGuard VPN network terminated on a remote host (M-1) in a different geographical location. Traffic from this network is routed over a Site-to-Site tunnel, a vRack, and multiple hops before reaching the VM.
    III. Observed Behavior (The "Firewall Glitch" Cycle)
    1. A connection from the problematic subnet 10.7.2.0/24 (e.g., RDP or SQL) initially fails.
    2. We disable the active firewall profile on the Windows Server VM (Set-NetFirewallProfile -Enabled False).
    3. The connection from 10.7.2.0/24 can now be established successfully.
    4. We immediately re-enable the firewall profile (Set-NetFirewallProfile -Enabled True).
    5. The existing connection remains active and works correctly for a period of time (e.g., one hour).
    6. After this period, the connection is dropped, and all new connection attempts from the 10.7.2.0/24 subnet are blocked again, returning to step 1.
    7. Throughout this entire cycle, connections from the 10.8.0.0/24 subnet remain stable and unaffected.
    IV. Troubleshooting & Remediation Steps Performed All of the following advanced troubleshooting steps have been performed and have failed to provide a permanent solution:
    1. Network Path Verification: End-to-end network connectivity has been confirmed with ping and tcpdump. Packets from 10.7.2.0/24 correctly arrive at the VM's network interface.
    2. TCP Checksum Offloading Disabled: All checksum offloading features have been disabled on the VM's VirtIO network adapter.
    3. Specific Allow Rules Created: Precise Allow rules for RDP/SQL ports from the 10.7.2.0/24 source, assigned to all profiles, were created. Result: No effect. The block still occurs after a period of time.
    4. Default Rules Disabled: All default "Remote Desktop" group rules were disabled to eliminate conflicts. Result: No effect.
    5. Overarching Allow Rule Created: A single, powerful "MASTER ALLOW" rule permitting any protocol and any port from the 10.7.2.0/24 source was created. Result: No effect. The block still occurs.
    6. IPsec Bypass Rule Created: A New-NetIPsecRule of type Bypass (-Mode None -InboundSecurity None) was implemented to instruct the filtering engine to ignore default policies for the 10.7.2.0/24 subnet. Result: No effect. The block still occurs.
    V. Key Question for Microsoft Support
    1. What underlying mechanism in Windows Server 2025, likely related to Network Location Awareness (NLA) or the Base Filtering Engine (BFE), could cause the firewall to "forget" or begin ignoring a valid, existing Allowrule for a specific subnet after a period of time?
    2. Why does this behavior only affect traffic from a locally routed subnet (10.7.2.0/24) and not from a remote, multi-hop routed subnet (10.8.0.0/24), and what undocumented policy could be causing this discrepancy?
    3. Is this a known issue, and is there a registry key, group policy, or other advanced method to permanently designate a specific subnet as "fully trusted" to prevent this periodic re-evaluation and blocking?
Windows for business | Windows Server | User experience | Other
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. David Levine 1 Reputation point
    2025-09-30T20:59:10.78+00:00
    0 comments
  2. Joseph Tran 4,000 Reputation points Independent Advisor
    2025-06-10T13:20:33.6866667+00:00

    I think the potential underlying causes and mechanisms for this situation you are facing to is belong to one of these :

    - Network Location Awareness (NLA) and Network Profile Re-evaluation

    Windows uses NLA to classify network interfaces and assign firewall profiles dynamically. If the system detects any change or issue in network identification (such as gateway reachability, routing changes, or subnet presence), it may re-evaluate the network profile, which can reset or change firewall behavior.

    • NLA caches network metadata, but certain routing/topology changes (or lack of expected network responses) can trigger it to "forget" or reassign profiles.
    • This could explain why toggling firewall profile off/on "resets" the state temporarily.
    • Locally routed VPN subnet traffic coming via the default gateway (10.10.60.1) might be treated differently than multi-hop routed traffic.

    - Base Filtering Engine (BFE) State or Resource Leak / Cache Expiry

    • BFE manages all firewall policies and can cache connection states and policies.
    • A bug or limitation in BFE or its interaction with the VirtIO network adapter or VM environment could cause it to drop or stop honoring specific allow rules for a subnet after some timeout.
    • This might be an undocumented caching or state expiration issue that happens only for certain routing/topologies.

    - Windows Filtering Platform (WFP) or Firewall Driver Behavior

    • The Windows Filtering Platform (WFP) underlying firewall infrastructure can behave differently with locally routed versus multi-hop routed traffic due to driver-level packet inspection and classification.
    • VPN termination within an LXC container on the same host might introduce subtle routing/NAT or encapsulation differences that Windows treats differently.

    - Routing and Source IP Determination

    • Since 10.7.2.0/24 traffic comes via a local gateway and is likely routed, Windows might see the source IP but associate it with a different network interface or network profile, causing conflicting rules.
    • The 10.8.0.0/24 subnet traffic arrives through a different interface or tunnel that Windows treats as trusted.

    - Potential Windows 2025 Firewall Bug or Changed Behavior

    • As this is Windows Server 2025 (a recent version), there could be new firewall engine behaviors or regressions affecting hybrid VPN/routed traffic.

    I have some recommend for you to try :

    A. Use Windows Network Isolation Policies to "Trust" the VPN subnet

    • Try explicitly creating a Network Isolation Policy or Trusted Subnet designation for 10.7.2.0/24 via Group Policy or PowerShell, if supported.
    • See if you can add the subnet to the Private Networks or equivalent trusted network list persistently.

    B. Add Persistent Static Routes in Windows VM

    • Confirm the VM itself has explicit static routes to 10.7.2.0/24 via 10.10.60.4 (VPN container) rather than relying on the default gateway.
    • Sometimes Windows firewall reacts better if it knows the exact interface and route for traffic.

    New-NetRoute -DestinationPrefix 10.7.2.0/24 -InterfaceIndex <ifIndex> -NextHop 10.10.60.4

    • You can find the interface index with Get-NetIPInterface.

    C. Check and Adjust Firewall Connection Security Rules

    • Disable or adjust any IPsec policies, connection security rules that might interfere over time.
    • Monitor with Get-NetIPsecRule and remove or temporarily disable suspicious rules.

    D. Increase BFE Logging and Debug

    • Enable verbose firewall and BFE logging to track why the packets are dropped after some time.
    • Use Windows Event Viewer under Applications and Services Logs > Microsoft > Windows > Windows Firewall with Advanced Security.
    • Also enable netsh trace for detailed packet filtering info.

    E. Network Location Awareness Override

    • Use PowerShell or registry to disable NLA on the interface temporarily to test if that stops the periodic profile re-evaluation.

    Set-NetConnectionProfile -InterfaceAlias "Ethernet" -NetworkCategory Private

    or you can find at registry key:

    HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles

    Manually set the profile to Private and lock it. Inside Profiles, you will see several GUID-named keys (e.g., {3a9c3d32-xxxx-xxxx}). Click each and check the ProfileName string to find the one that matches your network name (e.g., "Ethernet", "CorpNetwork").

    *Once found, edit these two values:

    • Category Set it to:

    1 = Private

    0 = Public

    2 = DomainAuthenticated

    *Set a DWord named Category if it doesn't exist yet.

    *To lock it further (optional):

    • You can set permissions on the key to prevent the system from changing it back:
      • Right-click the profile key > Permissions > Deny write access to SYSTEM or NETWORK SERVICE.
      • Use caution — misconfiguring this can break network functions.

     Links for references :

    -https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-networkisolation

    -https://github.com/MicrosoftDocs/windows-itpro-docs/blob/public/windows/client-management/mdm/policy-csp-networkisolation.md

    -https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj721521%28v%3Dws.11%29

    -https://tutorial.wmlcloud.com/windows_server/Windows-Server---Network-Access-Policy-and-Server-and-Domain-Isolation-%28part-4%29---Planning-NAP-DHCP-Enforcement%2C-Domain-and-Server-Isolation.aspx

    -https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-top

    -https://superuser.com/questions/1283316/stop-windows-nla-from-repeatedly-detecting-local-network-as-a-new-unidentified

    -https://learn.microsoft.com/en-us/answers/questions/400385/network-location-awareness-not-detecting-domain-ne

    -https://www.mcbsys.com/blog/2018/03/network-location-awareness-doesnt-identify-domain/

    -https://www.anyviewer.com/how-to/disable-network-level-authentication-2578.html

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.