That’s it. Not everybody have an static IP, and we can’t use machine names (my.peer.com) with IPsec, on the peers tab. Time and again we see someone asking how to do it, or sharing a script to this end.
So. Name resolution, in the peer address field?
The underlying software does not support that. It requires a numeric IP.
So the scripts are the way to go for now. (until version 7 solves all possible problems we can ever imagine)
Sure, this is just a question of resolving the address, before processing? Let the user insert the FQDN. When the time to process the rule comes, resolve the address, and use the IP for the duration of the connection.
If the IP changes, the connection will be broke, and the rules reprocessed.
Rinse, repeat.
Yes all very fine but racoon cannot do it.
So you need to wait until patches are written or a new start is made using different software.
You should understand that RouterOS is Linux plus a number of free software tools plus the MikroTik-written configuration interface and software.
It has been claimed since 2012 that large parts of the free software tools will be replaced by newly written, more capable, software in RouterOS version 7.
But as of today there is not even an alpha version on the download servers, although in the past week there seem to be some hints that it exists.
The solution already exists, in the form of “address list”. It queries the DNS, and get the IP address. No need to touch the IPSEC software stack - just change the Mikrotik shell around it, enough to use this.
At the end of the day, it will be just a placeholder to the $ADDRESS returned by address list. The IPSEC software will still see just an IP.
Again, racoon cannot do it.
It wires up a fixed table of policies and peers and does not change them when traffic is flowing.
It would have to be patched to do some external lookup once the peer address is required.
You should understand the difference between features that are in the user interface that is used to compile the configuration
for the underlying software, and features that are performed by the underlying software itself.
You will find that most of the quickly-added features are in the top layer of the software.
Requesting features that require modification in lower level software takes longer or never happens, and of course it endangers
future development. (all patches made to external software make it more difficult to just update everything to the latest release
and ship a new, enhanced RouterOS)
Also, note that changes like this are not without risk. Doing lookups in DNS requires a functional network that can
reach the DNS, and in certain situations this may only be available after IPsec tunnels have come up. It is easy to introduce
a circular dependency.
The fixed tables are wired up AFTER a request is accepted. The software understands only IP in his config files - but the config files are created by the shell Mikrotik wrapped up around this. I am not suggesting to change the way racoon works. I am saying it would be possible to change the way the Mikrotik shell stores the config. Racoon has nothing to do with it - it comes later in the process.
At the very worst, the system could do a DNS lookup, BEFORE sending the configuration to racoon, and feeding it just the IP. Use the TTL to find out when another DNS query would be needed. There. Problem solved, without touching racoon.
Yes, this is a risk. But it doesn’t matter: your your peer has dynamic IP, you need DNS. The situation you described would fail, that is true. But it would fail all the same with the current possibilities. So…
The fixed tables are wired up AFTER a request is accepted. The software understands only IP in his config files - but the config files are created by the shell Mikrotik wrapped up around this. I am not suggesting to change the way racoon works. I am saying it would be possible to change the way the Mikrotik shell stores the config. Racoon has nothing to do with it - it comes later in the process.
At the very worst, the system could do a DNS lookup, BEFORE sending the configuration to racoon, and feeding it just the IP. Use the TTL to find out when another DNS query would be needed. There. Problem solved, without touching racoon.
[/quote]
I expect with this “solution” it would take only 5 seconds and people would complain that it does the DNS lookup when configuring but not again when it has changed.
Cisco has a lot of this “solution” in its config: you can enter a DNS name at many places but when you later print your config it has been replaced by the literal IP address that was valid at the time you entered the command.
Nice for entering addresses (especially IPv6) but I think this is not what the typical MikroTik user would expect.
When you make it lookup again and again you are requiring an active process and also cleverness to detect that the address has changed.
It is a solution, not a “solution”. It is, already, used by Mikrotik itself. Create an L2TP server. Mark the “Use IPsec” option. There, the behavior I described. Dynamic rules, created using the IP address that the DNS spit at the time. Change de address, the rule change. I just proposed inserting it at the IPsec config options. Due to flexibility reasons.
What would a “typical Mikrotik user” expect? What I see on this forum is a quite diverse group - from hardened professionals to novice home users. Do You really know what everybody wants?
Well, I know what I want. My Ip is dynamic, and I want to be able to host an IPsec server. I also know how to do it, using features already available elsewhere on the Mikrotik interface.
And, yes. I am requiring cleverness to find out a change in address. It is already deployed - in “address list”! Is is already done! Just change the filed “peer ip” by a placeholder, pointing to “$address_list”. Include the ability to reload the rule, when the address change. There, done.
It is, after all, what the scripts do.
There is a bug difference between “client” use like in L2TP client and “symmetrical” use like in “IPsec tunnels”.
The difference is that in the client case the lookup is done at the time the interface is brought up and PPP login is to be attempted, while
in the tunnel case the rule has to be there all the time waiting for potential traffic from the peer.
So there is no local event that is triggering the lookup.
Anyway, in the 6.41RC version there has been some change towards what you would like to have, but it is not
a full solution that works for symmetric IPsec as well. But maybe it is useful to you.
You don’t need an event: you just look it up when validating the rule. Easy as this. The problem is that you keep trying to insert the logic in the racoon. My sugestion is to insert the logic in the Mikrotik wrapper. The DNS lookup will be done before the rule is coded into config. To the IPsec service there would be no difference at all.
I’ll take a look at 6.41RC. Thanks for the info. 
That’s EXACTLY what I wanted! They put it in 6.41RC28! Great, thanks for pointing me to this!