On Sat, Feb 22, 2020 at 01:47:35PM +0100, Klemens Nanni wrote: > On Sat, Feb 22, 2020 at 01:18:13PM +0100, Tobias Heider wrote: > > It seems I was mistaken because I usually use IPs in local > > and peer. What I said is true for IPs. When using > > FQDNs for local/peer however, iked first does the name > > resolution and then uses the IP as default dstid value > > to lookup the key... > > > > I still think using the actual value of peer would be the > > better dstid default, so maybe we should fix it in the > > code. What do you think? > Rereading the manual: > > If srcid is omitted, the default is to use the hostname of the > local machine, see hostname(1) to set or print the hostname. > > dstid is similar to srcid, but instead specifies the ID to be used > by the remote peer. > k > So `srcid' is a string (hostname), but what does `dstid' default to? > `peer' can be "any": what then? > > About `peer', the manual says > > [...]. If it is not specified or if the keyword any is > given, the default peer is used. > > What is "the default peer"?
No idea what the default peer is supposed to mean. > I'd expect `dstid' to always use the literal value of `peer' unless it > is "any", in which case I am not sure; perhaps require `dstid' to be > set explicitly? Peer can not be "any" in an active policy, somehow the initiator must know where to send the messages. In this case the default currently is what I've described before: the IP of peer. In a passive policy the key is only needed when the peer's ID has been exchanged in the IKE_AUTH message, so (I think) the default is to use whatever ID was received. I think this works pretty well in 90% of the cases and I've always been a fan of a short default configuration, so i don't think requiring to set dstid is a good idea. We should rather fix the defaults to do what we expect them to do. In your example case that would be using fqdn/D.example.com
