You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm in a spot where I need to manually create an ipsec policy for a VPN in our virtual wan due to the portal having a required field where I must set "None", but that's not an option.
With that said I'm using New-AzIpsecPolicy to create the following policy, but it bombs citing PFS14 is not a valid value for property PfsGroup and that valid values are None,PFS1,PFS2,PFS2048,PFS24,ECP256,ECP384.
C:\> $newIpsec = New-AzIpsecPolicy `
>> -IpsecEncryption None `
>> -IpsecIntegrity SHA256 `
>> -IkeEncryption AES256 `
>> -IkeIntegrity SHA256 `
>> -PfsGroup PFS14 `
>> -DhGroup DHGroup14 `
>> -SADataSizeKilobytes 2147483647 `
>> -SALifeTimeSeconds 14400
>>
New-AzIpsecPolicy:
Line |
6 | -PfsGroup PFS14 `
| ~~~~~
| Cannot validate argument on parameter 'PfsGroup'. The argument "PFS14" does not belong to the set "None,PFS1,PFS2,PFS2048,PFS24,ECP256,ECP384" specified by the ValidateSet attribute. Supply an argument that is in the set and then try the command again.
Research suggested using PFS2048 as an inline replacement, and I did. However, when I assign this policy to a vpn connection and run Update-AzVpnConnection, that then bombs citing PFS2048 is not a valid value for PfsGroup and accepted values are None,PFS14,PFS24,ECP256,ECP384
C:\Users\158088> Update-AzVpnConnection -ResourceGroupName $vwanRgName -ParentResourceName $vpnGwName -Name $vpnConnName -VpnSiteLinkConnection $siteLinkConn
Update-AzVpnConnection: Invalid PfsGroup specified for Resource <redacted>. The allowed PfsGroup values are None,PFS14,PFS24,ECP256,ECP384.
To get around this I created my own custom policy object of typename Microsoft.Azure.Commands.Network.Models.PSIpsecPolicy passing a hash table of the properties and values I need to it and that seems to have worked.
I'm just wondering, why would one support PFS2048 but the other PFS14? Shouldn't these two (and likely more) vpn related cmdlets support the same values? Is this worthy of an issue being filed?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm in a spot where I need to manually create an ipsec policy for a VPN in our virtual wan due to the portal having a required field where I must set "None", but that's not an option.
With that said I'm using
New-AzIpsecPolicy
to create the following policy, but it bombs citing PFS14 is not a valid value for property PfsGroup and that valid values are None,PFS1,PFS2,PFS2048,PFS24,ECP256,ECP384.Research suggested using PFS2048 as an inline replacement, and I did. However, when I assign this policy to a vpn connection and run
Update-AzVpnConnection
, that then bombs citing PFS2048 is not a valid value for PfsGroup and accepted values are None,PFS14,PFS24,ECP256,ECP384To get around this I created my own custom policy object of typename Microsoft.Azure.Commands.Network.Models.PSIpsecPolicy passing a hash table of the properties and values I need to it and that seems to have worked.
I'm just wondering, why would one support PFS2048 but the other PFS14? Shouldn't these two (and likely more) vpn related cmdlets support the same values? Is this worthy of an issue being filed?
Beta Was this translation helpful? Give feedback.
All reactions