Meraki Port based Access Control Policies vs. Traffic Access Control policies.

Here is the layout: 

Dual MX100's serving the Internet to the LAN.  A core network consisting of MS320's configured for Layer 3 routing, and MS220's in the IDF.

Previously in a temporary network setting we had a single MX100 serving all the switches with Layer 3 disabled.   At the time, the only way to apply policies to WIRED connections was to integrate with Active Directory.  The downside to configuring the Traffic Control Policies this way is you couldn't see what policy was applied.  They were in effect applied but in the Meraki Cloud Control Interface when looking at your clients all you saw was "Policy: Normal".  This particularly bothered me in general, but at the same point, made it difficult to troubleshoot policies because you couldn't see or tell what policy was actually being applied without creating a different rule in each policy and checking on the end point.  

This is different on the Wireless Networks.  On the Wireless networks you could configure Radius authentication and have policies applied per the 802.1x configuration.  Those clients showed what policies were applied.  

In discussing with Meraki, at the time, it was stated that the only way to get the wired clients to show in the policy counts, or in the client info portion of the Meraki Cloud Control was to have them either authenticate via a splash page, or to use the Port Access Policies through 802.1x.  

In transitioning to the final network, we implemented Port based Access Control, thus every connection authenticating not only to get network access but also, in theory, get the Traffic Control policy applied per user group.  However, once authenticated, the policy still showed normal in the Meraki Cloud Control Web interface.   In troubleshooting we applied a deny rule on the MX100 and a different rule to the policy that should have been applied for the 802.1x group upon authentication.  The rule at the MX100 applied, but nothing at the policy level was applied.

We reached out to Meraki to find out that in fact that is to be expected.  That the Layer 3 switches do not pass, and cannot pass the authentication to the MX100.  I am still stumped as to why that is the case.  The MR34 access points we have, are plugged into the same MS320 switch that we were using as our test port, and they authenticate from the same Radius server.   Meraki didn't have a further explanation of why.

Basically at this point it's a decision to be made, do you prefer the security and benefits of Access Control Policies at the switch level, or do you need to have the Traffic Control Access Policies applied on the wired connections?

Here are what I have gathered regarding the trade offs:


Wired Connections:
Networks hosted on Layer 3 Switches: - No Group Policies are applied, you are not allowed to manually apply policies, all you get are the default rules.

Networks Hosted on the MX: - Works as normal, you get Block pages for Layer 7 rules, you also get policies applied; both AD Integrated and Meraki direct.  You can also see what policies are applied to each client.

Wireless Connections: - You do see what policies are applied, and policies are automatically applied, however you do not get block pages just page time outs.


Wired Connections:
Networks created on Layer 3 Network do show, and are applied correctly if AD Integrated.  No Policies are applied via port based authentication.  However, even if Integrated via AD, policies do not show in the "Appliance's Network".  You also just see an IP Address vice client name.

Wireless Connections:
Policies would need to be applied at the "Appliance Network".  If applied at Switch \ AP Network you just get page timeouts but no messages.

Overall it seems as if whatever technology Meraki uses at the Access Point level to control policies upon authentication also needs to be applied to Layer 3.  Given how all these products integrate on the network, there should be a way for them to pass that information back to the dashboard.