PfSense 2.3.2 fails with macOS 10.11.6 native Cisco-style VPN client (IKE v1)
-
A little searching reveals that that there are a number of problems with the Mac IPSEC client, and is not just an issue with pfSense:
https://www.google.com/search?q=site%3Adiscussions.apple.com+10.11+broke+ipsec
This thread in particular might be of interest to you:
https://discussions.apple.com/thread/7502488
I don't believe that it would be appropriate for pfSense (or strongSwan) to attempt an implementation to work around this.
If you are interested in moving forward, I would recommend using IKEv2.
I had read this thread which you posted a link to (which is according to you "may be of particular interest" to me), and that is exactly the thread I had referred to when I had said that other vendors' IPSec headends were able to handle the new behavior of the native macOS Cisco IP VPN client starting with macOS 10.11.4.
If you read that thread more attentively, you will see that all that the folks had to do was to enable DH Group 14 on a variety of IPSec VPN headends by various vendors. Once DH Group 14 was enabled on the headends, the issue that the folks experienced with IPSec VPN connectivity in macOS 10.11.4 was resolved.
In the case of my extensive testing with pfSense, enabling DH Group 14 does not resolve this issue, as it is described at length in my posts above (probably with more verbosity than anyone would care to read). I was hoping that I was posting the detailed reports of my tests for the pfSense developers to try and replicate my issue; hence the amount of detail in may posts.
-
The logs I posted above say it works just fine. There is something peculiar about your environment it looks like.
-
Derelict,
Thanks for trying to connect via IPSec from macOS. Could you please verify the version of pfSense you are running and the version of macOS from which you were able to connect via the built-in Cisco IPSec Client?
Perhaps we are about to narrow down which product and which version is causing the issue.
Thank you!
10.11.6
2.3.2 CE amd64
Just the standard Cisco IPsec in the System Preferences.
-
There are many threads regarding defects introduced by the Mac specific version of Raccoon. Very similar if not the same as your issue. "Used to work fine, broke when I updated MacOS…" Sometimes you can make config changes on the server end to work around the defect, and sometimes you can't. In this case, it seems that you can't. Asking pfSense or strongSwan to implement further work-arounds for those defects isn't going to be productive, they are going to tell you to raise the issue with Apple. If there was no other way to get IPSEC connectivity to the platform it might be a different answer, but that's not the case here.
Taking a step back, what is the primary goal? Is it to get a vendor to fix the IKEv1 problem? Or is it to get to a solution that works? If the goal is to get a vendor to fix the IKEv1 issue, then the focus should be with Apple because that is where the defect was introduced. But you have to accept that this will likely take months. And when all is said and done, Apple may simply choose to not fix the defect. Like most everyone else, they are focusing their efforts on IKEv2. On the other hand, if the primary goal is to get something that works, then IKEv2 accomplishes that easily enough.
-
Thank you. This is definitely a setback in my troubleshooting because I am running exactly the same versions of Mac OS and pfSense. What is CE by the way?
However, this is not unique to my environment because another user was able to replicate the same exact issue and behavior in the logs, which he reported in this thread.
Another variable I can think of is that I installed MacOS 10.11.6 anew instead of upgrading to it from a previous version. I got a new Mac, and I made a fresh install of 10.11.6 before restoring the files, applications, and settings from a Time Machine backup.
Is your macOS 10.11.6 an upgrade from
A previous version or a fresh install?–----
At this point, there are two theories here:
1. MacOS IPSec VPN client is broken - raise a bug with Apple.
2. MacOS IPSec VPN client is just fine - something is different in my (and the other user having this problem) environment.Thank you!
-
There are many threads regarding defects introduced by the Mac specific version of Raccoon. Very similar if not the same as your issue. "Used to work fine, broke when I updated MacOS…" Sometimes you can make config changes on the server end to work around the defect, and sometimes you can't. In this case, it seems that you can't. Asking pfSense or strongSwan to implement further work-arounds for those defects isn't going to be productive, they are going to tell you to raise the issue with Apple. If there was no other way to get IPSEC connectivity to the platform it might be a different answer, but that's not the case here.
Taking a step back, what is the primary goal? Is it to get a vendor to fix the IKEv1 problem? Or is it to get to a solution that works? If the goal is to get a vendor to fix the IKEv1 issue, then the focus should be with Apple because that is where the defect was introduced. But you have to accept that this will likely take months. And when all is said and done, Apple may simply choose to not fix the defect. Like most everyone else, they are focusing their efforts on IKEv2. On the other hand, if the primary goal is to get something that works, then IKEv2 accomplishes that easily enough.
Does IKEv2 (as it's implemented in pfSense and in MacOS) support PSK authentication?
-
Does IKEv2 (as it's implemented in pfSense and in MacOS) support PSK authentication?
I can't say first hand if PSK still works in MacOS or not. I would expect so, but I moved to certificate based authentication a couple of years ago and no longer have a PSK config to test with. Of course, I would have expected what you are currently doing to work in MacOS as well… :)
-
I have had this Mac user profile going since 2010 or so. Just upgraded along the way. That macbook pro broke so I think this is a fresh install with a time machine restore but that was a while ago. Probably was Yosemite at the time then upgraded. Don't think about it much.
CE is community edition. The version you download from www.pfsense.org. As contrasted with factory edition which is tweaked for netgate/pfsense hardware. As far as IPsec/strongswan are concerned they are identical.
-
I downloaded Apple Configurator 2 and tried to configure VPN profiles there.
1. IPSec (IKE v1 Cisco VPN Client). There are no settings available there for crypto parameters of IKE 1. Nonetheless, I tried to configure a profile in the Apple Configurator 2 for IKE v1, but when I installed the profile in macOS 10.11.6, I had the same issue described earlier in this thread; namely, the proposal that macOS is sending to pfSense never contains the DH Group number configured in pfSense Phase 1.
2. IKE v2. IKE v2 profile in Apple Configurator 2 allows one to configure crypto parameters, which I did. Because I don't want to deal with PKI certificates - not just yet, I tried to configure an IKE v2 profile with "Shared Secret" (instead of "Certificate") for Machine Authentication. When I installed this profile in macOS 10.11.6 and tried to connect with IKE v2, the IPSec log in pfSense reported that the Machine Authentication (in IKE v2 Phase 1) with PSK was successful, but it was rejected by pfSense due to a "constraint" to authenticate with a public key. See the IPSec log output below:
Aug 31 22:02:46 charon 13[NET] <bypasslan|14>sending packet: from 192.168.160.1[4500] to 192.168.160.100[4500] (80 bytes) Aug 31 22:02:46 charon 13[ENC] <bypasslan|14>generating IKE_AUTH response 1 [ N(AUTH_FAILED) ] Aug 31 22:02:46 charon 13[IKE] <bypasslan|14>peer supports MOBIKE Aug 31 22:02:46 charon 13[IKE] <bypasslan|14>received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding Aug 31 22:02:46 charon 13[CFG] <bypasslan|14>no alternative config found Aug 31 22:02:46 charon 13[CFG] <bypasslan|14>selected peer config 'bypasslan' inacceptable: constraint checking failed Aug 31 22:02:46 charon 13[CFG] <bypasslan|14>constraint requires public key authentication, but pre-shared key was used Aug 31 22:02:46 charon 13[CFG] <con1|14>switching to peer config 'bypasslan' Aug 31 22:02:46 charon 13[CFG] <con1|14>selected peer config 'con1' inacceptable: insufficient authentication rounds Aug 31 22:02:46 charon 13[IKE] <con1|14>authentication of 'client@acme.com' with pre-shared key successful Aug 31 22:02:46 charon 13[CFG] <con1|14>selected peer config 'con1' Aug 31 22:02:46 charon 13[CFG] <14> looking for peer configs matching 192.168.160.1[192.168.160.1]...192.168.160.100[client@acme.com] Aug 31 22:02:46 charon 13[ENC] <14> parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) N(MOBIKE_SUP) IDr AUTH CPRQ(ADDR DHCP DNS MASK ADDR6 DHCP6 DNS6) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ] Aug 31 22:02:46 charon 13[NET] <14> received packet: from 192.168.160.100[4500] to 192.168.160.1[4500] (384 bytes) Aug 31 22:02:46 charon 13[NET] <14> sending packet: from 192.168.160.1[500] to 192.168.160.100[500] (448 bytes) Aug 31 22:02:46 charon 13[ENC] <14> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(MULT_AUTH) ] Aug 31 22:02:46 charon 13[IKE] <14> 192.168.160.100 is initiating an IKE_SA Aug 31 22:02:46 charon 13[ENC] <14> parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ] Aug 31 22:02:46 charon 13[NET] <14> received packet: from 192.168.160.100[500] to 192.168.160.1[500] (432 bytes)</con1|14></con1|14></con1|14></con1|14></bypasslan|14></bypasslan|14></bypasslan|14></bypasslan|14></bypasslan|14></bypasslan|14></bypasslan|14>
This brings me back to the question I asked two posts earlier, Does pfSense support PSK authentication in IKE v2? I guess the answer is, it does not, even though Apple supports this method of Machine Authentication in macOS 10.11.6 via a profile created in Apple Configurator 2.
I realize that going with PKI certs is more secure than with PSK; however, for small environments, the headache of managing PKI may not be worth the time. Would it be possible for pfSense to consider supporting "pre-shared key" Machine Authentication method in IKE v2?
-
I finally was able to transition pfSense from my lab to production, and once it was connected to the real Internet with its WAN port, I tried to connect to pfSense via the IPSec VPN (IKE v1) from an iPhone. I had no issues whatsoever connecting with an iPhone, using AES (256 bit), SHA256, and DH Group 14. So, it appears that something in my macOS installation is causing this issue rather than this being a problem with pfSense. I won't be able to tell for sure until I try another Mac and connect successfully with a Mac.
If this is an issue with my macOS installation (which is weird because it's a 3-week-old fresh install), I apologize for blaming pfSense for this. It helped when another person posted here saying that with the same settings that I used, this person had no issues connected to pfSense' IPSec (IKE v1) server.
Does anyone know how to default the entire network stack in OS X so that if something is in fact wrong with it in this Mac, I could default it and clear this erroneous behavior?
Thank you.
I guess I can try to re-install macOS on it as well.
-
I also ran into this issue as my macOS 10.12.x machines worked fine and an older pair of machines running 10.11.6 could not connect to the VPN.
I tried IKEv2, but could not get that to work so I started to fiddle with some additional settings and found that in 'IPsec->Advanced Settings' I had enabled 'IP Compression' and 'Enable Cisco Extensions' (Unity plugin). After disabling both and restarting the IPsec service in pfSense my 10.11.6 machines are able to make the IPsec connection.
So maybe the cause of the mentioned Phase 1 chatter and failing exchange is in the 'Unity plugin' as it is related to Cisco extensions and the macOS Client for IPsec is specifically labeled 'Ciso IPsec'.
My configuration settings :
Mobile Clients
Enable IPSsec Mobile Client Support
IKE Extensions -> Enable
Extended Authentication
User Authentication -> Local Database
Group Authentication -> system
Client Configuration
Virtual Address Pool -> checked any private address range
Virtual IPv6 Address Pool -> not checked
Network List -> not checked
Save Auth Password -> checked
DNS Default Domain -> not checked
Split DNS -> not checked
DNS servers -> not checked
WINS Servers -> not checked
Phase2 PFS Group -> not checked
Login Banner -> not checkedIPsec Tunnels -> Mobile Client
General Information
Key Exchange version -> IKEv1
Internet Protocol -> IPv4
Interface -> WAN
Description -> Mobile VPN
Phase 1 Proposal (Authentication)
Authentication Method -> Mutual PSK + Auth
Negotiation mode -> Aggressive (Main does not work)
My Identifier -> My IP address
Peer Identifier -> User distinguished name [@domain]
Pre-Shared Key -> some strong password
Phase 1 Proposal (Algorithms)
Encryption Algorithm -> AES 256 bits
Hash Algorithm -> SHA256
DH Group -> 14
Lifetime (Seconds) -> 86400
Advanced Options
Disable Key -> not checked
Responder Only -> not checked
NAT Traversal -> Force
Dead Peer Detection -> checked
Delay -> 10
Max Failures -> 5Phase 2
General Information
Mode -> Tunnel IPv4
Local Network -> LAN subnet
NAT/BINAT translation -> None
Description -> Only Internal Traffic Mobile VPN
Phase 2 Proposal
Protocol -> ESP
Encryption Algorithms -> AES 128 bits
Hash Algorithms -> SHA1
PFS key group -> off
Lifetime -> 28800