Meraki, a cloud-managed network device that is one of the Cisco products, has attracted a lot of attention in recent years! It is also very easy to set up, manage, and become a very convenient and popular product in remote work environments.
In addition, it is very speedy at the time of introduction, and it can be used simply by connecting Meraki to a port that is connected to the Internet. It is a very favorite product among me!
Therefore, I will introduce the MR series “Default setting of firewall function” that I met many times in various environments in the author.
About meraki MR series firewalls
About features
The Meraki MR series is an access point, but a firewall function is implemented. There is a “firewall”, but it is not a function like UTM, but “access list (ACL)” of layer 3 and layer 7. (*Adult content filtering is possible in NAT mode.) ）
Layer 3-level ACLs allow you to specify transport protocols (UDP, TCP, ICMP), destination IP addresses (segments), and destination port numbers, allowing/blocking radio client traffic as it crosses mr uplinks.
Note) Cisco devices basically have ALL Deny set on the last line, while Meraki MR has ALL Allow on the last line.
Layer 7 level ACLs are designed to set Deny by specifying any application from the category list prepared by Meraki in advance. Many applications can be specified for the application, such as Youtube, Netflix, Gmail, Box, etc. Alternatively, you can specify the port number, HTTP host name, and IP address range.
Common events
Meraki stores compligues such as SSID settings and radio wave settings in the cloud with Dashboard before using it, so that you can see the pre-configured SSID by simply connecting the Meraki device to a port that can connect to the Internet. Therefore, in the test environment, only the wireless part is set in advance, so the 
following events occur.
Wireless clients connected to Meraki MR have internet communication, but cannot communicate with other local devices. If this happens, it will take a long time to trouble shooting, such as pinging the server in the test environment or communication to the default gateway fails. Some of my customers took a day to solve this problem.
Cause
As I mentioned at the beginning, the cause is mr firewall settings. There is ALL Allow on the last line, but by default there is “Destination: Local LAN traffic is Deny” before it. Please note that “Deny” is set by default!!
It’s basically a wireless device, so it’s a firewall page that you often don’t see during the testing phase. In fact, there is a “trap” that causes it here. This “Local LAN” refers to a private address (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), so communication to the local device fails and the Internet can be communicated.
Before deploying in production, it is often seen in detail in parameter sheets, etc., but it is a very easy specification to miss in a test environment. I would like you to set it to “Allow” by default.