There are multiple things to deal with. The explanation below assumes that you use some kind of controlled WAN failover or load distribution and thus you are familiar with the concept of “policy routing” and additional routing tables. If it is not the case, the forum has numerous topics discussing that - this is just one of them.
- the XXXXXXXXXXX.sn.mynetname.net can always only resolve to a single IP address. So
- if both addresses are dynamic and you want to use both for incoming VPN connections, you need some other dynamic DNS service to resolve some other FQDN to the other WAN address (and a script that will notify it about the address changes).
- if you want XXXXXXXXXXX.sn.mynetname.net to resolve to the IP address of a WAN that is not the out-interface of the default route, you have to use mangle rules to let the router talk to Mikrotik cloud via the other WAN, something like:
/ip firewall address-list add list=mt-cloud address=cloud2.mikrotik.com
/ip firewall mangle add chain=output dst-address-list=mt-cloud action=mark-routing new-routing-mark=via-wanX
(you may want to find out which protocol and port are used for the DDNS update and make the mangle rule match on them so that the primary WAN would be used for RouterOS updates).
- if you want XXXXXXXXXXX.sn.mynetname.net to resolve to the IP address of a WAN that is not the out-interface of the default route, you have to use mangle rules to let the router talk to Mikrotik cloud via the other WAN, something like:
- you have to make the router send response (upstream) packets of a given connection through the same WAN through which the request (downstream) packets of that connection come in. If it is sufficient that this was the case for packets the router sends itself (like when it acts as a VPN server), you can make use of the fact that the router responds from the same own address on which it has received the request, so a routing rule that says src-address=ip.of.wan.X action=lookup-only-in-table table=via-wanX is sufficient. If you also use dst-nat rules to make services running on servers in LAN accessible from the internet, you need to use connection marking to allow the router to forward the responses from the servers via the “proper” WAN, as described in the topic I’ve mentioned above.
- you have to add the other FQDN to the certificate (as another SAN item) if you want to use a common IPsec peer for both WANs, because the only way the IPsec stack could choose a specific certificate for each WAN would be to create two peers, each attached to another static local-address, and use dst-nat rules to redirect the incoming request to one of them depending on in-interface.