Restrict Switch port to AP

[bigben386]

Hi,

I was curious how one would go about restricting switch ports to only allow a Meraki AP? We use 802.1x for all access ports but the APs are connected via trunk ports which have limited filtering options. I don't like having ports in public spaces that have access to trusted vlans. Currently we have the untagged vlan set to a guest vlan but that is far from secure.

Thanks

[DCooper]

You could use MAC Authentication? Not the MOST secure but it will do the job.

1.MAC whitelist (built-in) and easiest to setup

2.MAC Authentication bypass via Radius

MAC or Sticky Whitelist https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Switch_Ports

[bigben386]

Unfortunately those options are not available on trunk ports. We have multiple SSIDs/VLANS on these APs.

[DCooper]

ahh.. missed the trunk part. I'd agree, no easy way to do this with that design. There are some enhancements coming around switchport authentication but I haven't seen anything immediate to address this.

I can think of a couple ideas to solve this using standards based approach. I also have some ideas using tags and Meraki Authentication. All would require development on our part.

We welcome the feedback on this issue. We can share your ideas back to the team on how this could be solved the easiest way possible?

[bigben386]

My thinking was that the APs and switches are in the same network. There should be some way for the switch to confirm that a trusted AP is plugged in and auto trunk the port. Some type of device certificate authentication would probably make sense as lldp and macs can be spoofed.

[GreggT]

My thought is I would like to apply a filter (probably MAC address wildcard) to the native VLAN to recognize the AP in ISE.  If ISE could profile the WAP even better before permitting.  None of my end-users would end up on that native management VLAN so I'd only have the 1 client on the native VLAN, and still run DHCP with zero-touch for my AP deployment.  So in Meraki terms I could apply an "access policy" to the native VLAN of a trunk port and still run RADIUS on the client requests connected to the AP.

[bigben386]

I would prefer a more generic solution instead of one that relies in ISE. Either a RADIUS attribute that would change the port mode could work or some type of way for the switch to validate a hardware chain of trust in the AP that would then auto trunk the port. If it is not validated, then the port remains an access port. That would honestly be better than using RADIUS as it would stop someone from unlocking the port by MAC spoofing.

We have our AP port's native VLAN set to our guest VLAN so ZTP works but again there is nothing to stop a more sophisticated attacker from looking for tagged vlans and connecting to one without authentication.

[bigben386]

This would also solve the problem of having to worry about which port an AP is plugged into. That would simplify deployment and troubleshooting for offices that do not have IT staff and also eliminate most of the profile overrides we have.

[GreggT]

I'm not sure it would be part of the RADIUS standard to dynamically switch a port from access to trunk or vice-versa, but that is really the same problem I'm trying to solve too. Have the network adjust to an AP that does local switching (be it Cisco, Meraki, or other), so I can get to a single port "configuration" for all the ports on my switch.

[BadOscar]

If you're using cisco controlled wireless the ap ports just need to be access - if you're not then nevermind!

[BadOscar]

---

@BadOscar wrote:

If you're using cisco controlled wireless the ap ports just need to be access - if you're not then nevermind!

---

Sorry - I missed the part about meraki aps.....useless reply!

[PhilipDAth]

@bigben386 you wont be able to put in place a restriction that will achieve this.

[LegoGeek]

I'm in the same boat where last night someone unplugged my Meraki AP from the wall and plugged in their gaming console in.  Since I restrict WiFi access to certain devices - they bypassed using the wifi and plugged right in - "disrupting the bureaucracy" :-).  Needless to say - it would be nice to be able to make a Trunk port have the same "sticky mac address" thought applied like we can do with an Access port.

So has anyone come up with a solution here that I'm missing?

[PhilipDAth]

Here is an easy solution.  Configure the port as a trunk port, and make the native VLAN one that is not in use (and no DHCP).  Then make sure you configure the AP to use a specific VLAN for itself.

[LegoGeek]

I'm still a novice to networking - but I don't think this solution will work if you have (and need) multiple SSID's broadcasting on the AP to separate VLAN's to independent DHCP's (some on the MX and some on an internal domain server). Therefore, (for me) I could not apply @PhilipDAth's idea?

[PhilipDAth]

Yes, it will work.  The other VLAN numbers are not changed.

[LegoGeek]

@PhilipDAth if all my "management" devices (ie. switches, AP's) are on a VLAN that point to an internal server DHCP (current setting is: Relay DHCP to another server)... that is going to break many things if I try your suggestion... correct?  Not sure I'm ready to break things in the midst of a good production environment.

[bigben386]

I had previously tried not setting a native vlan but zero touch provisioning did not work. My APs would not come up initially, try a tagged vlan, and then proceed to download their config. Maybe I was not patient enough but I think I am a pretty patient for an IT person. The second issue is that even if that had worked, it still does not block anyone who plugs into that port from gaining access to any of the tagged vlans. There is still a need for a more secure method to connect APs to switches.

[colo]

If you are trying to secure a trunk port, I would typically "blackhole" the native VLAN. I've done that for office deployments where IT was concerned someone could access the AP's cable in the ceiling and just plug in. It was also recommended by @PhilipDAth

I think in the balance between ease of deployment and security I convinced the IT sec team to allow the guest VLAN or a special "staging VLAN" to be used as the native VLAN - with no internal access to the network. An alternative to a blackhole for the native VLAN is to put it on the guest network. Note that VLAN tagging and MAC whitelisting are security measures, but they are also both not too difficult to work around.

Finally a solution not based on Meraki (thanks MS) that I think we can agree is simple to implement, set your DHCP server to only give out IP addresses to your AP's MAC addresses. Microsoft explains how to do this here: https://technet.microsoft.com/en-us/library/ff521761.aspx