Bug:

The Windows Firewall snap-in does not always show the default Main Mode IPsec policy, it shows whatever MM policy was last created or assigned.

Expected Behavior:

Even if there are multiple Main Mode policies (called Main Mode Crypto Sets internally), the policy with the name of '{E5A5D32A-4BCE-4e4d-B07F-4AB1BA7E5FE1}' should always be displayed as the default in the GUI because it is the default used by Windows for IPsec.

Steps to Reproduce:

*In the Windows Firewall snap-in you can see the current default IPsec Main Mode proposal set by going to Properties of the Windows Firewall > IPsec Settings tab > Customize button > select Advanced for Main Mode > Customize button again.

*Delete all MM CryptoSets for IPsec:

Get-NetIPsecMainModeCryptoSet | Remove-NetIPsecMainModeCryptoSet

*The WF snap-in correctly shows it is using the built-in default.

*Change the default for MM by clicking Advanced > Customize > edit some proposals > OK > OK.

*The WF snap-in correctly shows the new default.

*List current MMCryptoSets and you can see that the edited default in the WF snap-in correctly has a name of '{E5A5D32A-4BCE-4e4d-B07F-4AB1BA7E5FE1}':

Get-NetIPsecMainModeCryptoSet

*Add an additional MMCryptoSet in PowerShell:

$MmAes128Sha256Dh19 = New-NetIPsecMainModeCryptoProposal -Encryption AES128 -Hash SHA256 -KeyExchang DH19

$MmCryptoSetAllowDH = New-NetIPsecMainModeCryptoSet -DisplayName 'MMCryptoSetAllowDH' -ForceDiffieHellman $False -Proposal $MmAes128Sha256Dh19

*Confirm the new MMCryptoSet has a different name and that the original default still has its correct original GUID name:

Get-NetIPsecMainModeCryptoSet

*But when you look in the WF snap-in GUI again, the default MM proposal appears to have changed, but it actually hasn't. The WF GUI is showing whatever MMCryptoSet was last created, not the actual default which has a hard-coded GUID to identify it as the default by the IPsec services like IKEEXT.

This is not a caching issue, closing the WF MMC console and opening it again does not fix the display.

It's not a PowerShell issue either, because whether or not the -Default switch is used when creating the MMCryptoSet, the WF snap-in still does not display the real default (identified by GUID), but whatever MMCryptoSet was created last. For example, try creating a third and fourth MMCryptoSet in PowerShell, and whichever one is created last gets displayed in the WF snap-in as the default even though it has the wrong GUID.

This kind of bug drives admins crazy and causes them to give up using IPsec on Windows in favor of competing products.

Also, the Windows Firewall snap-in GUI should be updated to better handle IKEv3 too, for which it is nearly useless, even just for displaying information.

Thanks!
Jason

Bug:

When creating an IPsec rule which uses the IKEv2 keying module in PowerShell, an error is thrown, but it is not likely a PowerShell error, but an underlying bug in Windows.

Expected Behavior:

We should be able to manage IKEv2 IPsec rules however we wish, including creating tunnel mode IKEv2 rules without using RRAS.

Steps To Reproduce:

In PowerShell, the following code should work (notice the KeyModule):

-------start---------
$P1MachineCertOnly = New-NetIPsecPhase1AuthSet -Default <rest of command not shown>

$IPsec3Tunnel = @{
IPsecRuleName = 'IPsec3'
DisplayName = 'IPsec3'
KeyModule = 'IKEv2'
Mode = 'Tunnel'
LocalAddress = '192.168.1.0/24'
LocalTunnelEndpoint = '192.168.1.204'
RemoteAddress = 'XX.51.94.0/24'
RemoteTunnelEndpoint = 'XX.51.94.202'
InboundSecurity = 'Require'
OutboundSecurity = 'Require'
Phase1AuthSet = ($P1MachineCertOnly.Name)
}

New-NetIPsecRule @IPsec3Tunnel

-----------end-----------------

This is the error produced on Windows 10, Server 2012 R2, and Server 2016 Datacenter:

--------begin error----------
New-NetIPsecRule : The choice of key modules is invalid.
At line:15 char:11
+ $IPsec3 = New-NetIPsecRule @IPsec3Tunnel
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (MSFT_NetConSecRule:root/standardcimv2/MSFT_NetConSecRule) [New-NetIPsecRule], CimException
+ FullyQualifiedErrorId : HRESULT 0x80070057,New-NetIPsecRule
-------end error------------

When KeyModule = 'IKEv1' or 'AuthIP', the code works fine, no error, and the tunnel can be established.

The PoSh error and the HRESULT suggests that this is a hard-coded limitation in PoSh or in something underlying, like FirewallAPI.dll. But this shouldn't be the case.

Please advise. Hopefully, my code is wrong somehow. And "use RRAS" or other similar responses is not a useful answer: this is a question specifically about IKEv2 on Windows, not about Microsoft VPN solutions in general, or why managing route tables, firewall rules and traffic selectors is too hard for the average admin, etc.

Thank You,
Jason

The new cmdlets for DNS policies in particular have inconsistent and downright broken support for -WhatIf and -Verbose.

Example:

Add-DnsServerClientSubnet -cn MyDC -Name 'Whatever' -IPv4Subnet 10.0.0.0/32

