xFirewall does not handle Any keyword for RemoteAddress

[jrudley]

No description provided.

[jrudley]

This is in the dev branch

[PlagueHO]

It should handle it - what is the error you're seeing when using it? Are you able to post the DSC output?

[jrudley]

use the sample Sample_xFirewall_AddFirewallRule.ps1
Add RemoteAddress = 'Any'

Looking at the psm1 file, there is no code to handle 'Any' for RemoteAddress.

[jrudley]

fwRemoteAddress.txt
dsc output

[PlagueHO]

Thanks @jrudley. The thinking was that there wasn't any special code to handle these special values like 'any' because they are handled by the underlying cmdlets. That being said, I'll take a look at this this weekend.

[PlagueHO]

Hi @jrudley - I'm working on this at the moment. I have managed to replicate the problem.

[PlagueHO]

The problem is actually caused by the Group parameter in the example. This is a limitation with the underlying Set-NetFirewallRule cmdlets. Once a Firewall rule has been created, the Group/DisplayGroup can't be changed by the Set-NetFirewallRule cmdlet. This is because the cmdlet uses those values as the index values that identify the rule to change.

** For now, if you remove the Group parameter from the example it will work correctly (it will always work correctly the first run - only subsequent runs will fail). **

I'll leave the issue open while I try and figure out a solution.

Possible Solutions (for discussion with @tysonjhayes):

1. Change Set-TargetResource and Test-TargetResource so that the Group and Display Group are never compared/updated - only set when created. Not an ideal solution.
2. Change Set-TargetResource so that if Group or Display Group for a rule needs to be changed then a Remove-NetFirewallRule is called, followed by a New-NetFirewallRule (essentially recreating the rule). However, this may be damaging to built-in rules. Still not a perfect solution.
3. For investigation - it might be possible to change the Group or Display Group using a WMI object. Worth investigating further?

[PlagueHO]

We still need to come up with a solution to this. But, as PS is now open sourced, it might actually be possible to resolve the problem by changing the actual Set-NetFirewallRule cmdlet - which is actually causing the problem. It is probably worth raising an issue in the PS Repo.

[wellsluo]

I hit the similar bug in version 2.11.0.0 (xNetworking). Exception "AmbiguousParameterSet" was thrown when calling Set-NetFirewallRule cmdlet. I reviewed the code MSFT_xFirewall.psm1, it already handled how to change group name by removing and recreating the firewall rule. However, it doesn't handle of the issue when calling Set-NetFirewallRule cmdlet.

Cause:
The cause was the parameters when calling Set-NetFirewallRule. As PlagueHO mentioned, this cmdlet uses "Group" and "Name" as different parameter sets index, so "Group" and "Name" cannot be in the parameters at the same time. Otherwise, it throws the exception "AmbiguousParameterSet".

Code Review:
Let have a quick look of the code from line 316 to 357:

