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

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