That works if you explicitly add -WhatIf. But if I make the call inside an advanced function that SupportsShouldProcess and call the outer function with -WhatIf, the preference will NOT carry over. In order to do that, I have to use -WhatIf:$WhatIfPreference.

The same is true with -Verbose, having to use -Verbose:$VerbosePreference because it won't inherit it.

This is true on the cmdlets for:
- Client Subnets
- Zone Scopes
- Query Reoslution Policies

Additionally, -ErrorAction is seemingly ignored; they all throw regardless of the setting, forcing the use of try / catch.

The worst gaffe is Get-DnsServerClientSubnet. It has no -WhatIf support, which is normal for a read-only Get- cmdlet, but if $WhatifPreference is $true, it uses it! It won't return the values. And since there is no -WhatIf parameter to override, I'm having a **** of a time getting around this.

So far I've tried explicitly setting $WhatIfPreference to $false before calling it but it seems like that's not working. Still experimenting.

RFC-4408 (section 3.1.3) https://tools.ietf.org/html/rfc4408#section-3.1.3 defines the use of multi-string records for SPF (DNS TXT records), however the Get- or Add- DNSServerResourceRecord commands do not support this. For the Get- the actual DNS record is truncated to 256 chars, and for the Add- it simply errors out with an invalid propery.

Example of a valid DNS record (that can be configured by the DNS GUI)
$RecordName = "spfrecord"
$RecordText = "v=spf1 ip4:192.168.0.1 ip4:192.168.0.2 ip4:192.168.0.3 ip4:192.168.0.4 ip4:192.168.0.5 ip4:192.168.0.6 ip4:192.168.0.7 ip4:192.168.0.8 ip4:192.168.0.9 ip4:192.168.0.10 ip4:192.168.0.11 ip4:192.168.0.12 ip4:192.168.0.13 ip4:192.168.0.14 include:spf.protection.outlook.com mx -all"
$Zone = "contoso.com"
$Type = "TXT"
$DNSServer = "DC1.contoso.com"
Add-DnsServerResourceRecord -DescriptiveText $RecordText -Name $RecordName -ZoneName $Zone -Txt -ComputerName $DNSServer

When Server 2016 DNS Server has a delgation within a primary zone, CNAME records in that delegation result in queries to the delgation's name servers, not forwarders / root hints.
For example:

Primary zone: one.example
Delegation: foo.one.example, with nameserver ns.bar.com

In that delegated zone, there exists a record:

baz.foo.one.example IN CNAME other.two.example

two.example's zone, hosted by ns.somethingelse.com, has a record:
other.two.example IN A 1.2.3.4

From a client pointed at the DNS server, query baz.foo.one.example.

I would expect the server to query ns.bar.com for baz, receive a reply of other.two.example, and then query either two.example's nameserver, or use the default forwarders to do the same, resulting in a recursive resolution passed back to the client of 1.2.3.4.

What actually happens, in Server 2016, is that only the CNAME is returned. With debug logging enabled, the DNS server issues a query to ns.bar.com for other.two.example, and of course gets a REFUSED response.

In Server 2012 R2, with the same configuration, baz.foo.one.example is resolved recursively to 1.2.3.4.

I'm pretty sure the new behaviour is incorrect?

Thanks,
Rob

"Direct Access" which unfortunately only works for domain joined clients (I dont get it why u made this fantastic technology computer based and not also user based which would also work for non domain joined computers)

Giving customers access to our fileshares via https would be easy then.
Currently almost all products from Microsoft are ready to deploy to external users via https the only thing left is classic filesharing.

I know u want customers to use ur cloud services, but there are also a lot of companys which could not use them for compliance reasons, so please dont forget your on premise product line.

Writing a script to provision a machine - we first remove the IPAddress (and any default gateway), But sometimes there is no address. That;s fine - we just try/catch and move on, liike this:

Try {
Remove-NetIPAddress -InterfaceIndex $IfIndex `
-AddressFamily IPv4 `
-Confirm $false
}
Catch {Write-Verbose 'No IPAddresses found'}

But instead of the nice write-verbose message, we get a fatal error:
Remove-NetIPAddress : No matching MSFT_NetIPAddress objects found by CIM query for instances of the ROOT/StandardCimv2/MSFT_NetIPAddress class on the CIM server:
SELECT * FROM MSFT_NetIPAddress WHERE ((IPAddress LIKE 'False')) AND ((InterfaceIndex = 3)) AND ((AddressFamily = 2)). Verify query parameters and retry.
At line:3 char:5
+ Remove-NetIPAddress -InterfaceIndex $IfIndex `
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (MSFT_NetIPAddress:String) [Remove-NetIPAddress], CimJobException
+ FullyQualifiedErrorId : CmdletizationQuery_NotFound,Remove-NetIPAddress

Please fix this cmdlet so it's trapping can be caught with a catch block.

Enable-NetLldpAgent not useful

The Enable-NetLldpAgent , in order to be useful in proper management of a network, should allow setting TLV subtypes.
Or...........Some options I would prefer:
set TLV 1 to ID subtype 5 (network address) instead of subtype 4 (MAC address)
set TLV 2 to ID subtype 5 (interface name) instead of 3 (MAC address)

include the optional TLV 5 system name

MAC address is easily obtained by other networking tools. Using this as the information for mandatory TLVs is redundant and useless.

And include lldp driver and PS modules in every version of Windows. You can't build a smart network if the individual links are dumb.