That is unfortunate. It seems like functionality that would be most useful if standardized across the entire network. ... View more

No, it isn't showing up publicly, just locally from internal vulnerability scans. ... View more

I fully agree.  Ther Meraki VPN tunels to 3rd party peers leaves a lot to be desired.  (No backup peer IP, no granularity for configuring different sets of source IPs to different destination IPs, no IKEv2).   I respectfully disagree with @PhilipDAth on the SSL inspection.  Our DLP policy enforced by zScaler allows us to grant users access to read documents shared from sources like Dropbox, Google Drive, Office 365, without allowing them to upload documents/files to those destinations.  That requires SSL inspection and a much more sophisticated policy set than is offered with Meraki.  Not to mention, the tunnel config options I mentioned above are all just standard boiler plate Site to Site VPN tunnel options, which would let a solution like zScaler work just fine. ... View more

This is an old thread, but I'm now running into the same issue.  I disagree with the statement this is an unusual configuration since it has been a standard configuration in other Cisco firewalls for as long as I can remember.  In an ASA as an example, you simply configure your phase 2 with something like the following: crypto map outside-vpn-map 999 set peer 104.129.206.38 165.225.0.42 This really is an important feature for the Meraki if it is going to be a viable replacement for other firewall products.  We use a tunnel like this to route traffic through a DLP vendor and since the Meraki firewall replacement, there is now no fault tolerance in the VPN tunnel on the vendor side.   This kind of thing and lack of support for IKEv2 in the VPN tunnels is really disappointing for anyone trying to move to Meraki from other more traditional firewall and networking gear. ... View more