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


  • Banned

    Hi,

    I can't get IKE v1 Phase 1 negotiated properly between macOS 10.11.6 client using the built in Cisco IPSec client and pfSense 2.3.2

    It appears to me that the pfSense is offering the crypto policy that is EXACTLY the one not offered by the macOS client.

    I've tried various settings for the Encryption Algorithm, Hash Algorithm, and DH Group in pfSense. When I modify one of these settings, the set of crypto policies offered by the macOS client (and shown in the IPSec log of pfSense - see below) changes so that the EXACT policy that IKE v1 Phase 1 crypto policy that I configure in pfSense is missing from the set of the policies offered by the MacOS client. However, when I modify the IKE v1 Phase 1 crypto policy in pfSense to match one of the policies  offered by the macOS client (during the previous unsuccessful attempt), on the subsequent attempt, the macOS client is NOT offering that EXACT crypto policy that it offered on the previous unsuccessful attempt and that is now configured in pfSense for IKE v1 Phase 1.

    Therefore, it appears to me that something is screwed up in pfSense 2.3.2 in a way that the crypto policy configured in pfSense is not negotiated properly with the IPSec v1 mobile client (macOS 10.11.6 native Cisco VPN client).

    Below is an excerpt from the IPSec log that shows one of such unsuccessful attempts.

    I'd appreciate any help with this.

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

    Time Process PID Message
    Aug 26 00:22:48 charon 10[NET] <con1|4>sending packet: from 192.168.160.1[500] to 192.168.160.100[500] (432 bytes)
    Aug 26 00:22:48 charon 10[IKE] <con1|4>sending retransmit 2 of response message ID 0, seq 1
    Aug 26 00:22:46 charon 14[NET] <con1|4>sending packet: from 192.168.160.1[500] to 192.168.160.100[500] (432 bytes)
    Aug 26 00:22:46 charon 14[IKE] <con1|4>received retransmit of request with ID 0, retransmitting response
    Aug 26 00:22:46 charon 14[NET] <con1|4>received packet: from 192.168.160.100[500] to 192.168.160.1[500] (779 bytes)
    Aug 26 00:22:43 charon 14[NET] <con1|4>sending packet: from 192.168.160.1[500] to 192.168.160.100[500] (432 bytes)
    Aug 26 00:22:43 charon 14[IKE] <con1|4>received retransmit of request with ID 0, retransmitting response
    Aug 26 00:22:43 charon 14[NET] <con1|4>received packet: from 192.168.160.100[500] to 192.168.160.1[500] (779 bytes)
    Aug 26 00:22:40 charon 14[NET] <con1|4>sending packet: from 192.168.160.1[500] to 192.168.160.100[500] (432 bytes)
    Aug 26 00:22:40 charon 14[IKE] <con1|4>sending retransmit 1 of response message ID 0, seq 1
    Aug 26 00:22:39 charon 14[NET] <con1|4>sending packet: from 192.168.160.1[500] to 192.168.160.100[500] (432 bytes)
    Aug 26 00:22:39 charon 14[IKE] <con1|4>received retransmit of request with ID 0, retransmitting response
    Aug 26 00:22:39 charon 14[NET] <con1|4>received packet: from 192.168.160.100[500] to 192.168.160.1[500] (779 bytes)
    Aug 26 00:22:36 charon 14[NET] <con1|4>sending packet: from 192.168.160.1[500] to 192.168.160.100[500] (432 bytes)
    Aug 26 00:22:36 charon 14[ENC] <con1|4>generating AGGRESSIVE response 0 [ SA KE No ID V V V V V NAT-D NAT-D HASH ]
    Aug 26 00:22:36 charon 14[CFG] <4> selected peer config "con1"
    Aug 26 00:22:36 charon 14[CFG] <4> looking for XAuthInitPSK peer configs matching 192.168.160.1…192.168.160.100[warriors@acme.com]
    Aug 26 00:22:36 charon 14[IKE] <4> 192.168.160.100 is initiating a Aggressive Mode IKE_SA
    Aug 26 00:22:36 charon 14[IKE] <4> received DPD vendor ID
    Aug 26 00:22:36 charon 14[IKE] <4> received Cisco Unity vendor ID
    Aug 26 00:22:36 charon 14[IKE] <4> received XAuth vendor ID
    Aug 26 00:22:36 charon 14[IKE] <4> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
    Aug 26 00:22:36 charon 14[IKE] <4> received draft-ietf-ipsec-nat-t-ike-02 vendor ID
    Aug 26 00:22:36 charon 14[IKE] <4> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
    Aug 26 00:22:36 charon 14[IKE] <4> received draft-ietf-ipsec-nat-t-ike-04 vendor ID
    Aug 26 00:22:36 charon 14[IKE] <4> received draft-ietf-ipsec-nat-t-ike-05 vendor ID
    Aug 26 00:22:36 charon 14[IKE] <4> received draft-ietf-ipsec-nat-t-ike-06 vendor ID
    Aug 26 00:22:36 charon 14[IKE] <4> received draft-ietf-ipsec-nat-t-ike-07 vendor ID
    Aug 26 00:22:36 charon 14[IKE] <4> received draft-ietf-ipsec-nat-t-ike-08 vendor ID
    Aug 26 00:22:36 charon 14[IKE] <4> received draft-ietf-ipsec-nat-t-ike vendor ID
    Aug 26 00:22:36 charon 14[IKE] <4> received NAT-T (RFC 3947) vendor ID
    Aug 26 00:22:36 charon 14[IKE] <4> received FRAGMENTATION vendor ID
    Aug 26 00:22:36 charon 14[ENC] <4> parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V V V V V V V V V ]
    Aug 26 00:22:36 charon 14[NET] <4> received packet: from 192.168.160.100[500] to 192.168.160.1[500] (779 bytes)
    Aug 26 00:22:36 charon 14[NET] <3> sending packet: from 192.168.160.1[500] to 192.168.160.100[500] (56 bytes)
    Aug 26 00:22:36 charon 14[ENC] <3> generating INFORMATIONAL_V1 request 3550720285 [ N(NO_PROP) ]
    Aug 26 00:22:36 charon 14[IKE] <3> no proposal found
    Aug 26 00:22:36 charon 14[CFG] <3> configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
    Aug 26 00:22:36 charon 14[CFG] <3> received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
    Aug 26 00:22:36 charon 14[IKE] <3> 192.168.160.100 is initiating a Aggressive Mode IKE_SA
    Aug 26 00:22:36 charon 14[IKE] <3> received DPD vendor ID
    Aug 26 00:22:36 charon 14[IKE] <3> received Cisco Unity vendor ID
    Aug 26 00:22:36 charon 14[IKE] <3> received XAuth vendor ID
    Aug 26 00:22:36 charon 14[IKE] <3> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
    Aug 26 00:22:36 charon 14[IKE] <3> received draft-ietf-ipsec-nat-t-ike-02 vendor ID
    Aug 26 00:22:36 charon 14[IKE] <3> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
    Aug 26 00:22:36 charon 14[IKE] <3> received draft-ietf-ipsec-nat-t-ike-04 vendor ID
    Aug 26 00:22:36 charon 14[IKE] <3> received draft-ietf-ipsec-nat-t-ike-05 vendor ID
    Aug 26 00:22:36 charon 14[IKE] <3> received draft-ietf-ipsec-nat-t-ike-06 vendor ID
    Aug 26 00:22:36 charon 14[IKE] <3> received draft-ietf-ipsec-nat-t-ike-07 vendor ID
    Aug 26 00:22:36 charon 14[IKE] <3> received draft-ietf-ipsec-nat-t-ike-08 vendor ID
    Aug 26 00:22:36 charon 14[IKE] <3> received draft-ietf-ipsec-nat-t-ike vendor ID
    Aug 26 00:22:36 charon 14[IKE] <3> received NAT-T (RFC 3947) vendor ID
    Aug 26 00:22:36 charon 14[IKE] <3> received FRAGMENTATION vendor ID
    Aug 26 00:22:36 charon 14[ENC] <3> parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V V V V V V V V V ]
    Aug 26 00:22:36 charon 14[NET] <3> received packet: from 192.168.160.100[500] to 192.168.160.1[500] (779 bytes)</con1|4></con1|4></con1|4></con1|4></con1|4></con1|4></con1|4></con1|4></con1|4></con1|4></con1|4></con1|4></con1|4></con1|4></con1|4>


  • Rebel Alliance Developer Netgate

    These are the proposals sent by the client:

    received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
    

    If you set yours to match one of those, it should work. Split them up so they're easier to read:

    IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048

    • Enc: AES 256, Hash: SHA256, DH Group: 14

    IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048

    • Enc: AES 256, Hash: SHA1, DH Group: 14

    IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_2048

    • Enc: AES 256, Hash: MD5, DH Group: 14

    IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048

    • Enc: AES 256, Hash: SHA512, DH Group: 14

    In contrast, you are set for:
    IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

    • AES 128, SHA1, DH Group 2.

  • Banned

    @jimp:

    These are the proposals sent by the client:

    received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
    

    If you set yours to match one of those, it should work. Split them up so they're easier to read:

    IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048

    • Enc: AES 256, Hash: SHA256, DH Group: 14

    IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048

    • Enc: AES 256, Hash: SHA1, DH Group: 14

    IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_2048

    • Enc: AES 256, Hash: MD5, DH Group: 14

    IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048

    • Enc: AES 256, Hash: SHA512, DH Group: 14

    In contrast, you are set for:
    IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

    • AES 128, SHA1, DH Group 2.

    jump,

    Today I set IPSec Phase 1 (IKE) (Tunnel in pfSense terms) to match the first proposal received from the macOS client in the output I posted yesterday. An excerpt of that output was quoted by you in your response and is quoted above in this post. This is the proposal that I used to configure pfSense Phase 1 and Phase 2 today:

    IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048" 
    

    Again, this proposal was offered by macOS to pfSense yesterday, and it's in the log above.

    The problem is that during the IKE Phase 1 negotiation, the macOS client does not offer EXACTLY the IKE Phase1 proposal that is configured in pfSense. Therefore, if I configure a different proposal in pfSense, then a proposal consisting of THAT particular combination of IKE Phase1 crypto parameters will NOT be offered by macOS as part of a set of proposals that it will offer next time I try to connect to pfSense via IPSec VPN (Cisco flavor with IKE v1) from macOS.

    Please see the log output below. If you compare it to the log output that I posted yesterday, you will see that something occurs during the IKE Phase 1 proposal negotiation that tells macOS NOT to include the proposal with EXACT IKE Phase1 crypto parameters configured in pfSense (on the VPN > Tunnels page).

    
    Time	Process	PID	Message
    Aug 26 16:09:15	charon		08[NET] <6> sending packet: from 192.168.160.1[500] to 192.168.160.100[500] (56 bytes)
    Aug 26 16:09:15	charon		08[ENC] <6> generating INFORMATIONAL_V1 request 1545987601 [ N(NO_PROP) ]
    Aug 26 16:09:15	charon		08[IKE] <6> no proposal found
    Aug 26 16:09:15	charon		08[CFG] <6> configured proposals: [b]IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048[/b]
    Aug 26 16:09:15	charon		08[CFG] <6> received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
    Aug 26 16:09:15	charon		08[IKE] <6> 192.168.160.100 is initiating a Aggressive Mode IKE_SA
    Aug 26 16:09:15	charon		08[IKE] <6> received DPD vendor ID
    Aug 26 16:09:15	charon		08[IKE] <6> received Cisco Unity vendor ID
    Aug 26 16:09:15	charon		08[IKE] <6> received XAuth vendor ID
    Aug 26 16:09:15	charon		08[IKE] <6> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
    Aug 26 16:09:15	charon		08[IKE] <6> received draft-ietf-ipsec-nat-t-ike-02 vendor ID
    Aug 26 16:09:15	charon		08[IKE] <6> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
    Aug 26 16:09:15	charon		08[IKE] <6> received draft-ietf-ipsec-nat-t-ike-04 vendor ID
    Aug 26 16:09:15	charon		08[IKE] <6> received draft-ietf-ipsec-nat-t-ike-05 vendor ID
    Aug 26 16:09:15	charon		08[IKE] <6> received draft-ietf-ipsec-nat-t-ike-06 vendor ID
    Aug 26 16:09:15	charon		08[IKE] <6> received draft-ietf-ipsec-nat-t-ike-07 vendor ID
    Aug 26 16:09:15	charon		08[IKE] <6> received draft-ietf-ipsec-nat-t-ike-08 vendor ID
    Aug 26 16:09:15	charon		08[IKE] <6> received draft-ietf-ipsec-nat-t-ike vendor ID
    Aug 26 16:09:15	charon		08[IKE] <6> received NAT-T (RFC 3947) vendor ID
    Aug 26 16:09:15	charon		08[IKE] <6> received FRAGMENTATION vendor ID
    Aug 26 16:09:15	charon		08[ENC] <6> parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V V V V V V V V V ]
    Aug 26 16:09:15	charon		08[NET] <6> received packet: from 192.168.160.100[500] to 192.168.160.1[500] (779 bytes)
    Aug 26 16:09:15	charon		08[NET] <5> sending packet: from 192.168.160.1[500] to 192.168.160.100[500] (56 bytes)
    Aug 26 16:09:15	charon		08[ENC] <5> generating INFORMATIONAL_V1 request 2819820963 [ N(AUTH_FAILED) ]
    Aug 26 16:09:15	charon		08[IKE] <5> Aggressive Mode PSK disabled for security reasons
    Aug 26 16:09:15	charon		08[IKE] <5> 192.168.160.100 is initiating a Aggressive Mode IKE_SA
    Aug 26 16:09:15	charon		08[IKE] <5> received DPD vendor ID
    Aug 26 16:09:15	charon		08[IKE] <5> received Cisco Unity vendor ID
    Aug 26 16:09:15	charon		08[IKE] <5> received XAuth vendor ID
    Aug 26 16:09:15	charon		08[IKE] <5> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
    Aug 26 16:09:15	charon		08[IKE] <5> received draft-ietf-ipsec-nat-t-ike-02 vendor ID
    Aug 26 16:09:15	charon		08[IKE] <5> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
    Aug 26 16:09:15	charon		08[IKE] <5> received draft-ietf-ipsec-nat-t-ike-04 vendor ID
    Aug 26 16:09:15	charon		08[IKE] <5> received draft-ietf-ipsec-nat-t-ike-05 vendor ID
    Aug 26 16:09:15	charon		08[IKE] <5> received draft-ietf-ipsec-nat-t-ike-06 vendor ID
    Aug 26 16:09:15	charon		08[IKE] <5> received draft-ietf-ipsec-nat-t-ike-07 vendor ID
    Aug 26 16:09:15	charon		08[IKE] <5> received draft-ietf-ipsec-nat-t-ike-08 vendor ID
    Aug 26 16:09:15	charon		08[IKE] <5> received draft-ietf-ipsec-nat-t-ike vendor ID
    Aug 26 16:09:15	charon		08[IKE] <5> received NAT-T (RFC 3947) vendor ID
    Aug 26 16:09:15	charon		08[IKE] <5> received FRAGMENTATION vendor ID
    Aug 26 16:09:15	charon		08[ENC] <5> parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V V V V V V V V V ]
    Aug 26 16:09:15	charon		08[NET] <5> received packet: from 192.168.160.100[500] to 192.168.160.1[500] (779 bytes)
    
    

  • Rebel Alliance Developer Netgate

    That's a completely different set of proposals from the client:

    IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
    IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
    IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
    IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
    IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
    IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
    IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
    IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024

    None of which match. Something else must have changed on the client or server side P1 config, it wouldn't just randomly decide to propose a completely different set of ciphers. The server side does NOT tell the client what it supports. The client tells the server and the server looks for a match.


  • Banned

    @jimp:

    That's a completely different set of proposals from the client:

    IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
    IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
    IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
    IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
    IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
    IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
    IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
    IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024

    None of which match. Something else must have changed on the client or server side P1 config, it wouldn't just randomly decide to propose a completely different set of ciphers. The server side does NOT tell the client what it supports. The client tells the server and the server looks for a match.

    This is exactly my point. Every time I change the settings in IKE Phase 1 in pfSense, the macOS client offers a completely different set of proposals, and the EXACT proposal that I configure in pfSense is missing from the new set of proposals offered by the macOS client.

    Nothing changed on the macOS client. The ISAKMP or IPSec parameters are not configurable in the macOS GUI. Therefore, there must be some negotiation that happens with pfSense that causes macOS to offer a completely different set of proposals. As long as I keep IKE Phase 1 parameters in pfSense unchanged, the macOS client consistently offers the same set of proposals on every subsequent attempt. Once I modify something in pfSense for IKE Phase 1, the next time I try to connect via IPSec VPN from macOS, a completely different set of proposals will be offered by macOS to pfSense, and the exact parameters configured for IKE Phase 1 in pfSense will be missing from the new set of proposals offered by macOS. I've tested this a few dozen time and confirmed this behavior.


  • Banned

    I have a few updates to my situation.

    1. I got an old Cisco IPSec VPN Client working with pfSense Mobile Client VPN. The Cisco IPSec VPN Client that I used is version 5.0.07.0410, which I believe is the last version that Cisco released before the software went EOL.

    2. The highest IKE Phase 1 / Phase 2 security settings that work with this Cisco IPSec VPN Client version are:
    Encryption Algorithm: AES 256
    Hash Algorithm: SHA1
    DH Group (IKE Phase 1): 2 (1024 bit)
    PFS Key Group (IKE Phase 2): Off

    3. The same settings that work with the Cisco IPSec VPN Client for Windows, do not work with the macOS El Capitan 10.11.6 built-in IPSec VPN client. Something really strange is happening with the set of proposals that the macOS IPSec VPN client is sending to pfSense. It so happens that the EXACT security settings configured for IKE Phase 1 in pfSense are NOT offered by the macOS IPSec VPN client in the set of proposals that it sends to pfSense, or so thinks pfSense according to its IPSec log.

    4. Prior to macOS IPSec VPN client sending its IKE Phase 1 proposals to pfSense, there is a lot of IKE-related chatting happening between pfSense and macOS IPSec VPN client. It is absolutely NOT a coincidence that EVERY time I change one setting (no matter if it's AES strength, HMAC type or strength, or DH Group key length), during the next negotiation of IKE Phase 1, the IKE Phase 1 proposals seen in the IPSec log in pfSense as received from the macOS IPSec VPN client do NOT include the VERY set of IKE Phase 1 settings configured in pfSense. I have not being able to figure out why this happens, but I have a higher-level IPSec log enabled, which shows a LOT of chatting happening between pfSense and macOS IPSec VPN client BEFORE the latter sends its proposals to pfSense.

    5. I found a post on the Adtran form that may shed some light on why macOS El Capitan 10.11.6 may have this strange behavior with pfSense.
    https://supportforums.adtran.com/thread/7804

    6. From the above Adtran forum post, I learned the location and the name of a dynamically created configuration file that macOS creates during its IKE Phase 1 negotiation with a VPN server (pfSense 2.3.2 in this case). This dynamic file is:

    /var/run/racoon/<vpn_server_ip>.conf</vpn_server_ip>
    

    This file is dynamic, and it exists only for the duration of IKE Phase 1 negotiation. So, if you want to see it, you have to enter the following command and be ready to press enter during a few seconds of PFSense and macOS negotiating IKE Phase 1.

    sudo cat /var/run/racoon/<vpn_server_ip>.conf</vpn_server_ip>
    

    I would also suggest running this command BEFORE attempting to connect with the IPSec VPN tunnel from macOS in order to be prompted for the password and supply the password. The output will be empty, but your password will be remembered for a couple minutes, so next time you run this command while macOS VPN client is trying to connect to pfSense, you will actually see the content of this dynamic file.

    7. Below is the content of my file when I try to connect to pfSense from macOS via its IPSec VPN client:

    
    sudo cat 192.168.160.1.conf
    remote 192.168.160.1 {
       doi ipsec_doi;
       situation identity_only;
       exchange_mode aggressive;
       my_identifier keyid_use "warriors@acme.com";
       verify_identifier off;
       shared_secret keychain "XXXX";
       local_address 192.168.160.100;
       nonce_size 16;
       dpd_delay 20;
       dpd_retry 5;
       dpd_maxfail 5;
       dpd_algorithm dpd_blackhole_detect;
       initial_contact on;
       support_proxy on;
       proposal_check obey;
       xauth_login "sirozha";
       mode_cfg on;
    
       proposal {
          authentication_method xauth_psk_client;
          hash_algorithm sha256;
          encryption_algorithm aes 256;
          lifetime time 3600 sec;
          dh_group 14;
       }
    
       proposal {
          authentication_method xauth_psk_client;
          hash_algorithm sha1;
          encryption_algorithm aes 256;
          lifetime time 3600 sec;
          dh_group 14;
       }
    
       proposal {
          authentication_method xauth_psk_client;
          hash_algorithm md5;
          encryption_algorithm aes 256;
          lifetime time 3600 sec;
          dh_group 14;
       }
    
       proposal {
          authentication_method xauth_psk_client;
          hash_algorithm sha512;
          encryption_algorithm aes 256;
          lifetime time 3600 sec;
          dh_group 14;
       }
    }
    
    

    8. pfSense IKE Phase 1 is currently set to:

    Encryption Algorithm: 256
    Hash Algorithm: SHA1
    DH Group: 14 (2048 bit)
    

    So, as you can see, the second proposal above (in #7) (listed in the temporary file /var/run/racoon/192.168.160.1.conf) contains EXACTLY the same parameters as the ones configured for IKE Phase 1 in pfSense. HOWEVER, here is the problem. When I review the pfSense IPSec log, the proposals that pfSense sees coming from macOS 10.11.6 IPSec VPN client are:

    
    received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
    
    

    As  you can see, the IKE Phase 1 parameters configured in pfSense are not part of ANY IKE Phase 1 proposal SUPPOSEDLY received from the macOS IPSec VPN tunnel according to the pfSense IPSec log. The mismatch between the proposals received from macOS and the IKE Phase 1 parameters configured in pfSense is the DH Group: it's DH Group 14 in pfSense and DH Group 2 in EVERY proposal seen by pfSense as coming from macOS 10.11.6.

    9. Here's the kicker, I say, "OK, then" and priced to change DH Group in pfSense IKE Phase 1 from DH Group 14 to DH Group 2 (in order to match what macOS IPSec VPN client is SUPPOSEDLY sending to pfSense). Once I make the change and apple it, I try to connect to pfSense from the macOS IPSec VPN tunnel again, and this is what I see:

    In macOS 10.11.6, the file temporary file var/run/racoon/192.168.160.1.conf contains the following:

    
    udo cat 192.168.160.1.conf
    remote 192.168.160.1 {
       doi ipsec_doi;
       situation identity_only;
       exchange_mode aggressive;
       my_identifier keyid_use "warriors@acme.com";
       verify_identifier off;
       shared_secret keychain "XXXX";
       local_address 192.168.160.100;
       nonce_size 16;
       dpd_delay 20;
       dpd_retry 5;
       dpd_maxfail 5;
       dpd_algorithm dpd_blackhole_detect;
       initial_contact on;
       support_proxy on;
       proposal_check obey;
       xauth_login "sirozha";
       mode_cfg on;
    
       proposal {
          authentication_method xauth_psk_client;
          hash_algorithm sha256;
          encryption_algorithm aes 256;
          lifetime time 3600 sec;
          dh_group 14;
       }
    
       proposal {
          authentication_method xauth_psk_client;
          hash_algorithm sha1;
          encryption_algorithm aes 256;
          lifetime time 3600 sec;
          dh_group 14;
       }
    
       proposal {
          authentication_method xauth_psk_client;
          hash_algorithm md5;
          encryption_algorithm aes 256;
          lifetime time 3600 sec;
          dh_group 14;
       }
    
       proposal {
          authentication_method xauth_psk_client;
          hash_algorithm sha512;
          encryption_algorithm aes 256;
          lifetime time 3600 sec;
          dh_group 14;
       }
    }
    
    

    However, the pfSense IPSec log is showing that the following IKE Phase 1 proposals were received by pfSense from macOS 10.11.6 IPSec VPN Client:

    
    09[CFG] <70> received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
    
    

    As you can see, in this case, the content of the proposals listed in the temporary file var/run/racoon/192.168.160.1.conf match EXACTLY what pfSense has in it IPSec log as the set of IKE Phase 1 proposals sent by macOS 10.11.6 IPSec VPN client. HOWEVER, none of these four IKE Phase 1 proposals sent by macOS IPSec VPN client has the DH Group that matches the one set in pfSense IKE Phase 1 configuration. The DF Group was the very setting I changed in this step, which resulted in pfSense seeing a completely different set of IKE Phase 1 proposals received from the macOS IPSec VPN client than the set of proposals received during the earlier attempt.

    10. Conclusion: In my opinion, during the chatting between pfSense and macOS 10.11.6 IPSec VPN client that occurs BEFORE macOS IPSec VPN client sends its IKE Phase 1 proposals to pfSense, something is said by either pfSense or macOS that causes this strange behavior, which results in IKE Phase 1 proposals seen by pfSense as sent by macOS 10.11.6 IPSec VPN client always missing the EXACT set of IKE Phase 1 parameters configured in pfSense. I would LOVE for pfSense engineers to look into this and figure out what is happening here.

    Below is the chatting that occurs between pfSense and macOS 10.11.6 IPSec VPN client BEFORE the latter sends its IKE Phase 1 proposals to the former:

    
    Aug 27 01:11:25	charon		09[IKE] no proposal found
    Aug 27 01:11:25	charon		09[CFG] <68> configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
    Aug 27 01:11:25	charon		09[CFG] <68> received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
    Aug 27 01:11:25	charon		09[IKE] <68> IKE_SA (unnamed)[68] state change: CREATED => CONNECTING
    Aug 27 01:11:25	charon		09[IKE] IKE_SA (unnamed)[68] state change: CREATED => CONNECTING
    Aug 27 01:11:25	charon		09[IKE] <68> 192.168.160.100 is initiating a Aggressive Mode IKE_SA
    Aug 27 01:11:25	charon		09[IKE] 192.168.160.100 is initiating a Aggressive Mode IKE_SA
    Aug 27 01:11:25	charon		09[IKE] <68> received DPD vendor ID
    Aug 27 01:11:25	charon		09[IKE] received DPD vendor ID
    Aug 27 01:11:25	charon		09[IKE] <68> received Cisco Unity vendor ID
    Aug 27 01:11:25	charon		09[IKE] received Cisco Unity vendor ID
    Aug 27 01:11:25	charon		09[IKE] <68> received XAuth vendor ID
    Aug 27 01:11:25	charon		09[IKE] received XAuth vendor ID
    Aug 27 01:11:25	charon		09[IKE] <68> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
    Aug 27 01:11:25	charon		09[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
    Aug 27 01:11:25	charon		09[IKE] <68> received draft-ietf-ipsec-nat-t-ike-02 vendor ID
    Aug 27 01:11:25	charon		09[IKE] received draft-ietf-ipsec-nat-t-ike-02 vendor ID
    Aug 27 01:11:25	charon		09[IKE] <68> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
    Aug 27 01:11:25	charon		09[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID
    Aug 27 01:11:25	charon		09[IKE] <68> received draft-ietf-ipsec-nat-t-ike-04 vendor ID
    Aug 27 01:11:25	charon		09[IKE] received draft-ietf-ipsec-nat-t-ike-04 vendor ID
    Aug 27 01:11:25	charon		09[IKE] <68> received draft-ietf-ipsec-nat-t-ike-05 vendor ID
    Aug 27 01:11:25	charon		09[IKE] received draft-ietf-ipsec-nat-t-ike-05 vendor ID
    Aug 27 01:11:25	charon		09[IKE] <68> received draft-ietf-ipsec-nat-t-ike-06 vendor ID
    Aug 27 01:11:25	charon		09[IKE] received draft-ietf-ipsec-nat-t-ike-06 vendor ID
    Aug 27 01:11:25	charon		09[IKE] <68> received draft-ietf-ipsec-nat-t-ike-07 vendor ID
    Aug 27 01:11:25	charon		09[IKE] received draft-ietf-ipsec-nat-t-ike-07 vendor ID
    Aug 27 01:11:25	charon		09[IKE] <68> received draft-ietf-ipsec-nat-t-ike-08 vendor ID
    Aug 27 01:11:25	charon		09[IKE] received draft-ietf-ipsec-nat-t-ike-08 vendor ID
    Aug 27 01:11:25	charon		09[IKE] <68> received draft-ietf-ipsec-nat-t-ike vendor ID
    Aug 27 01:11:25	charon		09[IKE] received draft-ietf-ipsec-nat-t-ike vendor ID
    Aug 27 01:11:25	charon		09[IKE] <68> received NAT-T (RFC 3947) vendor ID
    Aug 27 01:11:25	charon		09[IKE] received NAT-T (RFC 3947) vendor ID
    Aug 27 01:11:25	charon		09[IKE] <68> received FRAGMENTATION vendor ID
    Aug 27 01:11:25	charon		09[IKE] received FRAGMENTATION vendor ID
    Aug 27 01:11:25	charon		09[ENC] <68> parsed AGGRESSIƒVE request 0 [ SA KE No ID V V V V V V V V V V V V V V ]
    Aug 27 01:11:25	charon		09[NET] <68> received packet: from 192.168.160.100[500] to 192.168.160.1[500] (779 bytes)
    
    

    Thank you!



  • I'm seeing the same end behaviour - whichever DH Group is set (2 or 14) the Mac OS 10.11.6 client proposed the other.

    Did you raise a bug sirozha?


  • Banned

    @jumpymonkey:

    I'm seeing the same end behaviour - whichever DH Group is set (2 or 14) the Mac OS 10.11.6 client proposed the other.

    Did you raise a bug sirozha?

    I am slowly but surely trying to understand the underlying reason for this behavior. I've just come across this:
    https://support.apple.com/en-us/HT206154

    Apparently (according to this article), in macOS 10.11.4, Apple introduced DF Group 14 for IPSec VPN client, as well as DH Group 14 and 5 for the L2TP over IPSec client. With Aggressive mode, the macOS IPSec (Cisco VPN) Client first tries DH Group 14, and if the negotiation fails, it goes straight to DH Group 2 (skipping DH Group 5).

    The problem we are experiencing seems to suggest that there's some sort of failure occurring between macOS Cisco VPN Client and pfSense when negotiating DH Group 14, after which the macOS Cisco VPN Client tries DF Group 2. When DH Group 14 is set for IKE Phase 1 in pfSense, macOS Cisco VPN Client's IKE Phase 1 proposals with DH Group 2 can be seen in the IPSec log of pfSense. However, the IPSec log in pfSense doesn't explicitly show the failure in negotiating DH Group 14 with the macOS Cisco VPN Client PRIOR to the macOS Cisco VPN client failing over to to DH Group 2.

    The fact that we are seeing this weird behavior with the IKE Phase 1 proposals seen in the pfSense IPSEc log, whereby the proposals sent by the macOS Cisco VPN Client are missing EXACTLY the parameters configured in IKE Phase 1 in pfSense seem to suggest the following:

    1. The behavior of the macOS Cisco VPN client described in the article linked to above matches the behavior we we are seeing from the pfSense IPSec logs.
    2. There's some sort of incompatibility between pfSense and macOS Cisco VPN Client in negotiating DH Group 14 (as well as DH Group 2 for that matter!).
    3. There are multiple reports on the web of macOS 10.11.4 having introduced this new behavior for the macOS Cisco VPN Client resulting in mobile macOS clients no longer being able to connect to their VPN headends after upgrading to macOS 10.11.4. However, once the admins figured out that the headend needed to change its IKE Phase 1 configuration to DH Group 14, the problem was resolved, and that was the case for headends of various manufacturers. Therefore, the problem that the macOS Cisco VPN Client (in macOS 10.11.4 and later version) negotiating DH Group 14 with pfSense 2.3.2 seems to be on the pfSense end.
    4. When pfSense is configured for DH Group 2, the macOS Cisco VPN Client doesn't attempt any proposals with DH Group 2 according to the IPSEc log in pfSense. Therefore, it appears that something is missing in the control messages that pfSense SHOULD BE but NOT sending back to the macOS Cisco VPN client when the latter attempts DH Group 14 (as per the document linked to above). I am assuming this because macOS Cisco VPN client is NOT trying to fail over its IKE Phase 1 proposals to DH Group 2 when IKE Phase 1 DH Group is set to Group 2 in pfSense.
    5. Apple released macOS 10.11.4 (which introduced this new behavior of the macOS Cisco VPN Client) on March 23, 2016. pfSense 2.3.2 was released on July 25, 2016. It's unclear to me if pfSense releases prior to 2.3.2 worked correctly with the macOS (10.11.4 and later) Cisco VPN Client, but it's safe to assume that the incompatibility between the macOS Cisco VPN Client and pfSense occurred between March 23, 2016 and July 25, 2016.

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

    I believe the bug needs to be raised with pfSense. I'm a new user of pfSense, so I'm not sure yet how to raise a bug.


  • Banned

    Bug has been created for this issue. Bug ID 6745.



  • Great. I'll track the issue there. I have some verbose logs from the Mac side I'll work through over the weekend and see if there is anything more there - it certainly shows both the 2048 & 1024 modp option but I could see anything that showed where the decision is made to send the wrong value to the server. I'll update the bug if I find anything potentially useful.

    Thanks for putting in the work on this.


  • Banned

    I was able to configure L2TP over IPSec in pfSense 2.3.2 and connect from a macOS 10.11.6 built-in L2TP over IPSec Client.

    The transform configured in IKE Phase 1 is as follows:

    Authentication Method: Mutual PSK
    Negotiation Mode: Main
    My Identifier: My IP Address
    Encryption Algorithm: AES (256 bits)
    Hash Algorithm (SHA256)
    DH Group: 14 (2048 bit)
    Lifetime (Seconds): 28800

    –----------

    IKE Phase 2 Policy:
    Mode: Transport
    Protocol: ESP
    Encryption Algorithms: AES (128 bits)
    Hash Algorithm: SHA1
    PFS key group: off
    Lifetime: 28800


    L2TP over IPSec uses the same concepts of IKE Phase 1 and IKE Phase 2. The difference is that in L2TP over IPSec's IKE Phase 1, the Negotiation Mode used is Main (instead of Aggressive), and in its IKE Phase 2, the Mode used is Transport (instead of Tunnel).

    Per the Apple document linked to in one of my posts above, it's apparent that Apple modified the behavior of its Cisco VPN client and L2TP over IPSec VPN client the same way starting with macOS 10.11.6. Therefore, in my opinion, the problem that is reported in this thread (with pfSense 2.3.2 not being able to negotiate IKE Phase 1 with macOS 10.11.6 Cisco VPN client) is on the pfSense end, and not on the macOS end.



  • FWIW I followed the thread using Apple Configurator 2 to generate a config file, and that worked fine for IKEv2 and various DH and cipher settings and RADIUS auth. It'd be good if it worked with the defaults Preferences uses though.


  • Banned

    @jumpymonkey:

    FWIW I followed the thread using Apple Configurator 2 to generate a config file, and that worked fine for IKEv2 and various DH and cipher settings and RADIUS auth. It'd be good if it worked with the defaults Preferences uses though.

    This thread is about IKEv1 with PSK and X-Auth.


  • Rebel Alliance Developer Netgate

    I'm still not convinced that "Apple changed their client, now it doesn't work" translates to it being a problem on pfSense.

    It may be technically possible to work around their faults, but that does not mean the fault is not on the client side. Raise a case with Apple and tell them to fix their client.


  • Banned

    @jimp:

    I'm still not convinced that "Apple changed their client, now it doesn't work" translates to it being a problem on pfSense.

    It may be technically possible to work around their faults, but that does not mean the fault is not on the client side. Raise a case with Apple and tell them to fix their client.

    Wow! The client works with any other vendor, including Cisco and a multitude of other routers and firewalls. You seriously think if I raise a ticket with Apple for their client not working with pfSense, the ticket is going to go anywhere? We are talking about two vendors that had an incompatibility issue. One vendor is a corporation with the highest EVER market capitalization and profits that ANY corporation has ever had, and the other is a small open-source project. And again, the client made by this giant corporation works pretty much with EVERY other vendor's IPSec headend except for the firewall made by a small open-source project.

    Can I pay someone at pfSense to fix this issue because obviously there's a blame game going on here instead of looking into the issue.

    This kind of attitude makes me think twice before considering pfSense as a viable firewall.


  • Rebel Alliance Developer Netgate

    Just because it works with other vendors does not mean it still isn't a client bug. You changed nothing on pfSense but the client changed, and then it broke, so it won't hurt to ask them to look into what they broke. If they ignore your bug report, it would make me think twice about working with Apple since they broke the client and wouldn't fix it.

    Or just move on to IKEv2 like the rest of the world has (or is going to).

    We don't do paid development, but if you want to put up a bounty and see if someone can come up with a PR, go ahead. If the IPsec GUI allowed selection of multiple options like the P2 does, it would allow you to accommodate this broken client, but that's a lot more work than it would appear to be at a glance. It's something we intend to do, but we haven't allocated resources toward it yet since it has not been a pressing issue.

    Apple has broken other aspects of their clients along the way as well, one example is rekeying IKEv2 when not using the profile configuration utility. We only recent convinced them that their client was, in fact, broken and sending out-of-spec data when rekeying. Use the VPN profile config and it works fine, use defaults and it breaks. The client is sending bad data, nothing we can control in that case either. They need to be doing a better job, and if nobody tells them they aren't, they'll keep half-assing their clients.


  • Banned

    @jimp:

    Just because it works with other vendors does not mean it still isn't a client bug. You changed nothing on pfSense but the client changed, and then it broke, so it won't hurt to ask them to look into what they broke. If they ignore your bug report, it would make me think twice about working with Apple since they broke the client and wouldn't fix it.

    Or just move on to IKEv2 like the rest of the world has (or is going to).

    We don't do paid development, but if you want to put up a bounty and see if someone can come up with a PR, go ahead. If the IPsec GUI allowed selection of multiple options like the P2 does, it would allow you to accommodate this broken client, but that's a lot more work than it would appear to be at a glance. It's something we intend to do, but we haven't allocated resources toward it yet since it has not been a pressing issue.

    Apple has broken other aspects of their clients along the way as well, one example is rekeying IKEv2 when not using the profile configuration utility. We only recent convinced them that their client was, in fact, broken and sending out-of-spec data when rekeying. Use the VPN profile config and it works fine, use defaults and it breaks. The client is sending bad data, nothing we can control in that case either. They need to be doing a better job, and if nobody tells them they aren't, they'll keep half-assing their clients.

    All of this makes sense except the same macOS built-in Cisco VPN client works fine with other vendors' headends. I'm not going to comment on the IKE v2 issue you mentioned as I have no experience with that aspect.

    I know that Apple occasionally introduces bugs in their software upgrades, but this particular issue appears to be a bug on the pfSense end - just logically arriving at this conclusion based on the fact that other vendors have no problem with this new macOS Cisco VPN client behavior without having to fix anything on their end.

    And if you think you should ignore Apple products - for whatever reason - it's your decision. It's obviously a bad business decision for pfSense, but perhaps pfSense is not a business per se but a hobby.


  • Netgate

    I just built this…again...loosely following this: https://doc.pfsense.org/index.php/IPsec_Road_Warrior/Mobile_Client_How-To

    Worked fine.

    I have been unable to duplicate the behavior you describe.

    Aug 31 00:25:52 pfSense charon: 11[CFG] rereading secrets
    Aug 31 00:25:52 pfSense charon: 11[CFG] loading secrets from '/var/etc/ipsec/ipsec.secrets'
    Aug 31 00:25:52 pfSense charon: 11[CFG]  loaded IKE secret for 203.0.113.17 vpnusers@example.com
    Aug 31 00:25:52 pfSense charon: 11[CFG]  loaded IKE secret for %any
    Aug 31 00:25:52 pfSense charon: 11[CFG]  loaded EAP secret for testuser
    Aug 31 00:25:52 pfSense charon: 11[CFG] rereading ca certificates from '/usr/local/etc/ipsec.d/cacerts'
    Aug 31 00:25:52 pfSense charon: 11[CFG] rereading aa certificates from '/usr/local/etc/ipsec.d/aacerts'
    Aug 31 00:25:52 pfSense charon: 11[CFG] rereading ocsp signer certificates from '/usr/local/etc/ipsec.d/ocspcerts'
    Aug 31 00:25:52 pfSense charon: 11[CFG] rereading attribute certificates from '/usr/local/etc/ipsec.d/acerts'
    Aug 31 00:25:52 pfSense charon: 11[CFG] rereading crls from '/usr/local/etc/ipsec.d/crls'
    Aug 31 00:25:52 pfSense charon: 07[CFG] received stroke: unroute 'bypasslan'
    Aug 31 00:25:52 pfSense charon: 07[CFG] proposing traffic selectors for us:
    Aug 31 00:25:52 pfSense charon: 07[CFG]  192.168.1.0/24|/0
    Aug 31 00:25:52 pfSense charon: 07[CFG] proposing traffic selectors for other:
    Aug 31 00:25:52 pfSense charon: 07[CFG]  192.168.1.0/24|/0
    Aug 31 00:25:52 pfSense ipsec_starter[25095]: shunt policy 'bypasslan' uninstalled
    Aug 31 00:25:52 pfSense ipsec_starter[25095]:
    Aug 31 00:25:52 pfSense charon: 11[CFG] received stroke: delete connection 'bypasslan'
    Aug 31 00:25:52 pfSense charon: 11[CFG] deleted connection 'bypasslan'
    Aug 31 00:25:52 pfSense charon: 08[CFG] received stroke: delete connection 'con1'
    Aug 31 00:25:52 pfSense charon: 08[CFG] deleted connection 'con1'
    Aug 31 00:25:52 pfSense charon: 07[CFG] received stroke: add connection 'bypasslan'
    Aug 31 00:25:52 pfSense charon: 07[CFG] conn bypasslan
    Aug 31 00:25:52 pfSense charon: 07[CFG]  left=%any
    Aug 31 00:25:52 pfSense charon: 07[CFG]  leftsubnet=192.168.1.0/24
    Aug 31 00:25:52 pfSense charon: 07[CFG]  right=%any
    Aug 31 00:25:52 pfSense charon: 07[CFG]  rightsubnet=192.168.1.0/24
    Aug 31 00:25:52 pfSense charon: 07[CFG]  ike=aes128-sha256-modp3072
    Aug 31 00:25:52 pfSense charon: 07[CFG]  esp=aes128-sha256
    Aug 31 00:25:52 pfSense charon: 07[CFG]  dpddelay=30
    Aug 31 00:25:52 pfSense charon: 07[CFG]  dpdtimeout=150
    Aug 31 00:25:52 pfSense charon: 07[CFG]  mediation=no
    Aug 31 00:25:52 pfSense charon: 07[CFG] added configuration 'bypasslan'
    Aug 31 00:25:52 pfSense charon: 08[CFG] received stroke: route 'bypasslan'
    Aug 31 00:25:52 pfSense charon: 08[CFG] proposing traffic selectors for us:
    Aug 31 00:25:52 pfSense charon: 08[CFG]  192.168.1.0/24|/0
    Aug 31 00:25:52 pfSense charon: 08[CFG] proposing traffic selectors for other:
    Aug 31 00:25:52 pfSense charon: 08[CFG]  192.168.1.0/24|/0
    Aug 31 00:25:52 pfSense ipsec_starter[25095]: 'bypasslan' shunt PASS policy installed
    Aug 31 00:25:52 pfSense ipsec_starter[25095]:
    Aug 31 00:25:52 pfSense charon: 07[CFG] received stroke: add connection 'con1'
    Aug 31 00:25:52 pfSense charon: 07[CFG] conn con1
    Aug 31 00:25:52 pfSense charon: 07[CFG]  left=203.0.113.17
    Aug 31 00:25:52 pfSense charon: 07[CFG]  leftsubnet=0.0.0.0/0
    Aug 31 00:25:52 pfSense charon: 07[CFG]  leftauth=psk
    Aug 31 00:25:52 pfSense charon: 07[CFG]  leftid=203.0.113.17
    Aug 31 00:25:52 pfSense charon: 07[CFG]  right=%any
    Aug 31 00:25:52 pfSense charon: 07[CFG]  rightsourceip=172.25.240.0/24
    Aug 31 00:25:52 pfSense charon: 07[CFG]  rightauth=psk
    Aug 31 00:25:52 pfSense charon: 07[CFG]  rightauth2=xauth-generic
    Aug 31 00:25:52 pfSense charon: 07[CFG]  ike=aes128-sha1-modp1024!
    Aug 31 00:25:52 pfSense charon: 07[CFG]  esp=aes256-sha1,aes256-sha256,aes192-sha1,aes192-sha256,aes128-sha1,aes128-sha256,3des-sha1,3des-sha256!
    Aug 31 00:25:52 pfSense charon: 07[CFG]  dpddelay=10
    Aug 31 00:25:52 pfSense charon: 07[CFG]  dpdtimeout=60
    Aug 31 00:25:52 pfSense charon: 07[CFG]  dpdaction=1
    Aug 31 00:25:52 pfSense charon: 07[CFG]  mediation=no
    Aug 31 00:25:52 pfSense charon: 07[CFG]  keyexchange=ikev1
    Aug 31 00:25:52 pfSense charon: 07[CFG] reusing virtual IP address pool 172.25.240.0/24
    Aug 31 00:25:52 pfSense charon: 07[CFG] added configuration 'con1'
    Aug 31 00:26:52 pfSense charon: 07[NET] <11> received packet: from 203.0.113.16[500] to 203.0.113.17[500] (776 bytes)
    Aug 31 00:26:52 pfSense charon: 07[ENC] <11> parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V V V V V V V V V ]
    Aug 31 00:26:52 pfSense charon: 07[CFG] <11> looking for an ike config for 203.0.113.17…203.0.113.16
    Aug 31 00:26:52 pfSense charon: 07[CFG] <11>  candidate: %any…%any, prio 24
    Aug 31 00:26:52 pfSense charon: 07[CFG] <11>  candidate: 203.0.113.17…%any, prio 1052
    Aug 31 00:26:52 pfSense charon: 07[CFG] <11> found matching ike config: 203.0.113.17…%any with prio 1052
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received FRAGMENTATION vendor ID
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received NAT-T (RFC 3947) vendor ID
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received draft-ietf-ipsec-nat-t-ike vendor ID
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received draft-ietf-ipsec-nat-t-ike-08 vendor ID
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received draft-ietf-ipsec-nat-t-ike-07 vendor ID
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received draft-ietf-ipsec-nat-t-ike-06 vendor ID
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received draft-ietf-ipsec-nat-t-ike-05 vendor ID
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received draft-ietf-ipsec-nat-t-ike-04 vendor ID
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received draft-ietf-ipsec-nat-t-ike-02 vendor ID
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received XAuth vendor ID
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received Cisco Unity vendor ID
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> received DPD vendor ID
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> 203.0.113.16 is initiating a Aggressive Mode IKE_SA
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> IKE_SA (unnamed)[11] state change: CREATED => CONNECTING
    Aug 31 00:26:52 pfSense charon: 07[CFG] <11> selecting proposal:
    Aug 31 00:26:52 pfSense charon: 07[CFG] <11>  no acceptable ENCRYPTION_ALGORITHM found
    Aug 31 00:26:52 pfSense charon: 07[CFG] <11> selecting proposal:
    Aug 31 00:26:52 pfSense charon: 07[CFG] <11>  no acceptable ENCRYPTION_ALGORITHM found
    Aug 31 00:26:52 pfSense charon: 07[CFG] <11> selecting proposal:
    Aug 31 00:26:52 pfSense charon: 07[CFG] <11>  no acceptable ENCRYPTION_ALGORITHM found
    Aug 31 00:26:52 pfSense charon: 07[CFG] <11> selecting proposal:
    Aug 31 00:26:52 pfSense charon: 07[CFG] <11>  no acceptable ENCRYPTION_ALGORITHM found
    Aug 31 00:26:52 pfSense charon: 07[CFG] <11> received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
    Aug 31 00:26:52 pfSense charon: 07[CFG] <11> configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> no proposal found
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> queueing INFORMATIONAL task
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> activating new tasks
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11>  activating INFORMATIONAL task
    Aug 31 00:26:52 pfSense charon: 07[ENC] <11> generating INFORMATIONAL_V1 request 2759542525 [ N(NO_PROP) ]
    Aug 31 00:26:52 pfSense charon: 07[NET] <11> sending packet: from 203.0.113.17[500] to 203.0.113.16[500] (56 bytes)
    Aug 31 00:26:52 pfSense charon: 07[IKE] <11> IKE_SA (unnamed)[11] state change: CONNECTING => DESTROYING
    Aug 31 00:26:52 pfSense charon: 08[NET] <12> received packet: from 203.0.113.16[500] to 203.0.113.17[500] (776 bytes)
    Aug 31 00:26:52 pfSense charon: 08[ENC] <12> parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V V V V V V V V V ]
    Aug 31 00:26:52 pfSense charon: 08[CFG] <12> looking for an ike config for 203.0.113.17…203.0.113.16
    Aug 31 00:26:52 pfSense charon: 08[CFG] <12>  candidate: %any…%any, prio 24
    Aug 31 00:26:52 pfSense charon: 08[CFG] <12>  candidate: 203.0.113.17…%any, prio 1052
    Aug 31 00:26:52 pfSense charon: 08[CFG] <12> found matching ike config: 203.0.113.17…%any with prio 1052
    Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received FRAGMENTATION vendor ID
    Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received NAT-T (RFC 3947) vendor ID
    Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received draft-ietf-ipsec-nat-t-ike vendor ID
    Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received draft-ietf-ipsec-nat-t-ike-08 vendor ID
    Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received draft-ietf-ipsec-nat-t-ike-07 vendor ID
    Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received draft-ietf-ipsec-nat-t-ike-06 vendor ID
    Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received draft-ietf-ipsec-nat-t-ike-05 vendor ID
    Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received draft-ietf-ipsec-nat-t-ike-04 vendor ID
    Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
    Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received draft-ietf-ipsec-nat-t-ike-02 vendor ID
    Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
    Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received XAuth vendor ID
    Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received Cisco Unity vendor ID
    Aug 31 00:26:52 pfSense charon: 08[IKE] <12> received DPD vendor ID
    Aug 31 00:26:52 pfSense charon: 08[IKE] <12> 203.0.113.16 is initiating a Aggressive Mode IKE_SA
    Aug 31 00:26:52 pfSense charon: 08[IKE] <12> IKE_SA (unnamed)[12] state change: CREATED => CONNECTING
    Aug 31 00:26:52 pfSense charon: 08[CFG] <12> selecting proposal:
    Aug 31 00:26:52 pfSense charon: 08[CFG] <12>  no acceptable ENCRYPTION_ALGORITHM found
    Aug 31 00:26:52 pfSense charon: 08[CFG] <12> selecting proposal:
    Aug 31 00:26:52 pfSense charon: 08[CFG] <12>  no acceptable ENCRYPTION_ALGORITHM found
    Aug 31 00:26:52 pfSense charon: 08[CFG] <12> selecting proposal:
    Aug 31 00:26:52 pfSense charon: 08[CFG] <12>  proposal matches
    Aug 31 00:26:52 pfSense charon: 08[CFG] <12> received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
    Aug 31 00:26:52 pfSense charon: 08[CFG] <12> configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
    Aug 31 00:26:52 pfSense charon: 08[CFG] <12> selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
    Aug 31 00:26:52 pfSense charon: 08[CFG] <12> looking for XAuthInitPSK peer configs matching 203.0.113.17…203.0.113.16[76:70:6e:75:73:65:72:73:40:65:78:61:6d:70:6c:65:2e:63:6f:6d]
    Aug 31 00:26:52 pfSense charon: 08[CFG] <12>  candidate "bypasslan", match: 1/1/24 (me/other/ike)
    Aug 31 00:26:52 pfSense charon: 08[CFG] <12>  candidate "con1", match: 1/1/1052 (me/other/ike)
    Aug 31 00:26:52 pfSense charon: 08[CFG] <12> selected peer config "con1"
    Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>sending XAuth vendor ID
    Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>sending DPD vendor ID
    Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>sending FRAGMENTATION vendor ID
    Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>sending NAT-T (RFC 3947) vendor ID
    Aug 31 00:26:52 pfSense charon: 08[ENC] <con1|12>generating AGGRESSIVE response 0 [ SA KE No ID V V V V NAT-D NAT-D HASH ]
    Aug 31 00:26:52 pfSense charon: 08[NET] <con1|12>sending packet: from 203.0.113.17[500] to 203.0.113.16[500] (412 bytes)
    Aug 31 00:26:52 pfSense charon: 08[NET] <con1|12>received packet: from 203.0.113.16[32384] to 203.0.113.17[4500] (100 bytes)
    Aug 31 00:26:52 pfSense charon: 08[ENC] <con1|12>parsed AGGRESSIVE request 0 [ HASH NAT-D NAT-D ]
    Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>queueing XAUTH task
    Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>remote host is behind NAT
    Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>activating new tasks
    Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>activating XAUTH task
    Aug 31 00:26:52 pfSense charon: 08[ENC] <con1|12>generating TRANSACTION request 1000815079 [ HASH CPRQ(X_USER X_PWD) ]
    Aug 31 00:26:52 pfSense charon: 08[NET] <con1|12>sending packet: from 203.0.113.17[4500] to 203.0.113.16[32384] (76 bytes)
    Aug 31 00:26:52 pfSense charon: 08[NET] <con1|12>received packet: from 203.0.113.16[32384] to 203.0.113.17[4500] (92 bytes)
    Aug 31 00:26:52 pfSense charon: 08[ENC] <con1|12>parsed INFORMATIONAL_V1 request 3652027594 [ HASH N(INITIAL_CONTACT) ]
    Aug 31 00:26:52 pfSense charon: 08[NET] <con1|12>received packet: from 203.0.113.16[32384] to 203.0.113.17[4500] (92 bytes)
    Aug 31 00:26:52 pfSense charon: 08[ENC] <con1|12>parsed TRANSACTION response 1000815079 [ HASH CPRP(X_USER X_PWD) ]
    Aug 31 00:26:52 pfSense charon: user 'testuser' authenticated
    Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>XAuth-SCRIPT succeeded for user 'testuser'.
    Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>XAuth authentication of 'testuser' successful
    Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>reinitiating already active tasks
    Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>XAUTH task
    Aug 31 00:26:52 pfSense charon: 08[ENC] <con1|12>generating TRANSACTION request 1423147739 [ HASH CPS(X_STATUS) ]
    Aug 31 00:26:52 pfSense charon: 08[NET] <con1|12>sending packet: from 203.0.113.17[4500] to 203.0.113.16[32384] (76 bytes)
    Aug 31 00:26:52 pfSense charon: 08[NET] <con1|12>received packet: from 203.0.113.16[32384] to 203.0.113.17[4500] (76 bytes)
    Aug 31 00:26:52 pfSense charon: 08[ENC] <con1|12>parsed TRANSACTION response 1423147739 [ HASH CPA(X_STATUS) ]
    Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>IKE_SA con1[12] established between 203.0.113.17[203.0.113.17]…203.0.113.16[76:70:6e:75:73:65:72:73:40:65:78:61:6d:70:6c:65:2e:63:6f:6d]
    Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>IKE_SA con1[12] state change: CONNECTING => ESTABLISHED
    Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>scheduling reauthentication in 85592s
    Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>maximum IKE_SA lifetime 86132s
    Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>activating new tasks
    Aug 31 00:26:52 pfSense charon: 08[IKE] <con1|12>nothing to initiate
    Aug 31 00:26:52 pfSense charon: 12[NET] <con1|12>received packet: from 203.0.113.16[32384] to 203.0.113.17[4500] (172 bytes)
    Aug 31 00:26:52 pfSense charon: 12[ENC] <con1|12>unknown attribute type (28683)
    Aug 31 00:26:52 pfSense charon: 12[ENC] <con1|12>parsed TRANSACTION request 3279620505 [ HASH CPRQ(ADDR MASK DNS NBNS EXP VER U_BANNER U_DEFDOM U_SPLITDNS U_SPLITINC U_LOCALLAN U_PFS U_SAVEPWD U_FWTYPE U_BKPSRV (28683)) ]
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing INTERNAL_IP4_ADDRESS attribute
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing INTERNAL_IP4_NETMASK attribute
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing INTERNAL_IP4_DNS attribute
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing INTERNAL_IP4_NBNS attribute
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing INTERNAL_ADDRESS_EXPIRY attribute
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing APPLICATION_VERSION attribute
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing UNITY_BANNER attribute
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing UNITY_DEF_DOMAIN attribute
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing UNITY_SPLITDNS_NAME attribute
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing UNITY_SPLIT_INCLUDE attribute
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing UNITY_LOCAL_LAN attribute
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing UNITY_PFS attribute
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing UNITY_SAVE_PASSWD attribute
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing UNITY_FW_TYPE attribute
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing UNITY_BACKUP_SERVERS attribute
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>processing (28683) attribute
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>peer requested virtual IP %any
    Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>reassigning offline lease to 'testuser'
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>assigning virtual IP 172.25.240.1 to peer 'testuser'
    Aug 31 00:26:52 pfSense charon: 12[ENC] <con1|12>generating TRANSACTION response 3279620505 [ HASH CPRP(ADDR DNS) ]
    Aug 31 00:26:52 pfSense charon: 12[NET] <con1|12>sending packet: from 203.0.113.17[4500] to 203.0.113.16[32384] (92 bytes)
    Aug 31 00:26:52 pfSense charon: 12[NET] <con1|12>received packet: from 203.0.113.16[32384] to 203.0.113.17[4500] (300 bytes)
    Aug 31 00:26:52 pfSense charon: 12[ENC] <con1|12>parsed QUICK_MODE request 3949526512 [ HASH SA No ID ID ]
    Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>looking for a child config for 0.0.0.0/0|/0 === 172.25.240.1/32|/0
    Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>proposing traffic selectors for us:
    Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>0.0.0.0/0|/0
    Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>proposing traffic selectors for other:
    Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>172.25.240.1/32|/0
    Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>candidate "con1" with prio 5+5
    Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>found matching child config "con1" with prio 10
    Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>selecting traffic selectors for other:
    Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>config: 172.25.240.1/32|/0, received: 172.25.240.1/32|/0 => match: 172.25.240.1/32|/0
    Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>selecting traffic selectors for us:
    Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>config: 0.0.0.0/0|/0, received: 0.0.0.0/0|/0 => match: 0.0.0.0/0|/0
    Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>selecting proposal:
    Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>proposal matches
    Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_MD5_96/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_MD5_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_MD5_96/NO_EXT_SEQ
    Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_192/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_192/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ
    Aug 31 00:26:52 pfSense charon: 12[CFG] <con1|12>selected proposal: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>received 3600s lifetime, configured 28800s
    Aug 31 00:26:52 pfSense charon: 12[ENC] <con1|12>generating QUICK_MODE response 3949526512 [ HASH SA No ID ID ]
    Aug 31 00:26:52 pfSense charon: 12[NET] <con1|12>sending packet: from 203.0.113.17[4500] to 203.0.113.16[32384] (172 bytes)
    Aug 31 00:26:52 pfSense charon: 12[NET] <con1|12>received packet: from 203.0.113.16[32384] to 203.0.113.17[4500] (60 bytes)
    Aug 31 00:26:52 pfSense charon: 12[ENC] <con1|12>parsed QUICK_MODE request 3949526512 [ HASH ]
    Aug 31 00:26:52 pfSense charon: 12[CHD] <con1|12>using AES_CBC for encryption
    Aug 31 00:26:52 pfSense charon: 12[CHD] <con1|12>using HMAC_SHA1_96 for integrity
    Aug 31 00:26:52 pfSense charon: 12[CHD] <con1|12>adding inbound ESP SA
    Aug 31 00:26:52 pfSense charon: 12[CHD] <con1|12>SPI 0xc19b6efc, src 203.0.113.16 dst 203.0.113.17
    Aug 31 00:26:52 pfSense charon: 12[CHD] <con1|12>adding outbound ESP SA
    Aug 31 00:26:52 pfSense charon: 12[CHD] <con1|12>SPI 0x0e287f59, src 203.0.113.17 dst 203.0.113.16
    Aug 31 00:26:52 pfSense charon: 12[IKE] <con1|12>CHILD_SA con1{8} established with SPIs c19b6efc_i 0e287f59_o and TS 0.0.0.0/0|/0 === 172.25.240.1/32|/0

    Works with Group 14 in the Phase 1, too:

    Aug 31 00:39:35 pfSense charon: 08[IKE] <15> IKE_SA (unnamed)[15] state change: CREATED => CONNECTING
    Aug 31 00:39:35 pfSense charon: 08[CFG] <15> selecting proposal:
    Aug 31 00:39:35 pfSense charon: 08[CFG] <15>  proposal matches
    Aug 31 00:39:35 pfSense charon: 08[CFG] <15> received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
    Aug 31 00:39:35 pfSense charon: 08[CFG] <15> configured proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
    Aug 31 00:39:35 pfSense charon: 08[CFG] <15> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048</con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12></con1|12>



  • 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.


  • Banned

    @Derelict:

    I just built this…again...loosely following this: https://doc.pfsense.org/index.php/IPsec_Road_Warrior/Mobile_Client_How-To

    Worked fine.

    I have been unable to duplicate the behavior you describe.

    .....

    Works with Group 14 in the Phase 1, too:

    Aug 31 00:39:35 pfSense charon: 08[IKE] <15> IKE_SA (unnamed)[15] state change: CREATED => CONNECTING
    Aug 31 00:39:35 pfSense charon: 08[CFG] <15> selecting proposal:
    Aug 31 00:39:35 pfSense charon: 08[CFG] <15>  proposal matches
    Aug 31 00:39:35 pfSense charon: 08[CFG] <15> received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
    Aug 31 00:39:35 pfSense charon: 08[CFG] <15> configured proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
    Aug 31 00:39:35 pfSense charon: 08[CFG] <15> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048

    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!


  • Banned

    @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.


  • Netgate

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


  • Netgate

    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.


  • Banned

    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!


  • Banned

    @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?



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


  • Netgate

    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.


  • Banned

    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?


  • Banned

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