Hi, there are a few caveats for using FQDN in L3 firewall rules:   The MX must see the client's DNS request and the server's response in order to learn the proper IP mapping. The communication between the client and DNS server cannot be intra-VLAN . Additionally, in some cases the client device may already have IP information about the web resource it is attempting to access. This could be due to the client having cached a previous DNS response, or a local DNS entry in a host file. The MX will not be able to block communications to the web resource in these cases. You should configure a L3 allow rule for DNS traffic, eg:                       this rule should be placed above the rule containing the FQDN. hope this helps!   ... View more

Hi! You should be able to form an eBGP peering over IPsec with the Hub, with the following pre-requisites: IKEv2 setting MX 19.1.4 or newer release MX platforms that support MX 19.1 firmware and above BGP - TCP port 179 permitted on your VPN firewall BGP enabled BGB Multi-hop enabled on BGP neighbor If you chose the Hub network to configure, according to: https://documentation.meraki.com/MX/Site-to-site_VPN/BGP_routing_over_IPsec_VPN#Configuring_eBGP_over_IPsec   Routes should then be propagated to the spoke sites.     ... View more

Hi,   Please ensure you do not tag the native VLAN the management (LAN) IP section; this field should be blank:   this is effectively 'double tagging' and will prevent the AP from receiving a DHCP IP lease in the correct VLAN.    You can tag the SSID with the VLAN chosen for client traffic by navigating to Wireless > Configure > access control, selecting the SSID from the dropdown menu, and scrolling to the bottom of the page:     If the above is configured correctly, and you are seeing the lease assigned from the server logs, try rebooting the AP by cycling the upstream switchport. ... View more

Hi, Windows is not great at handling situations where the client and / or server (MX) is behind NAT, and this will generate an 809 error.  I am also seeing that, recently, the Windows VPN client does not report the specific numerical error, but reports "The network connection between your computer and the VPN server could not be established because the remote server is not responding."    This can be resolved with a registry edit, which can be tricky to apply. However, you can download the regedit file here   The link also contains advice on resolving other Windows client VPN errors.  Hopefully you will find this helpful 😊 ... View more

Hi,    Once a Cloud Archive license has been purchased and applied, all MV cameras (Except the MV2 which has live video only) will archive footage to the cloud.   Once the Cloud Archive license is applied, the camera will start recording footage to the cloud for that 7, 30, 90, 180, or 365 days of 24/7 recording. It will not upload or back up footage previously stored on the camera before the license was applied. The recommended MV firmware for cloud archive is MV 3.22 or higher Please refer to the documentation  for more information.    ... View more

You will need to send "interesting traffic" (ie: a continuous ping) from a device behind the MX in one of the exported subnets, toward a device in a subnet behind the remote peer that is participating in the VPN to bring up the tunnel.  You should then at least see ISAKMP initiator requests egressing the MX WAN interface. you can verify with a capture on the internet interface of the MX. These would be UDP packets toward the remote peer public IP on port 500 or 4500. If you are using a PPPoE uplink, the filtered capture would be blank unless you filter for "pppoes and host x.x.x.x" ... View more

Hi,    Assuming the MXs are in different dashboard Organizations, then this would be treated as a non-Meraki VPN.   I would suggest a packet capture on the Primary WAN (Internet) interface on both sides, filtering for the public IP of each remote appliance:     (so, from your site, x.x.x.x would be the Public IP of your Customer's MX and vice-versa)   Then you will be able to verify if ISAKMP traffic is being sent from /reaching either side.   If there is another firewall upstream, ensure UDP 500 and 4500 is allowed to and from the remote side.   If you are using IKEV2, please understand these settings, especially the local and remote ID fields, if either side is behind NAT. The event log can also be a useful source of information. If you need further assistance, please do not hesitate to open a Support case, we are here to help! 😊 ... View more

Hi    Thank you for your reply.   In Allowed URLs, abcd.com will allow all subdomains of abcd.com , whereas "*abcd.com" will only allow the URL "*.abc.com" which is unlikely to be useful.    The " * " (asterisk) symbol when used as part of a URL or in line with a URL is simply a regular asterisk symbol and is interpreted as part of the URL, NOT as a wildcard. ... View more

 If you do require L3 roaming, and this is an issue, you can use DHCP option 26 to set the clients to a smaller MTU size. ... View more

Hi Ash,   Welcome to the Meraki Community! 😊   Site-to-site VPN settings are managed on the Security & SD-WAN > Configure > Site-to-site VPN page, and 3rd-party peers are located in the Organization-wide settings section. When configuring a peer, you can modify the IPsec policy settings by clicking the three dots on the right side. In the window that appears, a number of options are available.    The Preset selection allows easy setup of peers for some popular services, such as Azure and AWS. "Default" will reset the parameters to those used between Cisco Meraki peers, and "Custom" can be used for non-standard configurations, and this should enable you to replicate your existing VPN configuration.   Further details can be found here.   Some terminology may be a little different, eg Local ID of this MX. This is an optional configuration and is what the remote peer will receive as the remote ID of this MX, and is only available with IKEv2 tunnels. If left blank (default) it is the uplink IP of the MX, not the public IP. Some peers may expect this to match the public IP of the MX, and you can enter this here, if required.   If you run into any issues with your initial setup, please free to open a case from Support Center in your Meraki dashboard, and an NSE will be happy to assist!               ... View more