Hi all,

I understand there is an issue with Windows Server 2019/Windows 10 1809 however I was wondering if Microsoft are aware of any problems regarding the Firewall rather than the systems handling of user files.

Recently I setup a Server 2019 VM (1.5GB Dynamic RAM, 2 Allocated Cores, 36GB Drive space, 3GB NIC Team) and installed the NPS and RDS Gateway role onto it however I noticed that despite the NPS role adding the standard firewall rules for port 1813 and 1812 they do not seem to be working.

I have confirmed that with an exception allowing port 1812 through or disabling the firewall allows authentication requests to reach the NPS server however when these are removed and the default rules are left they are blocked.

I have performed an SFC scan and DISM scan/repair however no issues have been detected
I have also spun up a new Server 2019 and Server 2016 server to compare and the 2019 server has the same issue whilst the 2016 server has no problems with just the default rules and no exceptions/extra.

If anyone has any suggestions or information I would be extremely great-full as currently I'm not sure what seems to be the cause

Hi,

I'm trying to understand how RSS works and while experimenting, I found out that when Convervative RSS Profile is used with 1 RSS Queue, Indirection Table stay the same, with two processors. Is that correct behavior?

I'm asking, because when I choose other RSS Profile (for example Closest or ClosestStatic), number of the processors in IndirectionTable always match NumberOfRecaiveQueues.

Is that mean that I have some bad version of Powershell/Windows/Drivers or is it correct??

Can anyone help with that?

I've used Set-NetAdapterRss cmdlet to set things up.

Name : test0
InterfaceDescription : Intel(R) Ethernet Converged Network Adapter X550-T2
Enabled : True
NumberOfReceiveQueues : 1
Profile : Conservative
BaseProcessor: [Group:Number] : 0:0
MaxProcessor: [Group:Number] : 0:26
MaxProcessors : 14
RssProcessorArray: [Group:Number/NUMA Distance] : 0:0/0 0:2/0 0:4/0 0:6/0 0:8/0 0:10/0 0:12/0 0:14/0 0:16/0 0:18/0 0:20/0 0:22/0 0:24/0 0:26/0
IndirectionTable: [Group:Number] : 0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
...

"netsh trace" and/or NetEventPacketCapture lacks capable packet filtering. A lot of secure and change managed environments do not [easily] allow the installation of packet capture tools for collecting network data, like Wireshark (or the now defunct netmon and Message Analyzer).

The two built-in packet capture tools in Windows, "netsh trace" and NetEventPacketCapture, can only filter packets by IP address, MAC, and protocol. This makes collecting a targeted trace, sometimes needed when collecting traces on sensitive networks or when other data floods the ETL, impossible.

This is a request to add, at a minimum, the ability to filter packets by TCP port and UDP endpoint. Ideally, Windows inbox packet filtering should be on par with the industry standard tcpdump(*nix)/npcap(Wireshark for windows) filter format.

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

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

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.