PfSense 2.3.2 fails with macOS 10.11.6 native Cisco-style VPN client (IKE v1)
-
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> -
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.
-
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)
-
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_1024None 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.
-
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_1024None 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.
-
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): Off3. 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/78046. 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?
-
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/HT206154Apparently (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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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|/0Works 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.
-
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_2048Derelict,
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!