HNS Container Networking firewall rules for DNS queries are broken after rebooting

[stijnherreman]

Version

Microsoft Windows [Version 10.0.22581.200]

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.10.102.1

Distro Version

Ubuntu 21.04

Other Software

No response

Repro Steps

The initial system state has DNS queries failing, but succeeding when you disable Windows Defender Firewall or when you add an Allow rule for the vEthernet (WSL) network interface.

$ nslookup example.com
;; connection timed out; no servers could be reached

1. Remove all HNS Container Networking inbound rules in Windows Defender Firewall. There may be many existing rules, as observed in WSL2 DNS stops working #4285 (comment)
2. Reboot your system.
3. Verify that there are no inbound rules defined.
4. Launch WSL and perform a DNS query.

   $ nslookup example.com
   Server:         172.17.224.1
   Address:        172.17.224.1#53
   
   Non-authoritative answer:
   Name:   example.com
   Address: 93.184.216.34
   Name:   example.com
   Address: 2606:2800:220:1:248:1893:25c8:1946

5. Verify that there are 2 inbound rules defined.
   
6. Lookup one of the rules by name.

   > Get-NetFirewallRule -DisplayName "HNS Container Networking - DNS (UDP-In) - B95D0C5E-57D4-412B-B571-18A81A16E004 - 0"
   
   
   Name                          : HNS Container Networking - DNS (UDP-In) - B95D0C5E-57D4-412B-B571-18A81A16E004 - 0
   DisplayName                   : HNS Container Networking - DNS (UDP-In) - B95D0C5E-57D4-412B-B571-18A81A16E004 - 0
   Description                   : HNS Container Networking - DNS (UDP-In) - B95D0C5E-57D4-412B-B571-18A81A16E004 - 0
   DisplayGroup                  :
   Group                         :
   Enabled                       : True
   Profile                       : Any
   Platform                      : {}
   Direction                     : Inbound
   Action                        : Allow
   EdgeTraversalPolicy           : Block
   LooseSourceMapping            : False
   LocalOnlyMapping              : False
   Owner                         :
   PrimaryStatus                 : OK
   Status                        : The rule was parsed successfully from the store. (65536)
   EnforcementStatus             : NotApplicable
   PolicyStoreSource             : PersistentStore
   PolicyStoreSourceType         : Local
   RemoteDynamicKeywordAddresses : {}
   
   
   
   > Get-NetFirewallRule -DisplayName "HNS Container Networking - DNS (UDP-In) - B95D0C5E-57D4-412B-B571-18A81A16E004 - 0" | Get-NetFirewallInterfaceFilter
   
   
   InterfaceAlias : vEthernet (WSL)

7. Reboot your system.
8. Verify that there are still 2 inbound rules defined.
9. Launch WSL and perform a DNS query.

   $ nslookup example.com
   ;; connection timed out; no servers could be reached

10. Verify that there are still 2 inbound rules defined.
11. Lookup one of the rules by name.

    > Get-NetFirewallRule -DisplayName "HNS Container Networking - DNS (UDP-In) - B95D0C5E-57D4-412B-B571-18A81A16E004 - 0"
    
    
    Name                          : HNS Container Networking - DNS (UDP-In) - B95D0C5E-57D4-412B-B571-18A81A16E004 - 0
    DisplayName                   : HNS Container Networking - DNS (UDP-In) - B95D0C5E-57D4-412B-B571-18A81A16E004 - 0
    Description                   : HNS Container Networking - DNS (UDP-In) - B95D0C5E-57D4-412B-B571-18A81A16E004 - 0
    DisplayGroup                  :
    Group                         :
    Enabled                       : True
    Profile                       : Any
    Platform                      : {}
    Direction                     : Inbound
    Action                        : Allow
    EdgeTraversalPolicy           : Block
    LooseSourceMapping            : False
    LocalOnlyMapping              : False
    Owner                         :
    PrimaryStatus                 : OK
    Status                        : The rule was parsed successfully from the store. (65536)
    EnforcementStatus             : NotApplicable
    PolicyStoreSource             : PersistentStore
    PolicyStoreSourceType         : Local
    RemoteDynamicKeywordAddresses : {}
    
    
    
    > Get-NetFirewallRule -DisplayName "HNS Container Networking - DNS (UDP-In) - B95D0C5E-57D4-412B-B571-18A81A16E004 - 0" | Get-NetFirewallInterfaceFilter
    
    
    InterfaceAlias : 6558c937-8919-460a-b9d0-bbd3a6fefb2b

As you can see, after rebooting, the firewall rule is no longer applied to the vEthernet (WSL) network interface. This is (to my understanding) because the network interface is recreated on every boot, and is also observed in various comments in #4285, #5256, #4139 when workarounds with firewall rules are suggested.

These steps can be repeated to reliably fix and reproduce the issue each time.

Expected Behavior

The firewall rules are updated after rebooting so they refer to the newly created vEthernet (WSL) network interface, and DNS queries continue working.

Actual Behavior

The firewall rules refer to a network interface that no longer exists, and DNS queries stop working.

Diagnostic Logs

No response

[keith-horton]

Thanks, folks, for reporting this to us. We have addressed it in this next release of WSL: https://github.com/microsoft/WSL/releases/tag/0.70.5. WSL will ensure the Firewall rules which it requires for its NAT configuration are present on the host system.

Thanks!

[Ged-fi]

Finally! This issue has persisted for far too long, and effectively cripples WSL2 usage on many platforms. I trust the fix is dynamic enough to react to NIC changes in a live system?

[keith-horton]

Finally! This issue has persisted for far too long, and effectively cripples WSL2 usage on many platforms. I trust the fix is dynamic enough to react to NIC changes in a live system?

Yep. WSL worked around the entire issue with a single Firewall rule which was crafted specifically for this DNS NAT flow. It's no longer dependent on individual interfaces.

[Ged-fi]

Finally! This issue has persisted for far too long, and effectively cripples WSL2 usage on many platforms. I trust the fix is dynamic enough to react to NIC changes in a live system?

Yep. WSL worked around the entire issue with a single Firewall rule which was crafted specifically for this DNS NAT flow. It's no longer dependent on individual interfaces.

@keith-horton Any chance of linking to the changes/commits? I pulled down the 0.70.5 release, and I'm not seeing a change in behavior.

[stijnherreman]

I've since installed builds 25231 and 25236, and did a couple other reboots. So far so good, the issue seems to be gone on my machine!