-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
xFirewall does not handle Any keyword for RemoteAddress #130
Comments
This is in the dev branch |
It should handle it - what is the error you're seeing when using it? Are you able to post the DSC output? |
use the sample Sample_xFirewall_AddFirewallRule.ps1 Looking at the psm1 file, there is no code to handle 'Any' for RemoteAddress. |
fwRemoteAddress.txt |
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. |
Hi @jrudley - I'm working on this at the moment. I have managed to replicate the problem. |
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):
|
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. |
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: Code Review:
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:
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:
|
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? |
I've just come across this issue:
The following code works:
The following gives the AmbiguousParameterSet exception:
Some points to keep in mind.
|
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? |
That's exactly what I'm doing, configuring the built-in rule. It does work without setting the |
Hi @affieuk - this sounds like the problem I've struggled to effectively solve for nearly 2 years now: #191 The problem mainly stems from the way the 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? |
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? |
No description provided.
The text was updated successfully, but these errors were encountered: