IKEv2 VPN for Windows 10 and OSX - HOW-TO!

gbitglenn

This, hopefully, will serve as the one document that definitively defines how to get a secure IPSEC VPN on PFSense that works on both Windows 10 and OSX.

This document is the result of a lot of trial-and-error, and research. I have included the PowerShell stuff kapara contributed, so credit to him on that part.

The original document, seen as the official go-to for IKEv2 VPN is https://doc.pfsense.org/index.php/IKEv2_with_EAP-MSCHAPv2. This document is close, it's author did a good job at the time. However it is either out-of-date, unclear, and perhaps inaccurate in certain areas. The OSX instructions don't work at all for example.

This new document is based directly on that original document, with all the appropriate updates and changes. I'd love to just update the original if someone would give me access to to do. (I can do Wiki format).

Note: This document is for SPLIT VPN, meaning, the client will retain local access to the Internet and the only traffic that will pass through your VPN is traffic destined for servers on your LAN side. (IE: This is not a VPN meant for hiding your Netflix country :)).

This is copy/pasted from a Word doc so it's not going to format nicely here.

IKEv2 with EAP-MSCHAPv2

SECTION A: Set Up Certificates

Create a Certificate Authority

Navigate to System > Cert Manager on pfSense.
On the “CA” tab, click “Add” to create a new certificate authority.
“Descriptive Name”: This will be the name of the certificate you give to people. Name is accordingly, no spaces or punctuation. IE: “vpnca”.
Method: ‘Create an internal Certificate Authority’.
Key length: 2048
Digest Algorithm: sha256
Lifetime: 3650 days (whatever you want but unless you want to keep having to re-issue this, just make it 10 years).
Fill in the rest of the fields as desired with company or site-specific information. As this is a non-registered self-issued certificate, this doesn’t need to be accurate so long as you don’t care that people connecting could see wrong information if you do fudge it).
“Common Name”: Put same as you used for “Descriptive Name” above.
Click Save.

Create a Server Certificate
• Navigate to System > Cert Manager on pfSense.
• On the “Certificates” tab, click “Add” to create a new certificate.
• Method: “Create an internal certificate”.
• Enter a Descriptive Name such as IKEv2 VPN.
• For “Certificate Authority”, select the one you just created in Step 1.
• Choose the desired Key length, Digest algorithm, and Lifetime. The default of 2048, sha256 works fine. Lifetime, as in Step 1, leave at the 10 years (3650 days) unless you want to reissue certs to clients more frequently.
• “Certificate Type”: Server Certificate.
• The regional and company values are copied from the CA and may be left as-is.

Common and Alternative Names:
Some people put their VPN server address in DNS. Others don’t and just give out the IP address. Some do both. The below steps should cover all 3 scenarios.

• “Common Name”: The hostname of this PFSense firewall as it exists in DNS. If clients will connect by IP address, place the WAN IP address here.
• Click “Add” to add a new Alternative Name
• Select “FQDN or Hostname” in the Type drop-down.
• Enter the same value you just used in Common Name.
• Click “Add” to add a 2nd new Alternative Name
• Select “IP address” in the Type drop-down.
• Enter the WAN IP address of the firewall in the Value field
• Add more Alternative Names as needed for additional hostnames or IP addresses on the firewall that clients may use to connect.
• Click Save

SECTION B: Set up Mobile IPsec for IKEv2+EAP-MSCHAPv2

Mobile Clients
• Navigate to VPN > IPsec, Mobile Clients tab on pfSense
• “IKE Extensions”: Check “Enable IPsec Mobile Client Support”
• “User Authentication”: Local Database
• “Group Authentication”: None.
• “Virtual Address Pool”: Check “Provide a virtual IP address to clients”.

For “Network configuration for Virtual Address Pool”: Getting this wrong means your clients will not be able to see any inside network resources. (IE: Anything on the LAN side of the firewall). The network range you put here must be completely off the LAN network that’s on your firewall. This includes, for example, if you have taken an entire /16, EG 10.1.0.0/16 as your LAN. Putting a pool of 10.1.2.0/24 here will not work, since the /16 covers everything that starts with 10.1.* If that’s how your network is set up, then do something completely different here, such as 172.16.1.0/24.

