On 2022-02-18, [email protected] <[email protected]> wrote:
> On Fri, Feb 18, 2022 at 11:43 AM I wrote:
>> I recently started seeing some ipsec clients fail on newer versions of
>> MacOS and iOS. After MacOS 12.1, connecting to my head end now fails
>> with NO_PROPOSAL_CHOSEN using mod1024 in my ipsec.conf. I've also
>> tried, with no success:
>>
>> main auth "hmac-sha2" enc "aes" group modp1024
>> quick auth "hmac-sha2" enc "aes" group modp1024
>
> Doing further research shows things are just not working out.
>
> I added two different configs that should match in /etc/ipsec.conf
>
> ike passive esp transport proto udp from $public_ip to any \
> main auth "hmac-sha2-256" enc "aes-256" group "modp2048" \
> quick auth "hmac-sha2-256" enc "aes-256" group "modp2048" \
> psk "THIS_IS_MY_IPSEC_PASSPHRASE"
>
> ike passive esp transport proto udp from $public_ip to any \
> main auth "hmac-md5" enc "3des" group "modp1024" \
> quick auth "hmac-md5" enc "3des" group "modp1024" \
> psk "THIS_IS_MY_IPSEC_PASSPHRASE"
With isakmpd and ipsec.conf you can't have two proposals for the default
("to any") peer with different PFS groups, you will have to choose one
or the other. As-is the second will overwrite the first config block.
(Use ipsecctl -v to see the commands sent by ipsecctl to isakmpd;
it generates what are basically isakmpd.conf style config blocks and
sends them over the control socket).
There is a chance that by writing your own isakmpd.conf you might be
able to have two main mode (phase 1) proposals with differing groups,
but for quick mode it's a protocol limitation and it's only possible to
send one - and I don't think isakmpd can let you choose what to send in
phase 2 depending on what was used for phase 1. It will still be painful
though.
You will save yourself a lot of trouble if you can move the newer machines
to IKEv2 .. (It would not be possible to run both isakmpd and iked on a
single OpenBSD machine though). Or alternatively wireguard or openvpn
(which _can_ coexist with IKEv1) though IKEv2 generally has a simpler
client config.
> Running a packet capture on the server shows that both of these
> proposals are being sent by the client and should match in isakmpd.
> Alas, they do not.
>
> Here's the pcap -- again, thanks in advance for any assistance.
>
> server# tcpdump -nvvs 16000 -i em0 src host 100.64.10.10 and port 500
> 13:14:50.662540 64:9e:f3:XX:XX:XX 52:54:00:XX:XX:XX 0800 830:
> 100.64.10.10.63823 > 203.0.113.1.500: [udp
> sum ok] isakmp v1.0 exchange ID_PROT
> cookie: 197d16ba79870fd2->0000000000000000 msgid: 00000000 len: 788
> payload: SA len: 516 DOI: 1(IPSEC) situation: IDENTITY_ONLY
> payload: PROPOSAL len: 504 proposal: 1 proto: ISAKMP
> spisz: 0 xforms: 14
> payload: TRANSFORM len: 36
> transform: 1 ID: ISAKMP
> attribute LIFE_TYPE = SECONDS
> attribute LIFE_DURATION = 3600
> attribute ENCRYPTION_ALGORITHM = AES_CBC
> attribute KEY_LENGTH = 256
> attribute AUTHENTICATION_METHOD = PRE_SHARED
> attribute HASH_ALGORITHM = SHA2_256
> attribute GROUP_DESCRIPTION = MODP_2048
> [..]
> payload: TRANSFORM len: 32
> transform: 14 ID: ISAKMP
> attribute LIFE_TYPE = SECONDS
> attribute LIFE_DURATION = 3600
> attribute ENCRYPTION_ALGORITHM = 3DES_CBC
> attribute AUTHENTICATION_METHOD = PRE_SHARED
> attribute HASH_ALGORITHM = MD5
> attribute GROUP_DESCRIPTION = MODP_1024
> [..]
> 13:14:50.667404 52:54:00:XX:XX:XX 64:9e:f3:XX:XX:XX 0800 82:
> 203.0.113.1.500 > 100.64.10.10.63823: [bad udp cksum 1608! -> 2224]
> isakmp v1.0 exchange INFO
> cookie: 3cbfd92c4ea7626d->0000000000000000 msgid: 00000000 len: 40
> payload: NOTIFICATION len: 12
> notification: NO PROPOSAL CHOSEN (ttl 64, id 48652, len 68)
> [..]
>
>
--
Please keep replies on the mailing list.
