That’s not a “feature” or an “option”, that’s a service - the vendor must run these servers somewhere, which generates some expenses.
But there is a way you can use instantly: when IPsec is using IKEv2 mode and at least one NAT is present in the path between the peers, a single bi-directional UDP flow between the peers is used to carry all the traffic, the control session as well as the transport packets. As UDP has got no notion of an initial session negotiation (like TCP has), the firewalls and NATs cannot check the traffic too deeply, and thus they can be tricked into letting the connection through if both endpoints act in accord. The idea relies on the usual behaviour of most contemporary NATs which do not change the source port unless they need to do so because a connection from that source port to the same remote IP and port already exists; if one of the NATs on the path between your devices behaves different, this solution won’t work.
So what you need to do is the following:
- activate some kind of Dynamic DNS service at both machines. The service must store the public IP from which the update requests are coming even if they are coming from a device behind a NAT. Mikrotik’s “ip cloud” is one example of such a service, with an fqdn generated from the unit’s serial number. To find the serial number, use
:put [/system routerboard get serial-number] - on each router, add an address list item with the other router’s fqdn as the address item. RouterOS will keep resolving the fqdn to the current address based on the record lifetime reported by the DNS system:
/ip firewall address-list add list=remote-peer address=serial-number-of-the-remote-machine.sn.mynetname.net
Check that the address list shows also a dynamically created item with the current public IP of the remote device as address. - randomly choose two numbers between 16384 and 65534, to be used as local port numbers at each of the two peers. The thing is that normally, both peers use a local port 4500, so there is a small chance that someone else is running an IPsec connection through the same two NAT devices; by using randomly chosen ports instead, you reduce the chance that you’d collide with someone else doing the same. I’ll use LLLLL for the port on the local machine and RRRRR for the port on the remote machine (you create two symmetric configurations so the LLLLL value in one of them is used as RRRRR value on the other one).
- as in RouterOS you cannot change the local port which the IPsec stack uses, you have to use both src-nat and dst-nat rules to translate 4500 to the chosen local port at the uplink interface:
/ip firewall nat
add chain=srcnat out-interface=your-wan dst-address-list=remote-peer protocol=udp src-port=4500 dst-port=RRRRR action=masquerade to-ports=LLLLL
add chain=dstnat in-interface=your-wan src-address-list=remote-peer protocol=udp src-port=RRRRR dst-port=LLLLL action=dst-nat to-ports=4500 - create a site-to-site IPsec VPN with exchange-mode=ike2. The /ip ipsec peer row at each machine must be configured with passive=no, address=serial-number-of-the-remote-machine.sn.mynetname.net, and port=RRRRR)