• Enter an unused private Network and appropriate subnet mask (such as /24). For this example, let’s use 172.16.1.0/24. (Unless that’s on your LAN then use something else that isn’t).
• Check “Provide a list of accessible networks to clients".
• Rest of options are unchecked.
• Click Save, then Apply.

IPSEC Phase 1
• If the “Create Phase 1” button appeared at the top of the page after you clicked Apply in the previous step, click it. Otherwise, go to the Tunnels Tab and “Add P1”.
• “Key Exchange version”: to IKEv2.
• “Description”: ‘Mobile Phase 1’ (Or whatever you want, it doesn’t matter).
• “Authentication method” to “EAP-MSChapv2”
• “My Identifier”: ‘Distinguished name’, and enter in either the hostname or WAN IP address.
• NOTE: This MUST match what you used as the “Common Name” of the server certificate, in Step 1.
• “Peer Identifier”: any.
• “My Certificate”: Select the server certificate created in Step 1.
• “Encryption algorithm”: “AES” and “256”
• “Hash algorithm”: SHA256
• Set DH key group to 2 (1024 bit) (Windows 10 doesn’t natively support anything else!)
• Set Lifetime to 28800
• Uncheck Disable Rekey
• Uncheck Disable Reauth
• Check Enable DPD, set for 10 seconds and 5 retries
• Click “Save”, then “Apply”.
IPSec Phase 2
• Back on the Tunnels tab, you will see the entry for “Mobile Client” you just created. Under it, click “Show Phase 2 Entries”, then click “Add P2”.
• “Mode”: Tunnel IPv4
• Set Local Network as desired, usually “LAN subnet”. (Select this if not sure).
• If your intent is to pass all traffic, including Internet traffic, across the VPN, set “Local Network” to “Network”, and enter 0.0.0.0 for the address, and /0 for the subnet.
• “NAT/BINAT”: None.
• Description”: ‘Mobile Phase 2’.
• “Protocol”: ESP
• “Encryption Algorithms”:
• Just “AES, 256”.
• “Hash Algorithms”: SHA1 (Windows 10 needs this), SHA256, SHA384, SHA512.
• “PFS Key Group”: off
• “Lifetime”: 3600
• “Automatically ping host”: leave blank.
• Click Save, then Apply.
Create Client Pre-Shared Keys

Mobile user logins and passwords are defined as a Pre-Shared Key. This document covers using EAP, the default way. The draw-back with the default way is that the usernames and passwords are visible in plain-text to anyone who has access to your PFSense web admin. (Not anywhere else – just the web admin). In theory that should only be you, or certain sysadmins, and this isn’t a problem. However, if that doesn’t float your boat you can always set up and use a RADIUS server service. The setup is nearly identical. Follow the directions on this page and then see IKEv2 with EAP-RADIUS for the needed adjustments. Some changes for EAP-RADIUS to work effectively are only found in pfSense 2.2.5-RELEASE and later.

• Navigate to VPN > IPsec, Pre-Shared Keys tab on pfSense to add EAP users
• Click “Add” to add a new user
• “Identifier” is the username.
• “Secret type”: EAP
• “Pre-Shared Key”: This is the password. Note that PFSense, oddly, doesn’t like certain commonly-recommended characters such as certain punctuation in its passwords. So just use varying case and numbers if you have a problem.
• Click Save.
• Repeat as needed for additional users.
• When done, Click “Save”, then “Apply”.

Add Firewall Rules for IPsec
• Navigate to Firewall > Rules, IPsec tab
• Review the current rules. If there is an "allow all" style rule, then there is no need to add another. Continue to the next task.
• Click “Add” to add a new rule
• “Action”: Pass
• “Interface”: IPsec
• “Address Family”: IPv4
• “Protocol”: any
• “Source”: any
• “Destination”: any
• Click “Save”, then “Apply”.

SECTION C: Client Setups

Common for all: Export Certificate

• Navigate to System > Cert Manager, CA tab on pfSense.
• Click the seal icon (looks like a sun – mouse over it for a second to be sure it’s the one to download the CA NOT the key) icon under “Actions” to export the CA. It will download automatically.

Windows 10 Client Setup

Import the VPN server CA certificate.
• Copy the .crt file you downloaded to the PC.
• Double click the CA file.
• Click “Install Certificate…”.
• Select “Local Machine”, then “Next”.
• Click Yes at the “User Account Control” box if it appears.
• Select Place all Certificates in the following store, then “Browse”.
• Select “Trusted Root Certification Authorities” and click “OK”.
• Click Next.
• Click Finish.
• Click OK.
Add the VPN connection

To get around limitations in the Windows 10 GUI, you must create the VPN connection, and its routes, manually via a PowerShell command line.

• Open a PowerShell window, as administrator.
• (type ‘powershell’ in the task bar search box. When it finds it, right-click on it and select “Run as Administrator).
• Enter the below command (or edit it somewhere then just copy/paste it), with the following changes:
• Replace “VPN_NAME” with whatever you want to call this VPN connection on the client’s computer.
• Replace “firewall.domain.com” with the address of your VPN server. (LAN IP of your PFSense box, or DNS name of it).

Add-VpnConnection -Name "VPN_NAME" -ServerAddress "firewall.domain.com" –TunnelType IKEv2 -EncryptionLevel Required -AuthenticationMethod EAP -SplitTunneling –AllUserConnection

Keep PowerShell open for the next step.

Add VPN Routes

Copy/paste the following into PowerShell, replacing 10.5.0.0/16 with the appropriate remote LAN subnet:

Add-VpnConnectionRoute -ConnectionName "VPN_NAME" -DestinationPrefix 10.5.0.0/16 -PassThru

That will tell Windows to send anything meant for 10.5.* over the VPN.

Mac OS X Client Setup (10.10 or Greater)

Apple’s built-in support for the IKEv2 protocol either doesn’t exist (up to 10.12 Sierra), or doesn’t support common standards. You will need to download and install the StrongSwan VPN client for OSX to work with IKEv2 on PFSense.

StrongSwan is a long-running and trusted open-source VPN standard application. It’s very light-weight and easy to configure. Much easier than monkeying around with some convoluted Apple configurator tool.

Import the VPN server CA certificate.
• Copy the CA Certificate to the OS X system
• Double click the CA Certificate File in Finder, which opens Keychain Access. The certificate would have been added to the System keychain.
• In the list that appears, find the certificate.
• Right-click the Certificate and select Get Info.
• Expand Trust
• Set When using this certificate to Always Trust
• Close the window.
• Close Keychain Access.
Download and Install StrongSwan VPN Client.

• Download the current OSX client version here: https://download.strongswan.org/osx/ (Find the highest number.app.zip) EG: strongswan-5.3.2.1.app.zip.
• Once downloaded, double-click the zip file. It will emit a file called “strongSwan”. Drag and drop that to your Applications folder.

Set up VPN Connection in strongSwan

• Start the stongSwan app. (That you just put in your Applications folder).
• A swan icon will appear in your top toolbar.
• Click the swan icon, and select “Add connection..”
• “Connection name:” Name of your connection. EG: “Office”
• “Authentication:” Leave at default “IKEv2 EAP”
• “Server address:” DNS hostname or IP address of your VPN server. (WAN address of PFSense box).
• “Username:” Username of who this client is being set up for, as defined in Section B-4 ‘Pre-Shared Keys’.
• Click OK.

To Connect:

• If the Swan icon isn’t on the top tool bar, open strongSwan from Applications.
• Click the swan icon, and click the VPN you just set up.
• The first time you try and connect, strongSwan needs to do some configuration on the computer. It will ask to authenticate to the computer. Note: This is to the computer and not yet to the VPN. Supply the appropriate credentials.
• Reboot, and try connecting.

kroko

nice writeup, thanks! cannot confirm though.

