I just purchased and began configuring an upgraded router/switch (going from RB750GL to hAP AC2). I initially tried backing up the current config and then restoring to the new - that went horribly. Probably totally due to my own ignorance and external cabling factors - but I digress. I now have the new unit setup as basically a switch behind the old. The RB750GL has been providing IPSEC services to a few remotes.
I want to slowly transition to the new router - testing as I go. I’ve setup new certificates on the hAP and pushed the certs out to the remotes. But now…I’m not sure how to proceed. There’s one remote that I have an alternative path to - so if I kill the IPSEC I’ll still be able to get into it. But I don’t know how to forward IPSEC from my external router to the new internal one. Is that actually possible?
If the new one is currently set up as just a LAN host of the old one, the only thing you need to move the IKEv2 connections from the old one to the new one is to set up port forwarding of incoming traffic to UDP port 4500 to the LAN address of the new one: /ip firewall nat add chain=dstnat in-interface=your-wan-interface-name dst-address-type=local protocol=udp dst-port=4500 action=dst-nat to-addresses=ip.of.hap.ac²
(depending on the rest of your firewall settings, you may or may not need a dedicated action=accept rule in /ip firewall filter to permit the port-forwarded traffic).
As there is NAT between the peers, the ESP transport packets will get encapsulated into UDP ones and come in the same UDP flow as the control (IKEv2) ones. If some of your remote peers are Windows machines, you may need a slightly more complex setup - but I’m not sure whether Windows are that picky about an IKEv2 server too, so maybe it will work without that trick.
To switch over from “old” to “new” IPsec tunnels, it is enough to disable all the peers on the old machine and clean up all related connections on its firewall (the NAT rules only affect new connections, existing ones continue unchanged): /ip firewall connection remove [find dst-address~“:4500$”]
To switch back to “old” tunnels, you have to disable the peers at the new 'Tik, enable them at the old one, and clean up the connections again, for the same reason. So there is no need to worry about permanently losing access to the remote peers.
I’d definitely start from having the CA certificate of the old machine imported to the new one, so that it would accept the remote peers’ certificates signed by the old machine; after completing the migration, you may switch to using the certificates signed by the new machine on the remote peers, as this is the point where you may lose access. So I’d definitely schedule a script to switch back to the old certificate in 10 minutes, switch manually to the new certificate, and if the tunnel re-connects, remove the schedule and the script. An even better possibility is to set up an SSTP VPN in parallel to the IPsec one, which is sufficient for management access and simple enough to set up (you can use the same certificates).