This article describes best practices for configuring DNS servers on the WAN interfaces of all Cisco Meraki products. One of the most common DNS configurations when assigning a static IP address to the MX is to use one ISP-provided DNS server and one well-known public DNS service such as Google (22.214.171.124). Many ISPs use their own hosted DNS server and may not have all records or have lookups to many publicly-accessible servers.
All DNS queries for wired.meraki.com that route through the MX are intercepted and responded to with an A record pointing to the local IP address of the MXs wired.meraki.com interface. If DNS queries for wired.meraki.com do not pass through the MX, DNS queries for wired.meraki.com will not resolve to the correct local IP address and clients will not be able to reach the local wired.meraki.com page.
Wireless-capable MX or Z1 devices have the option to authenticate wireless users with a RADIUS server. If this RADIUS server exists on the other side of a VPN tunnel, it will be important to note which IP address the MX/Z1 will use when sending its Access-request messages. This article explains how to determine the source IP address used by a wireless-capable MX or Z1 for RADIUS authentication.
The MX Security Appliance can be configured to act as a warm spare, where a primary MX will "gracefully" fail over to a pre-configured, online secondary appliance. However, if a primary MX fails before a secondary was pre-configured as a spare, the network admin must perform a “cold spare” swap by cloning the original MX's configuration and swapping in the replacement appliance. This article outlines the full procedure for an MX cold swap.
The MX400 and the MX600 support a hardware feature known as port bypass which enables traffic to flow through the devices in the event that the MX loses power or is shut down unexpectedly. This is done by the pairing of circuiting between WAN port one with LAN port one and WAN port two with LAN port two.
The following instructions outline how to use the password reset feature for network users. Note: If you are trying to reset the password for an administrator's Dashboard account, please refer to our KB documentation on resetting an Organization or Network administrator password.
There are circumstances where a switch will fail, and the only option is to replace the device. However, many common symptoms that may appear as device failure can be resolved with some simple troubleshooting steps. This article outlines common symptoms and troubleshooting steps for Cisco Meraki MS switches, as well as information about how to request an RMA.
To achieve redundancy, a secondary MX can be added to Dashboard as a warm spare, allowing it to share the primary MX's configuration and seamlessly take over in the event of a device failure. This configuration is commonly referred to as High Availability NAT (NAT HA). This article outlines common troubleshooting steps and best practices for NAT HA configurations.
Universal Plug and Play (UPnP) is a series of protocols for communication between networked devices. It allows for devices to automatically discover, create connections and communicate with each other without additional setup. UPnP is the networking equivalent of Plug and Play which is used for devices like keyboards and other peripherals that are used with client devices today.
The MX security appliance is designed to be used as a VPN endpoint, but as a firewall it can also pass VPN traffic to an internal VPN endpoint. PPTP and IPsec are protocols used to establish a secure encrypted VPN connection between two end points. This article outlines how the MX handles PPTP and IPsec traffic, including routing specifics and limitations.
No articles with the article type topic could be found.