i am currently fighting (2.4.0-BETA) DNS resolving issues on macOS (testing on 10.12.4 Beta) for outbound and meanwhile it came up i will also have to support MSW (IKEv2 was meant only for macOS/iOS in my plans), which complicates things. it was thought i'll use OpenVPN for everything else. oh well.

the route i will try to go is certificate based auth though.
currently it works really nice with Apple Configurator to push profiles around machines w/o pre-shared keys (except for that WAN DNS issue).

if DH group 14 was used (modp 2048) as suggested here (but untested?) it should work on macOS/iOS/MSW simultaneously. last time i opened MSW registry was [starts singing] long long time ago.

hopefully will test cert based stuff this week. just saying as it very well might be another way to "definitely get a secure IPSEC VPN on PFSense that works on both Windows 10 and OSX."
you could look into that too as this would solve your "The draw-back with the default way is that the usernames and passwords are visible in plain-text".
plus there will be no need for StrongSwan on OSX, all OSes will use built in capabilities.
my main reason for built in stuff is because of the iOS usage (although i could use OpenVPN here) - telephone tethers 3/4G on its WiFi interface to be used with a laptop to enable working in LAN/DMZ on remote locations where WiFi is not available to a laptop directly.

gbitglenn

@kroko:

i am currently fighting the DNS resolving issues on macOS (testing on 10.12.4 Beta) for outbound and meanwhile it came up i will also have to support MSW (IKEv2 was meant only for macOS/iOS in my plans), which complicates things. it was thought i'll use OpenVPN for everything else. oh well.

Luckily my client OSX machines only need to connect using IP addresses, so I haven't actually noticed if I can pass DNS through with the config I laid out above. You should be able to, guess it needs to be tested.

if DH group 14 was used (modp 2048) as suggested here (but untested?) it should work on macOS/iOS/MSW simultaneously. last time i opened MSW registry was [starts singing] long long time ago.

I can tell you from my testing that natively Windows 10 only works with DH Group 2. (1024). Note I said natively. I think there was some rumblings on some other posting about screwing with the registry to get other DH groups working. For the sake of simplicity, I didn't bother and just used Group 2 since that works on both Windows and OSX.

hopefully will test cert based stuff this week. just saying as it very well might be another way to "definitely get a secure IPSEC VPN on PFSense that works on both Windows 10 and OSX." you could look into that too as this would solve your "The draw-back with the default way is that the usernames and passwords are visible in plain-text", there will be no need for StrongSwan on OSX, all OSes will use built in capabilities ;)

Sounds like we both have the same goal - to come up with a good solution so the next person doesn't have to pull their hair out for hours/days getting this working when there's no other documentation that lays it all out in once place. If you want to contribute anything or test, by all means.

My end-goal was to have ONE document people can refer to, in ONE area. Rather than have to do what I did and have to compile several "try this" postings, plus my own research, to get it working.

If you want to expand it by adding a section for people who want to use Radius or individual certs go nuts. For the sake of keeping it all in one place though, maybe let me maintain it for now - just reply on this thread the tested changes and I'll update the original post?

jimp

This is almost entirely the same as the existing doc except for the client setup. The original doc was written to be used against either Windows 10 or OS X, depending on the settings. There are ways to use both, but as you've found it isn't so straightforward.

