On 2016-01-03, Julian Hsiao <mad...@nyanisore.net> wrote: > On 2016-01-02 13:18:15 +0000, Stuart Henderson said: > >> See isakmpd.policy(5). It's an utter pain but it's necessary in order to >> secure things with isakmpd. > > Right, I eventually figured that out by having isakmpd dump out the > isakmpd.conf(5) equivalent config. Turns out "ike passive [...]" is > transformed into "Passive-connections", and in isakmpd.conf(5): > > Passive-connections > A list of IPsec "connection" names we recognize and accept initiations > for. [...] Currently only the Local-ID and Remote-ID tags are looked at > in those sections, as they are matched against the IDs given by the > initiator. > > Meaning that the Configuration parameter, which links to the remaining > phase 2 options, are totally ignored! > > FWIW, I worked out that the following policy will (mostly) enforce the > phase 2 parameters I wanted: > > Authorizer: "POLICY" > Conditions: app_domain == "IPsec policy" && > esp_auth_alg == "hmac-sha2-256" && > esp_enc_alg == "aes" && > esp_group_desc == "18" && > pfs == "yes" -> "true"; > > This is a pretty serious gotcha with using ipsecctl(8) / ipsec.conf(5) > IMO, especially since the latter suggests you run isakmpd with -K > option.
Yes, it's a big and nasty gotcha. >> The other "fun" thing a client can do if it's >> not restricted by keynote policy is to set "their" side of the tunnel to >> something which diverts the wrong traffic - 0.0.0.0/0 is an obvious >> example but rather unsubtle. > > I'm not sure I completely follow. Do you mean that the client has > "from any to $SERVER_IP" instead of "from $CLIENT_IP to $SERVER_IP", > resulting the client routing all its traffic to the server? Exactly. The traffic can be controlled with PF (allowing to to prevent a malicious client from actually seeing it), but once it has been 'abstracted' by the IPsec flow it can't be sent back to the proper destination. > Incidentally, do you know if iked(8) (IKEv2) suffers from similar gotchas? Unsure, I can't use iked(8) in the normal places I use IPsec, iked sends UDP packets without binding, often resulting in it using the wrong source IP address on a multihomed host - and in other places I need IKEv1+L2TP for some connections so I am stuck with only being able to use isakmpd. I suspect iked is better than isakmpd at requiring a specific mode without complex config, but I don't see how to configure it to restrict subnets unless you know the IP address of the peer at all, whereas with isakmpd it is there (though needs arcane knowledge to use it). I'm not a fan of keynote but one way or another there needs to be some way to feed in information about the connection and (certificate|psk) into some configurable logic that allows a decision to be made whether to allow it to succeed. As mentioned above, PF isn't enough for this as IPsec is flow-based on OpenBSD, and even if it was route-based, really the connection should be rejected rather than just blocking packets - and keynote does provide a way to do this. A lesser but still important issue with ipsec.conf(5), and I think it's the same for iked.conf(5), is that you can't do things like "allow either AES or 3DES" - this is supported by isakmpd.conf and is useful if you have various clients on dynamic IPs, some of which support AES which you'd like them to use if possible, and others which only support 3DES.
