From: Noel Kuntze Date: Mon, 13 Mar 2017 15:26:10 +0000 (+0100) Subject: swanctl: Reformulate IKEv1 selector restriction, describe problems with TS narrowing X-Git-Tag: 5.5.2~15 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=693107f6aeae523ff2b4e9db05143a355d8a5a7c;p=thirdparty%2Fstrongswan.git swanctl: Reformulate IKEv1 selector restriction, describe problems with TS narrowing --- diff --git a/src/swanctl/swanctl.opt b/src/swanctl/swanctl.opt index 142a271709..bdd92177ff 100644 --- a/src/swanctl/swanctl.opt +++ b/src/swanctl/swanctl.opt @@ -664,9 +664,16 @@ connections..children..local_ts = dynamic value _opaque_ for RFC 4301 OPAQUE selectors. Port ranges may be specified as well, none of the kernel backends currently support port ranges, though. - Unless the Unity extension is used, IKEv1 supports the first specified - selector only. IKEv1 uses very similar traffic selector narrowing as it is - supported in the IKEv2 protocol. + When IKEv1 is used only the first selector is interpreted, except if + the Cisco Unity extension plugin is used. This is due to a limitation of the + IKEv1 protocol, which only allows a single pair of selectors per CHILD_SA. + So to tunnel traffic matched by several pairs of selectors when using IKEv1 + several children (CHILD_SAs) have to be defined that cover the selectors. + + The IKE daemon uses traffic selector narrowing for IKEv1, the same way it is + standardized and implemented for IKEv2. However, this may lead to problems + with other implementations. To avoid that, configure identical selectors in + such scenarios. connections..children..remote_ts = dynamic Remote selectors to include in CHILD_SA.