The native IKEv2 client on OS X works fine when you configure it properly using our export tool (if you're on the factory version), or by crafting a profile using Apple Configurator 2. Then it can use the same settings recommended for Windows 10 and they'll both work OK without third-party software.

Sure, you can install strongSwan and use that but I wouldn't pick that over the native client in most cases.

For the Windows 10 setup, I do need to put up the parts for using powershell since using split routing is a common request, though using the GUI to setup the VPN still works fine.

kroko

Just tested:

pfSense 2.4.0-BETA
macOS 10.12
iOS 10.2.1
MSW 10

All work (LAN traffic, DNS resolving, outbound traffic etc.) with certificate based IKEv2 auth just using built in OS func OOB. Currently could not be happier.

–-----------------------------------------------------------------------

Using DH14 as apple now supports it and MSW can be easily made to support it.

For macOS/iOS it is super easy - just use profile(s), mail them to (users), 3 clicks and user is ready.
Enable perfect forward secrecy must be urned on in Apple Configurator, so that DH group for Phase 2 is proposed.

Adding MSW support was easier than I thought. I am not power user on this os. Followed this guide, but only the part that describes how to install certs on MSW and configure interface.
For this part I created registry entry and exported as double-click-to install file that just has to be shipped to clients along with certs.

At first, after enabling reg key, it did not work on MSW, but logs said it all

Mar 21 15:34:42     charon          05[CFG] <con1|8> configured proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
Mar 21 15:34:42     charon          05[CFG] <con1|8> received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ</con1|8></con1|8>

Thus phase 2 has to include also 3DES and SHA1 (which means: AES-256, 3DES for enc; SHA1, SHA256 for hash). DH group 14 for both phase 1 and Phase 2.

Basically takes ~3min to set it up on MSW (or faster if i was poweruser and could script cert installation, vpn adapter setup).

Profit. All mentioned OSes connect w/ cert based auth & DH14

Now I have to test how stable IKEv2 conn is on all OSes :)

–-----------------------------------------------------------------------

Using DH20

Note that per Cisco docs 3 years ago DH14 is really lowest DH group one should use, so i'll check wether DH20 (that macOS/iOS support OOB) can be brought to MSW w/o external client. This doc and this doc says ecdhp384 is supported since MSW7 which imho refers to 384 bit elliptic curve which itself is DH20.

EDIT: DH20 can be made to work on windows OOB, see ECP384. The docs are clear so…

switched pFsense back to DH20 @ phase 1&2
Rolled back phase 2 - removed 3DES and SHA1 (back to AES256; SHA256 only).

For macOS/iOS just rolled back to DH20 in Phase 1 & 2, reexported and reinstalled the profiles.
Enable perfect forward secrecy must be urned on in Apple Configurator, so that DH group for Phase 2 is proposed.

For MSW deleted DH14 registry entry (you have to for this to work).
Fired up PS and

Set-VpnConnectionIPsecConfiguration -ConnectionName "myvpnname" -AuthenticationTransformConstants SHA256 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA384 -DHGroup ECP384 -PfsGroup ECP384 -PassThru -Force

Profit. All mentioned OSes connect w/ cert based auth & DH20

–-----------------------------------------------------------------------

I'll probably stick with DH20 now, as for macOS it does not matter, and both DH14 and DH20 need some "custom script execution" on MSW, so why not choosing the latter.

I'm awaiting quantum resistant stuff though.

gbitglenn

@jimp:

This is almost entirely the same as the existing doc except for the client setup. The original doc was written to be used against either Windows 10 or OS X, depending on the settings. There are ways to use both, but as you've found it isn't so straightforward.

