Greetings,    If you are still running into the issue, I would suggest contacting support and/or opening a case so that we can attempt a recreate and investigate further.  ... View more

Greetings,   The 1:M NAT feature may be the answer you are looking for. Please review the document below and let us know if you have questions or concerns!   https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX#1:Many_NAT   As always, please don't hesitate to reach out to support and open a case if any other issues arise.  ... View more

Greetings,   There is currently no way to extend the timers on the MXen, and I would suggest submitting a feature request so that it may be developed in the future, since even if there was a way to do this outside of the dashboard, it would be untested, atypical, finicky, unavailable for you to modify, and probably cause a load of other problems.  ... View more

Greetings,   This would not be a support configuration option on the MX since the general idea is that we treat VPN endpoints as point-to-point connections so anything outside of that, we cannot route to.   Another example is there you cannot forward traffic from an auto-VPN spoke, to a non-Meraki VPN peer.    Having said that, there might be some options here. If you cannot send it to the spoke MX public IP and forward it from there, then maybe we can use a proxy or another L3 switch/device that has its routable SVI in the local subnet of the MX, and the MX can ARP and port forward / NAT to that IP. The L3 switch/device must then send the traffic to the server across the spoke and that should work since from the MX's perspective, that's local traffic that can be routed.   Please let us know if you have any questions, and please don't hesitate to contact support if you need assistance in setting and testing this.  ... View more

Greetings,   There is no known caveat with Fortigate when it comes to tunnel negotiations but the MXen generally act as a responder with most peers so this should absolutely work.    If a tunnel is down, then the MX can be forced to be an initiator by attempting to send over interesting traffic to the peer's subnet.    If this does not seem to be the case or if it's not working as expected, please open a support case for further investigation. Please let us know if you have any questions.  ... View more

Greetings, It is possible that some existing traffic hasn't failed over solely with the configuration changes. Some traffic, especially sensitive traffic like voice/video calls or some streaming services for example, might not failover since that would break the connection completely.    I would suggest testing with a new client, or at least a client that has been disconnected for at least five minutes from the network and then testing again. After that, if possible, I would physically disconnect WAN 1 to force the traffic to failover.   If some IPv4 traffic still egresses from WAN 1 - I would suggest contacting support and opening a case so that we can investigate further.    Immediate failover/failback is also an option but we should troubleshoot prior to enabling that option.   https://documentation.meraki.com/General_Administration/Support/Contacting_Support https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Connection_Monitoring_for_WAN_Failover#.E2.80.9CImmediate.E2.80.9D   ... View more

Greetings! It would be helpful to have a screenshot of the issue since it seems more like a notification since not all requirements are met rather than an error. I would also suggest opening a ticket with support so that we can investigate further!  https://documentation.meraki.com/General_Administration/Support/Contacting_Support https://documentation.meraki.com/General_Administration/Support/Attaching_Files_to_Dashboard_Cases ... View more