316          # If the Group is being changed the **the** rule needs to be recreated
                if ($PSBoundParameters.ContainsKey('Group') `
                    -and ($Group -ne $FirewallRule.Group))
                {
                     ...
341        }
                else
                {
                    # If the DisplayName is provided then need to remove it
                    # And change it to NewDisplayName if it is different.
                    if ($PSBoundParameters.ContainsKey('DisplayName'))
                    {
                        $null = $PSBoundParameters.Remove('DisplayName')
                        if ($DisplayName -ne $FirewallRule.DisplayName)
                        {
                            $null = $PSBoundParameters.Add('NewDisplayName',$Name)
                        }
                    }

                    # Set the existing Firewall rule based on specified parameters
                    Set-NetFirewallRule @PSBoundParameters
357        }

Lines between 317 to 341 process the situation if group name was changed for specific firewall rule. Let's see the code in "else" bucket. It includes following 2 conditions:

1. $PSBoundParameters.ContainsKey('Group') and ($Group -eq $FirewallRule.Group),
2. !$PSBoundParameters.ContainsKey('Group')

For the 2nd condition, the code works fine since there is no "Group" property in the parameters.

For the 1st condition, issue comes since both "Group" and "Name" properties are in the parameters. So the exception will be thrown.

So simple suggestion for the solution: just remove "Group" property from the parameters. Since we won't change rule name (simply create a new one if you do want to change name), Set-NetFirewallRule will work like it should do.

Solution:

Before line 355 (Set-NetFilewallRule @PSBoundParameters), add following code:

               #If the Group is provided, then need to remove it.
                if ($PSBoundParameters.ContainsKey('Group'))
                {
                    $null = $PSBoundParameters.Remove('Group')
                }

[PlagueHO]

Hi @wellsluo - thanks for the detailed description of a possible solution to this issue! And sorry for not looking into this sooner.

What I'd like to do is first implement some failing tests around this and then put your fix in. Are you able to provide me with a config example that fails with the AmbiguousParameterSet exception?

[affieuk]

I've just come across this issue:

TEST-2012 VERBOSE   13/02/2018 16:38:19 [TEST-2012]:                            [[xFirewall]WinRM] Test-RuleProperties: RemoteAddress property value 'Any' does not match desired state '192.168.1.0/24,172.16.1.1/32'.
TEST-2012 ERROR     13/02/2018 16:38:19 This event indicates that a non-terminating error was thrown when DSCEngine was executing Set-TargetResource on MSFT_xFirewall DSC resource. FullyQualifiedErrorId is AmbiguousParameterSet,Set-NetFirewallRule.    
                                             Error Message is Parameter set cannot be resolved using the specified named parameters..                                                                                                                            
TEST-2012 ERROR     13/02/2018 16:38:19 MIResult: 1                                                                                                                                                                                                         
                                             Error Message: Parameter set cannot be resolved using the specified named parameters.                                                                                                                               
                                             Message ID: AmbiguousParameterSet,Set-NetFirewallRule                                                                                                                                                               
                                             Error Category: 5                                                                                                                                                                                                   
                                             Error Code: 5                                                                                                                                                                                                       
                                             Error Type: MI

The following code works:

Configuration Firewall
{
    Import-DSCResource -ModuleName xNetworking

    Node "Firewall"
    {
        xFirewall WinRM {
            Name = 'WINRM-HTTPS-In-TCP'
            Enabled = $true
            DisplayName = 'Windows Remote Management (HTTPS-In)'
            Group = 'Windows Remote Management'
            Protocol = 'TCP'
            LocalPort = 5986
        }
    }
}
Firewall

The following gives the AmbiguousParameterSet exception:

Configuration Firewall
{
    Import-DSCResource -ModuleName xNetworking

    Node "Firewall"
    {
        xFirewall WinRM {
            Name = 'WINRM-HTTPS-In-TCP'
            Enabled = $true
            DisplayName = 'Windows Remote Management (HTTPS-In)'
            Group = 'Windows Remote Management'
            Protocol = 'TCP'
            LocalPort = 5986
            RemoteAddress = ('192.168.1.0/24','172.16.1.1/32')
        }
    }
}

Firewall

Some points to keep in mind.

1. When executing Update-DscConfiguration after the first failure, no error is returned:

VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' = PerformRequiredConfigurationChecks,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' = root/Microsoft/Windows/DesiredStateConfiguration'.
VERBOSE: An LCM method call arrived from computer CHOCOTEST-2012 with user sid S-1-5-21-2247089116-3065529080-3804744930-500.
VERBOSE: [TEST-2012]:                            [] Executing Get-Action with configuration (null)'s checksum: 16A81BB6C69B9F5A1F36F194BE767DDC17043207D27EB5A22B81C1824F1AB238.
VERBOSE: [TEST-2012]:                            [] Executing Get-Action with configuration 's checksum returned result status: Ok.
VERBOSE: [TEST-2012]:                            [] Updated configuration not found on pull server so no action taken. Ensure that a configuration with a different checksum exists on the pull server for target node.
VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Time taken for configuration job to complete is 0.415 seconds

2. It doesn't matter if the firewall rule had 'Any' set or some IP addresses / IP ranges. The error is still the same.

[PlagueHO]

Hi @affieuk - am I correct in understanding you're wanting to change the config on a built-in firewall rule? Or are you wanting to create a new rule?

I think the reason that this works:

Configuration Firewall
{
    Import-DSCResource -ModuleName xNetworking

    Node "Firewall"
    {
        xFirewall WinRM {
            Name = 'WINRM-HTTPS-In-TCP'
            Enabled = $true
            DisplayName = 'Windows Remote Management (HTTPS-In)'
            Group = 'Windows Remote Management'
            Protocol = 'TCP'
            LocalPort = 5986
        }
    }
}
Firewall

is because this is not actually trying to change the built-in rule.

Could you try without specifying a group parameter and see if this works?

[affieuk]

That's exactly what I'm doing, configuring the built-in rule.

It does work without setting the Group parameter, but this does create a new rule and this is my current workaround.

[PlagueHO]

Hi @affieuk - this sounds like the problem I've struggled to effectively solve for nearly 2 years now: #191
#44

The problem mainly stems from the way the Set-NetFirewallRule cmdlet works. It treats both Group and Name as search identifiers. There has been a suggestion that I need to test out, but I haven't had the time to progress it.

Am I correct in understanding the purpose of this config is to restrict WinRM connection to only connecting from either 192.168.1.0/24 or172.16.1.1/32?

[affieuk]

Yes that’s correct, although they’re just example IP’s. DSC wasn’t very happy when I disabled the HTTP rule, during the push operation. Need to see if it’ll automatically switch to HTTPS once that’s configured. Any suggestions for a DSC config to setup WinRM on 5986?