The native IKEv2 client on OS X works fine when you configure it properly using our export tool (if you're on the factory version), or by crafting a profile using Apple Configurator 2. Then it can use the same settings recommended for Windows 10 and they'll both work OK without third-party software.

Sure, you can install strongSwan and use that but I wouldn't pick that over the native client in most cases.

For the Windows 10 setup, I do need to put up the parts for using powershell since using split routing is a common request, though using the GUI to setup the VPN still works fine.

Hi there,

The original is well done just needs some updates and clarification. I was offering to do that but it looks like you're the actual maintainer of the doc anyway.

The changes on the doc are in a few places - I'd have to do a side-by-side comparison, but there were a few key things. (And of course that whole PowerShell nonsense if you need split routing). (Nonsense on MS's part not your or PFSense's part). Agreed the VPN setup using the GUI will also work fine, I just figured since the user has to issue PowerShell commands anyway it's quicker and less prone to missed steps to issue the initial VPN setup as well.

Re: use of 3rd-party client software ie: StongSwan. Personally I looked at using that vs. a to-be-installed tool kinda one in the same problem - only that StrongSwan is just quicker and easier to set up. Up to the user which one is best for their particular situation I guess. If you have a dozen client computers to maintain, perhaps the tool would be best. Maybe both options should be noted.

At the end of the day hey, you're the one who works here and it's your doc to maintain. I'm just trying to save people the headaches I had to go through that's all. I'm happy to pitch in where needed. (In particular on the OSX side).

Take care,
-G

gbitglenn

@kroko:

Just tested:

pfSense 2.4.0-BETA
macOS 10.12
iOS 10.2.1
MSW 10

Hi,

My thoughts are whatever is easier for the user, and will work for both Win10 and OSX. I'm not the judge of what the correct method is since it's partly up to opinion (profile tools vs. client, DH 2 vs DH14, etc). My logic on the matter is whatever is less effort for the client while still being secure and functional. Registry changes are not easy for the client. Nor is installing and messing with Apple's Profile Tool (Unless you are maintaining a lot of machines). But again, that's just MY opinion.

Seems Jimp is the actual doc maintainer - his call I guess. Glad to see we're all working together for a good final experience though!

kroko

Well, you can go the secure way and you can go insecure way. I would not agree upon "it's partly up to opinion (…) DH 2 vs DH14". There is lot of educated opinion out there that DH2 is insecure and i provided links to what cisco has to say about DH2. But I see your point - you just want to VPN going and really don't care about security for that speciffic case. Been there, done that - if one does not care then for the sake of simplicity just use PPTP VPN with shared CHAP, it is really easy to setup on both ends, used it for years for VPNing in my home network. Offt: Actually I have seen people pulling hair out on configuring VPN when simple SSH tunnel would provide everything needed.

If security is concern then the orignal doc should also note this, why certs should be used.

gbitglenn

I wouldn't exactly compare DH2 to PPTP and CHAP (unencrypted). Yes 1024 is not ideal for everyone, however I'm not so sure it's completely insecure.

If it's that big of a deal then Jimp can decide wether DH2 is acceptable for documentation, or guiding the user through editing their registry.

For me, considering there's still encryption, and a certificate required in the client side to boot, it's fine. However this is a small operation and not a bank. The user should decide what's right for them.

I guess the long and short of it is, the original doc maintainer is now involved. We've made our suggestions, and PFSense staff can implement as they see fit. You're not wrong about the DH14 btw.

kroko

Don't get me wrong - imho your input is great. My two cents is just
a) If the docs are updated, it should be noted that by year 2017 standards it is insecure*.

which comes to offtopic for my case - i'm building something that i don't have to return to in near future and i need security, my use case is medium office infrastructure, other cases might really be security indifferent (secured traffic over unsecured tunnel is secure).
b) If one seeks for supersimple VPN capability ("i want to login in my home media bin and don't know how to use console & SSH, only those auto SMB share icons that show up in my MSW explorer left panel; security? - i don't care, i do not watch balck mirror :)" stuff) then there are evern simplier methods to get cross-OS VPN working, which was part of agenda of this post - having "something that works on both Windows 10 and OSX" and does not involve cert installation and what not.

EDIT: beware, that my comments on my setup above with setting PF group for phase 2 will not work for rekeying if Enable Perfect Forward Secrecy is off when creating profile in Apple Configurator. Either this or set pfSense not to use DH group for phase 2 (as Enable Perfect Forward Secrecy macOS/iOS will never send DH proposals).

lyubomyr83

@kroko:

Just tested:

pfSense 2.4.0-BETA
macOS 10.12
iOS 10.2.1
MSW 10

All work (LAN traffic, DNS resolving, outbound traffic etc.) with certificate based IKEv2 auth just using built in OS func OOB. Currently could not be happier.

–-----------------------------------------------------------------------

Using DH14 as apple now supports it and MSW can be easily made to support it.

For macOS/iOS it is super easy - just use profile(s), mail them to (users), 3 clicks and user is ready.
Enable perfect forward secrecy must be urned on in Apple Configurator, so that DH group for Phase 2 is proposed.

Adding MSW support was easier than I thought. I am not power user on this os. Followed this guide, but only the part that describes how to install certs on MSW and configure interface.
For this part I created registry entry and exported as double-click-to install file that just has to be shipped to clients along with certs.

