Trouble setting up Client IPsec VPN
-
I'm trying to set up an IPsec client VPN for the first time and am not successful. I've had no trouble with OpenVPN before, but the customer has given me the following requirements:
- Must use the built-in Windows 10 and Windows 11 clients
- Nothing additional (e.g. certificate) may be installed on the client computer
To start with, am I correct that this is possible? It seems that if we're willing to live with login name and password as adequate security (I'm not comfortable with that, but the customer insists on it), setting up an IPsec VPN should work.
I should mention that the firewall is on an Active Directory network using Radius for authentication. I don't think that's the issue based on the logs, authentication tests, and the fact that OpenVPN is working properly.
I'm running version 22.05 on a Netgate 4100.
I've attached the log file that I hope will give some clue as to where it is failing.
I had issues with compatible phase 1 proposals, but was able to remedy that (or so it appears). It's not clear to me if it is phase 1 or phase 2 that is the issue. Any input would be appreciated.
I should be able to provide any other information if requested.
Thank you in advance for any assistance!
20220902Log.txt -
@compprobsolv Well, that setup is certianly achievable and works well (I know because I use it a lot).
There is a couple of gotha’s in setting it up:
1: The Cetificate used for the IPSEC mobile VPN MUST be trusted by the client, so in your case it must be a publicly signed cert. Since you are not allowed to install a private CA cert on your clients. The Certificate CANNOT be a wildcard cert - you can set it up, but it will not work - at least not for iOS/MacOS devices. The certificate needs to be issued with the FQDN Common name and SAN name contaning the public DNS name used to reach the VPN endpoint.
2: Windows has a limited set of encryption and signing options enabled by default. I can’t remember those as I create the VPN tunnel with a powershell - and at the same time enabled the heavier and more advanced ciphers and signing options needed.
But I seem to remember it being AES128 and SHA2 with DH2 as your best options (Not the best options these days - but still fairly safe - unless VERY heayv supercomputer time is available to decrypt). -
@compprobsolv Forgot to mention: Use IKEv2 and disable Mobike - you can go straight through without all the negotiations of Mobike and the possible selection of subpar encryption ciphers.
-
@keyser said in Trouble setting up Client IPsec VPN:
in your case it must be a publicly signed cert
Thank you for the quick response.
The cert I set up was from the local pfSense CA. If I'm understanding you, I need to obtain a cert from a public CA if I can't install the cert locally. Do I have that correct?
I doublechecked the FQDN and SAN names and they are the same and are the public name. It sounds as if that isn't relevant as I need a public cert.
Is there anything in the log that implies that the cert is the issue? I recognize from your comments that it will be an issue regardless of other problems.
limited set of encryption and signing options
Initially I wasn't getting past the configured/received proposals. I added IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_1024 to the firewall and that worked with the Windows 10 client.Use IKEv2
Under VPN/IPsec/Mobile Clients/Edit Phase 1 IKE Endpoint Configuration, Key Exchange version I have IKEv2 set. I do notice in the log that it refers to IKEv1. Do you have any idea why that is?disable Mobike
I believe I also tried with it enabled, but I just checked and it was disabled when I did the latest test for which I posted the logThank you again. I'll look into the public cert and see if that gets me any further.
-
@compprobsolv Your log is not detailed enough to see why the client decided not to persue the connection, but since ciphers where negotiated, I’m pretty sure it’s the certificate.
You can test this easily since your selfsigned cert contains the right FQDN and SAN name. Install the pfSense Certificate autority (CA Cert) on your test machine in the “Local computer -> Trusted root authorities” store. This is not the cert used for IPSec, but rather the cert of the authority that signed the cert for IPSEC (Can be found on your pfSense and exported)
If your client then starts working, you know the cert was your current issue, and you can get a proper official one for use with the remaining clients.Regardless - even is the cert is not yet the issue (if it’s still a cipher issue on the client), you will still meet the cerificate problem later on, and that needs to be solved before it will start working.
-
@keyser
Thank you for the insight!I exported the cert, installed it as you suggested, and the connection works. I've got other details to sort out, but you got me past the main one.
-
Win 10 can use AES GCM 128, SHA 256 and DH19/ECP256, no need for crepey DH Settings.
2 Lines Powershell:
Add-VPNConnection -AllUserConnection -Name "RW-VPN" -ServerAddress "Dyndns" -TunnelType "Ikev2" -AuthenticationMethod Eap -RememberCredential Set-VpnConnectionIPsecConfiguration -ConnectionName "RW-VPN" -AuthenticationTransformConstants GCMAES128 -CipherTransformConstants GCMAES128 -EncryptionMethod GCMAES128 -IntegrityCheckMethod SHA256 -DHGroup ECP256 -PfsGroup ECP256 -PassThru
But you need the private FW Root CA or a public trust CA on the pfSense.
-
@nocling said in Trouble setting up Client IPsec VPN:
Win 10 can use AES GCM 128, SHA 256 and DH19/ECP256, no need for crepey DH Settings.
2 Lines Powershell:
Add-VPNConnection -AllUserConnection -Name "RW-VPN" -ServerAddress "Dyndns" -TunnelType "Ikev2" -AuthenticationMethod Eap -RememberCredential Set-VpnConnectionIPsecConfiguration -ConnectionName "RW-VPN" -AuthenticationTransformConstants GCMAES128 -CipherTransformConstants GCMAES128 -EncryptionMethod GCMAES128 -IntegrityCheckMethod SHA256 -DHGroup ECP256 -PfsGroup ECP256 -PassThru
But you need the private FW Root CA or a public trust CA on the pfSense.
Yes, I know, that’s why I use powershell to create the VPN on the clients. But the OP has no options to touch/install/script anything on the clients, so I guess he has to make do with a user GUI “next - next -next” guide, and then you have to settle with what windows tries to autonegotiate.