Why Meraki Wi-Fi Cannot Print When the MX Firewall Allows Everything
Short answer: Wireless traffic is filtered on the access point before it reaches the MX. On that SSID, Wireless → Configure → Firewall & traffic shaping still has Deny Local LAN. That rule blocks RFC1918 destinations — printers, file servers, domain controllers, other PCs. The MX outbound table can sit on its default allow and never see the print job.
Why can the MX look wide open while printing still fails?
People debug the wrong box.
The MX Layer 3 outbound firewall is evaluated for traffic that arrives at the MX. If no outbound rule matches, the documented default at the bottom of that table is allow. An empty or “permit the internet” MX policy does not prove that a wireless client was allowed to talk to 192.168.x.x.
Meraki access points apply their own Layer 3 firewall per SSID. Rules run top-down on traffic leaving the AP. First match wins. A deny here drops the packet on the AP. The MX never logs it as an outbound miss, because the packet never got there.
The row that causes this ticket is not hidden. It is labelled Local LAN, and it lives under wireless firewall settings — not under Security & SD-WAN.
What does Deny Local LAN actually block?
Deny Local LAN matches destinations in RFC1918:
10.0.0.0/8172.16.0.0/12192.168.0.0/16
That is every usual office printer, NAS, file server, internal RADIUS host and desktop. The setting applies in Bridge mode and in NAT mode. It is not “NAT-only.”
A new organisation’s first auto-created SSID is commonly NAT mode with Deny Local LAN left on. That is a sane guest default. It is the wrong default for a staff SSID that must print, join AD, or hit an on-prem file share.
Cisco’s own wireless firewall notes: clients that need internal LAN resources — including RADIUS — need Allow Local LAN (or a more specific allow above the deny).
Where do you change it?
Open the network that holds the SSID, not the MX appliance page.
Go to Wireless → Configure → Firewall & traffic shaping.
Select the staff SSID.
Find Deny Local LAN / destination Local LAN.
Set that SSID to Allow Local LAN, or insert a narrower allow above the deny.
Do not copy the same change onto the guest SSID.
| SSID purpose | Local LAN policy | Why |
|---|---|---|
| Staff / corporate | Allow Local LAN, or allow specific printer / server addresses above a deny | Print, file, AD, on-prem apps |
| Guest / contractor | Deny Local LAN | Stops guests scanning RFC1918 |
| IoT / printer VLAN SSID | Allow only what that VLAN must reach | Do not open the whole campus from a camera SSID |
A /32 allow for the print server, placed above Deny Local LAN, is cleaner than opening every private range when the staff SSID should not roam onto every VLAN.
Layer 3 rules on the AP are ordered. An allow that sits below the Local LAN deny never runs.
How do you confirm the MX is not the problem?
| Check | If this is true | What it means |
|---|---|---|
| Same laptop on wired prints | MX path to the printer works | Problem is on the SSID / AP policy |
| MX outbound L3 has no deny for that printer | Default allow would have passed it | Packet likely never reached the MX |
| Wireless firewall shows Deny Local LAN on that SSID | Matches the symptom | Flip or punch a hole on that SSID |
| Packet capture on the MX shows no client to printer | Consistent with an AP drop | Do not keep adding MX allows |
Use Event Log and a wireless pcap on the AP / SSID if you need proof. Adding another MX “allow any” rule will not resurrect a packet the AP already dropped.
What else looks like Deny Local LAN but is not?
Fix Local LAN first. If print or discovery still fails, look at these as separate controls.
NAT mode on the SSID
NAT mode puts wireless clients on a private AP-translated range. That is a different design from Bridge onto the corporate VLAN. Deny Local LAN can still apply. Changing only the MX will not put the laptop on the printer VLAN.
Staff SSIDs that must use internal printers are usually Bridge onto the correct VLAN, with Local LAN allowed as above.
Layer 2 isolation / client isolation
That stops wireless clients talking to each other. It is not the RFC1918 destination rule. A peer-to-peer AirPrint path or a user-to-user share can fail here even when Local LAN is allowed.
Bonjour / mDNS / AirPrint discovery
Apple discovery is multicast. Allowing TCP 9100 to a /32 does not automatically make the printer appear in the laptop’s list. That is a Bonjour forwarding / VLAN-discovery problem, not an MX outbound miss and not the same row as Deny Local LAN.
Wrong VLAN or no route
Bridge + Allow Local LAN still fails if the SSID is on a guest VLAN that has no route to the print subnet, or if the printer ACL on a switch drops the client subnet. That is switching, not the wireless Local LAN toggle.
What should a Singapore office set on day one?
Staff SSID: Bridge, correct VLAN, Allow Local LAN (or explicit printer/server allows above a deny).
Guest SSID: NAT or isolated VLAN, Deny Local LAN left on.
Do not debug printing on the MX L3 page until the wireless firewall page for that SSID has been read.
After an MR → CW refresh, templates copy the same SSID firewall. New radios will repeat the old deny.
Licensing and AP naming do not change this rule. A CW9174I with a correct subscription still drops RFC1918 if the SSID says deny.
FAQ
Is Deny Local LAN a hidden rule?
No. It is a labelled destination on Wireless → Firewall & traffic shaping. People miss it because they only open the MX firewall.
Does the MX default deny inbound from the internet?
That is a different table. This article is about wireless clients to internal RFC1918. Do not treat inbound WAN policy and Deny Local LAN as one control.
Will Allow Local LAN expose the guest network?
Only if you change it on the guest SSID. Change the staff SSID. Leave guest on deny.
We use 802.1X and RADIUS on-prem. Does this matter?
Yes. If RADIUS is an internal RFC1918 host, Deny Local LAN can break authentication as well as printing. Allow the path the SSID actually needs.
If wired works and wireless cannot reach printers or file servers, send the SSID name and a screenshot of Wireless → Firewall & traffic shaping for that SSID. Megatron Technology will tell you whether it is Deny Local LAN, NAT, isolation, or a VLAN — before anyone adds another MX allow.
Request help: www.megatron.com.sg/ciscomeraki · Contact