At first, after enabling reg key, it did not work on MSW, but logs said it all
Mar 21 15:34:42     charon          05[CFG] <con1|8> configured proposals: ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
Mar 21 15:34:42     charon          05[CFG] <con1|8> received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ</con1|8></con1|8>
Thus phase 2 has to include also 3DES and SHA1 (which means: AES-256, 3DES for enc; SHA1, SHA256 for hash). DH group 14 for both phase 1 and Phase 2.

Basically takes ~3min to set it up on MSW (or faster if i was poweruser and could script cert installation, vpn adapter setup).

Profit. All mentioned OSes connect w/ cert based auth & DH14

Now I have to test how stable IKEv2 conn is on all OSes :)

–-----------------------------------------------------------------------

Using DH20

Note that per Cisco docs 3 years ago DH14 is really lowest DH group one should use, so i'll check wether DH20 (that macOS/iOS support OOB) can be brought to MSW w/o external client. This doc and this doc says ecdhp384 is supported since MSW7 which imho refers to 384 bit elliptic curve which itself is DH20.

EDIT: DH20 can be made to work on windows OOB, see ECP384. The docs are clear so…

switched pFsense back to DH20 @ phase 1&2
Rolled back phase 2 - removed 3DES and SHA1 (back to AES256; SHA256 only).

For macOS/iOS just rolled back to DH20 in Phase 1 & 2, reexported and reinstalled the profiles.
Enable perfect forward secrecy must be urned on in Apple Configurator, so that DH group for Phase 2 is proposed.

For MSW deleted DH14 registry entry (you have to for this to work).
Fired up PS and
Set-VpnConnectionIPsecConfiguration -ConnectionName "myvpnname" -AuthenticationTransformConstants SHA256 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA384 -DHGroup ECP384 -PfsGroup ECP384 -PassThru -Force
Profit. All mentioned OSes connect w/ cert based auth & DH20

–-----------------------------------------------------------------------

I'll probably stick with DH20 now, as for macOS it does not matter, and both DH14 and DH20 need some "custom script execution" on MSW, so why not choosing the latter.

I'm awaiting quantum resistant stuff though.

Sorry. Who can help set ikev2 from iOS 10? You wrote you can set, but i cant. From Win10 i can connect, but not from iphone.

io-automation

Hello,

I Would like to follow this guide but in the configuration of the Phase1 I'm unable to select the EAP-MSCHAPv2 option as authentication option.

Our system version is 2.3.2_1

Thank you for your support.
Bart

raidensix

The guide worked for me using FreeRadius user authentication. For W10 clients, had to add another route command for the remote LAN subnet so the W10 clients could see clients in the remote network.

thanks!

franken

@gbitglenn:

IKEv2 with EAP-MSCHAPv2
….

SECTION B: Set up Mobile IPsec for IKEv2+EAP-MSCHAPv2

Mobile Clients
…

IPSEC Phase 1
• If the “Create Phase 1” button appeared at the top of the page after you clicked Apply in the previous step, click it. Otherwise, go to the Tunnels Tab and “Add P1”.
• “Key Exchange version”: to IKEv2.
• “Description”: ‘Mobile Phase 1’ (Or whatever you want, it doesn’t matter).
• “Authentication method” to “EAP-MSChapv2”
• “My Identifier”: ‘Distinguished name’, and enter in either the hostname or WAN IP address.
• NOTE: This MUST match what you used as the “Common Name” of the server certificate, in Step 1.
…...

Am I missing anything, or why doesn't I get the option?

PhYrE

@io-automation:

I'm unable to select the EAP-MSCHAPv2 option as authentication option.

@franken:

“Authentication method” to “EAP-MSChapv2”
Am I missing anything, or why doesn't I get the option?

It's a stupid feature (a bug in my opinion), but you need to create the tunnel from the Mobile Clients page instead of from the Tunnels page. At the very least there is a lack of documentation (ie: something at that stage that lets you know you're in the wrong place).

If you go to create a Tunnel from the Tunnels menu, it won't give you the option

