Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    PfSense 2.3.2 fails with macOS 10.11.6 native Cisco-style VPN client (IKE v1)

    Scheduled Pinned Locked Moved IPsec
    31 Posts 6 Posters 8.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      sirozha Banned
      last edited by

      @dennypage:

      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.

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        The logs I posted above say it works just fine. There is something peculiar about your environment it looks like.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • DerelictD
          Derelict LAYER 8 Netgate
          last edited by

          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.

          Chattanooga, Tennessee, USA
          A comprehensive network diagram is worth 10,000 words and 15 conference calls.
          DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
          Do Not Chat For Help! NO_WAN_EGRESS(TM)

          1 Reply Last reply Reply Quote 0
          • dennypageD
            dennypage
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • S
              sirozha Banned
              last edited by

              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!

              1 Reply Last reply Reply Quote 0
              • S
                sirozha Banned
                last edited by

                @dennypage:

                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?

                1 Reply Last reply Reply Quote 0
                • dennypageD
                  dennypage
                  last edited by

                  @sirozha:

                  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… :)

                  1 Reply Last reply Reply Quote 0
                  • DerelictD
                    Derelict LAYER 8 Netgate
                    last edited by

                    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.

                    Chattanooga, Tennessee, USA
                    A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                    DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                    Do Not Chat For Help! NO_WAN_EGRESS(TM)

                    1 Reply Last reply Reply Quote 0
                    • S
                      sirozha Banned
                      last edited by

                      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?

                      1 Reply Last reply Reply Quote 0
                      • S
                        sirozha Banned
                        last edited by

                        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.

                        1 Reply Last reply Reply Quote 0
                        • M
                          macUnix
                          last edited by

                          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 checked

                          IPsec 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 -> 5

                          Phase 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

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.