Hi folks,

In the 6.40rc11 changelog we have this entry:

ipsec - allow to specify remote peer address as DNS name (CLI only);

That is, it is now possible to say: But if I say a DNS name for sa-dst-address=, the CLI gives me an error:
So, how do I create a matching policy?

same here
+1

Mee too
+1

Sorry if it's stupid idea, but do we need sa-src-address and sa-dst-address options at all? Couldn't policies be simply linked to peer from "/ip ipsec peer" instead? Maybe I'm forgetting some advanced usage, but for all I ever used, it was always sa-src-address=<local-address from peer> and sa-dst-address=<address from peer> anyway. Even if it wouldn't work for all scenarios, it could be nice as option.

Then there would have to be some linkage between "policy" and "peer", currently this is only there in the form of the SA addresses.
When there would be a reference in "policy" to e.g. a "peer name", that could then fill the SA addresses internally in RouterOS.

Note that this is already possible, when you use "generate policy" in the "peer" definition. But of course its usage is limited to
a policy between the SA addreses only, and for a specified set of protocols. But, it still works when you use IPsec as transport
below another tunneling protocol (GRE, IPIP, L2TP). I recommend that anyway, over trying to use IPsec tunnel to send traffic
for specified subnets.

Sorry if it's stupid idea, but do we need sa-src-address and sa-dst-address options at all?

That's all tied to how IPsec works behind the scene.

For L2L tunnels, policies are expected to come into the game first, and are used to find a proper SA. And only in case there's no established SA, a peer configuration is searched for, and then an ISAKMP or IKEv2 exchange is initiated based on the peer configuration found. Using DNS names in policies in such scenario is not really an option.

For road-warrior-like scenarios, however, a client is usually initiates ISAKMP or IKEv2 connection first. When phase 1 is established, one of the parties initiate phase 2 exchange, at which point both parties generate and install dynamic policies. And this is where the ability to specify peer address as an FQDN instead of IP address comes in handy. For this scenario policy templates are supposed to be used instead of predefined policies, so the ability to specify sa-src-address and sa-dst-address as DNS names is not needed either.

And of course the second setup can also be used for L2L tunnels when necessary.

It is actually possible to get a viable IPsec lan2lan tunnel configuration working with dynamic address.
I did this in a plain Linux system. The racoon program can start a script whenever phase1 is established, and this can be used to
fixup the phase2 policy SA address. This is done at the "server" site. At the dynamic address site the policy can be fixed by
a script running when the dynamic address is determined or changes at the "client" site.
At the moment, RouterOS does not yet allow running a script on phase1 establishment. It could be added.
With this support it is also possible to make GRE/IPsec and IPIP/IPsec tunnels work with dynamic address.

+1

That's all tied to how IPsec works behind the scene.

For L2L tunnels, policies are expected to come into the game first, and are used to find a proper SA. And only in case there's no established SA, a peer configuration is searched for, and then an ISAKMP or IKEv2 exchange is initiated based on the peer configuration found. Using DNS names in policies in such scenario is not really an option.

I understand that there may be limitations, but I believe it must be possible somehow to link peers and policies to eachother.
If policies can't be tied to peers (because of the reason you specify), then perhaps it's possible by link peers to policies (the other way around)?
Either way: in most other VPN-capable devices, it's possible to link the policy to the peer somehow.