https://router:443/vpn_ipsec_phase1.php

If you go to create a Tunnel from the Mobile Clients menu

https://router:443/vpn_ipsec_phase1.php?mobile=true

overpf

Thanks for the writeup. I'm using windows 7 instead of win10, I got the VPN connected, however I could not access anything on the LAN. I notice compared to my other VPN, this connection did not set the DNS server.

josey

thanks this worked for me under win 7

question is
if i turn off default gw in VPN connection (under win 7 network vpn connection), and internet passes directly, i cant connecto to servers behind vpn.
If i turn on default gw under VPN connection, internet goes through VPN and i can access servers behind VPN.

I guess i have to add default route for servers subnet? but what is my gw then, because there is no IPV4 address of IKEv2 under connection details.

i hope you will understand what im asking, because i think i didnt explain this very well.

thanks

edit:
i add route
route add "server netvork" mask 255.255.255.0 "ip address of ike vpn" -p
and it is working.
but, if i have two or more useres connected and if ip address change, than route will not work.
I need ipv4 address of ikev2 server to add correct route. and it seems there is no one :(

helviojr

@josey:

I guess i have to add default route for servers subnet? but what is my gw then, because there is no IPV4 address of IKEv2 under connection details.

I didn't test IKEv2 yet (still on L2TP with IKEv1), but it seem you can create route using device, instead of gateway IP:

use ipconfig to get the name of each device (you probably can get those form GUI also);
use route print to get the number of each interface, and get the one of your VPN device (the table at the begining of "route print" command output);
create the route using "IF" option instead of the gateway address:

route ADD 10.10.10.0 MASK 255.255.255.0 IF 10 -p
(this would create a route to subnet 10.10.10.0/24 through interface number 10)

peter911

Hello guys!

I can connect to the IKEv2 IPSec VPN and ping both WAN and LAN NIC from my pfsense but I cannot ping other hosts in the remote LAN

Thanks!

ipsec_int.PNG_thumb

ipsec_stat.PNG_thumb

rule_1.PNG_thumb

rule_2.PNG_thumb

tabs

@gbitglenn:

@jimp:

This is almost entirely the same as the existing doc except for the client setup. The original doc was written to be used against either Windows 10 or OS X, depending on the settings. There are ways to use both, but as you've found it isn't so straightforward.

The native IKEv2 client on OS X works fine when you configure it properly using our export tool (if you're on the factory version), or by crafting a profile using Apple Configurator 2. Then it can use the same settings recommended for Windows 10 and they'll both work OK without third-party software.

Sure, you can install strongSwan and use that but I wouldn't pick that over the native client in most cases.

For the Windows 10 setup, I do need to put up the parts for using powershell since using split routing is a common request, though using the GUI to setup the VPN still works fine.

Hi there,

The original is well done just needs some updates and clarification. I was offering to do that but it looks like you're the actual maintainer of the doc anyway.

The changes on the doc are in a few places - I'd have to do a side-by-side comparison, but there were a few key things. (And of course that whole PowerShell nonsense if you need split routing). (Nonsense on MS's part not your or PFSense's part). Agreed the VPN setup using the GUI will also work fine, I just figured since the user has to issue PowerShell commands anyway it's quicker and less prone to missed steps to issue the initial VPN setup as well.

Re: use of 3rd-party client software ie: StongSwan. Personally I looked at using that vs. a to-be-installed tool kinda one in the same problem - only that StrongSwan is just quicker and easier to set up. Up to the user which one is best for their particular situation I guess. If you have a dozen client computers to maintain, perhaps the tool would be best. Maybe both options should be noted.

At the end of the day hey, you're the one who works here and it's your doc to maintain. I'm just trying to save people the headaches I had to go through that's all. I'm happy to pitch in where needed. (In particular on the OSX side).

Take care,
-G

Thank you very much. I have set up a few VPNs, and recently set up 2 at different sites., both in the latest version.

Strangely I only had to run the powershell command to connect to one of the sites. thank you very much for the information, and thanks also to the creators of the original doc.