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.
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?
Incidentally, do you know if iked(8) (IKEv2) suffers from similar gotchas?
Thanks.
Julian Hsiao
