Hi, when having clients that use an MX at the head end with alot of windows users connecting to it using L2TP/IPsec client VPN we see the following logmessages at each IPsec Phase 1 negotiation:
msg: received broken Microsoft ID: MS NT5 ISAKMPOAKLEY
msg: invalid DH group 19.
msg: invalid DH group 20.
Now about the broken Microsoft ID: The ID it sends is 9 which corresponds to the MS documentation. So why this is perceived as broken... I don't know. As wireshark also shows this as unkown this could be an issue that nobody really updated their lists or something. I do believe Meraki can do something about this.
However for the invalid Diffie Hellman groups where 19 and 20 are elliptical curves, I did some digging on my own to get around this.
So basically a windows 10 client by default will send 5 IKE phase 1 proposal transforms:
1) AES256, SHA-1, DH20, PSK, 28800
2) AES128, SHA-1, DH19, PSK, 28800
3) AES256, SHA-1, DH14, PSK, 28800
4) 3DES, SHA-1, DH14, PSK, 28800
5) 3DES, SHA-1, DH2, PSK, 28800
And viewing from the wireshark capture, the MX will only accept the fifth one which is the only one with a more legacy DH group.
So was looking around how to change the parameters of the IPsec in windows and found some powershell commands that will help us all.
So up until now I always define my client VPNs via Powershell as split tunnels using these cmdlets:
Add-VpnConnection -Name "Companyname" -AuthenticationMethod Pap -TunnelType L2tp -SplitTunneling -RememberCredential -L2tpPsk "SomeSecretKey" -EncryptionLevel Optional -ServerAddress "hostname-or-IP" -DnsSuffix "companyname.local" -Force
And then I add the routes which only appear when the VPN is up:
Add-VpnConnectionRoute -ConnectionName "Companyname" -DestinationPrefix "10.0.0.0/24"
I also go the the GUI and disable the classfull route add so it does not route the entire 10.0.0.0/8 over the VPN.
To verify this I use:
(Get-VpnConnection -ConnectionName "Companyname").Routes
DestinationPrefix : 10.0.0.0/24
InterfaceIndex :
InterfaceAlias : CompanyName
AddressFamily : IPv4
NextHop : 0.0.0.0
Publish : 0
RouteMetric : 1
PolicyStore :
However this still tells nothing about how the actual IPsec is negotiated so I found next commands to change the negotiation for that connection alone and verify it:
Configure:
Set-VpnConnectionIPsecConfiguration -ConnectionName "Companyname" -DHGroup 2 -EncryptionMethod DES3 -PfsGroup None -CipherTransformConstants AES128 -AuthenticationTransformConstants SHA196 -IntegrityCheckMethod SHA1
Verify:
(Get-VpnConnection -ConnectionName "Companyname").IPSecCustomPolicy
AuthenticationTransformConstants : SHA196
CipherTransformConstants : AES128
DHGroup : Group2
IntegrityCheckMethod : SHA1
PfsGroup : None
EncryptionMethod : DES3
I assumed the TransformConstants + PfsGroup are the phase 2 parameters and the rest are the phase 1 parameters except lifetime.
I then tried a few other sets and for the time being I found that phase 1 only works with 3DES, DH2 and SHA but phase 2 does support AES128 at least. Maybe other combinations are possible but at least I know these work 🙂
After changing this, the MX no longer complains because it does not receive these high DH groups it does not support!
I hope this helps at least someone or is at least educational for the rest 🙂
