Hi Philipp, Thank you - this was exactly what I was missing. I have now gotten it to work by excluding hmac-sha2-256 (and therefore falling back to hmac-sha1), which strongly suggests my Nexus 6P (all patched) doesn't implement hmac-sha2-256 correctly.
The irony is that the manpage of isakmpd.policy explains all this excellently, but I didn't read it because I misunderstood what the manpage of ipsec.conf says: "The keying daemon, isakmpd(8), can be enabled to run at boot time via the isakmpd_flags variable in rc.conf.local(8). Note that it will probably need to be run with at least the -K option, to avoid keynote(4) policy checking." I read this as meaning that keynote policy checking is *always* unwanted when ipsecctl is used, and that you can avoid policy checking either by not having a policy file at all (in which case the -K option doesn't matter), or by using the -K option (in which case it's certain that policy checking never happens). But now I know better. :) Thanks, Jurjen 2017-03-20 9:33 GMT+01:00 Jurjen Oskam <jur...@osk.am>: > Hi Philipp, > > Thank you - this was exactly what I was missing. I have now gotten it to > work by excluding hmac-sha2-256 (and therefore falling back to hmac-sha1), > which strongly suggests my Nexus 6P (all patched) doesn't implement > hmac-sha2-256 correctly. > > The irony is that the manpage of isakmpd.policy explains all this > excellently, but I didn't read it because I misunderstood what the manpage > of ipsec.conf says: "The keying daemon, isakmpd(8), can be enabled to run > at boot time via the isakmpd_flags variable in rc.conf.local(8). Note that > it will probably need to be run with at least the -K option, to avoid > keynote(4) policy checking." I read this as meaning that keynote policy > checking is *always* unwanted when ipsecctl is used, and that you can avoid > policy checking either by not having a policy file at all (in which case > the -K option doesn't matter), or by using the -K option (in which case > it's certain that policy checking never happens). > > But now I know better. :) > > Thanks, > > Jurjen > > > 2017-03-20 6:08 GMT+01:00 Philipp Buehler <e1c1bac6253dc54a1e89ddc046585 > 7...@posteo.net>: > >> Am 19.03.2017 15:36 schrieb Jurjen Oskam: >> >> So, to validate that I'm indeed hitting this bug (and also as a >>> workaround) >>> I tried to set up the OpenBSD side to not use SHA2. I haven't been able >>> to >>> get this running yet: isakmpd always seems to offer HMAC_SHA2_256. >>> >> >> It's not offering that - but accepting "better" Phase2 transforms. If >> isakmpd >> would start the negotiation, it'd propose HMAC_SHA. >> >> To keep out unwanted proposals, you need an isakmpd.policy. (hint: no -K) >> >> In my eyes this is 'bad behaviour' and tends to lead to situations where >> e.g. >> a remote end "upgrades" (and locks down) the transforms and thus rekeying >> started by isakmpd start to fail. >> >> HTH, >> -- >> pb
