Windows Firewall does not always display the correct default Main Mode IPsec policy
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
Jason Fossen
shared this idea
2 comments
-
Jason Fossen
commented
Note: The above issue was observed on Windows 10 Pro version 1703 (latest patches) and also on Windows Server 2012 R2 Standard Edition (latest patches).
There is another related problem too. Start with factory default IPsec settings, create new MMCryptoSet in PoSh (call this "X"), open WF snap-in and the GUI still shows using the factory defaults. If you customize the defaults in the GUI (call these proposals "Y"), save changes (OK > OK > OK), come back to the GUI, and it doesn't show the "Y" changes just made, it shows the "X" proposal. Under the hood I'm sure it's the same issue, just a different way an admin might see it.
Expected behavior is 1) for the code behind the GUI to look for the GUID of the default MMCryptoSet and, if found, update the GUI correctly when the property sheet is first opened, and 2) when the default MMCryptoSet is edited in the GUI, this should create or update the correct default MMCryptoSet identified by its GUID. This will keep in sync what's seen in PoSh, what's seen in the WF snap-in, and what the IPsec services or drivers are actually using.
-
Jason Fossen
commented
In my last sentence, it should be "IKEv2", not 3.