I'm experiencing some issues with iked(8) and the first one took
me much longer than appreciated: order of commands matters.
ikev2 passive esp \
proto gre \
from A to B \
local any peer any
But switching `proto' and `inet' breaks it, not reporting any further
I ran into the broken config in the first place, tried a few iterations
and finally removed `proto' to "unbreak" it, thinking this particular
command was broken in general.
Since fixing parse.y is another journey I'm currently not up for, the
BUGS section seems appropiate until order is truly irrelevant.
RCS file: /cvs/src/sbin/iked/iked.conf.5,v
retrieving revision 1.61
diff -u -p -r1.61 iked.conf.5
--- iked.conf.5 10 Feb 2020 13:18:20 -0000 1.61
+++ iked.conf.5 14 Feb 2020 19:48:38 -0000
@@ -1006,3 +1006,5 @@ The
.Xr iked 8
program was written by
.An Reyk Floeter Aq Mt [hidden email] .
+Commands must be specified in the same order as documented.
On Fri, Feb 14, 2020 at 08:56:25PM +0100, Klemens Nanni wrote:
> I'm experiencing some issues with iked(8) and the first one took
> me much longer than appreciated: order of commands matters.
iked/iked.conf is not special, ipsecctl/ipsec.conf obviously has it, too.
So while the problem of undocumented order does exist, I no longer think
BUGS is the right place for it. Either ways, all effected tools ought
to be fixed, not just iked.
pfctl/pf.conf for example does expect a certain order of keywords as
well, yet it provides syntax in BNF which rules out any ambiguity.