03-28-2018 07:11 AM - edited 03-08-2019 02:26 PM
I work at a university and we are using non-cisco controllerless APs in our dorms. The dorm switches are mostly 3750x but we have some old 3560G as well. Here's how an AP port is programmed on both models:
interface GigabitEthernet1/0/1
description AP
switchport trunk encapsulation dot1q
switchport trunk native vlan 100
switchport trunk allowed vlan 100,200,300,400
switchport mode trunk
We have some problem students who are unplugging the APs in their rooms and jacking their own routers. I am looking for a way to only allow the MAC OUIs of our APs on the Management VLAN (100). We've tried to use port security on the AP port, but we can't seem to target the specific management vlan (100) only and it therefore starts blocking wireless client vlans as well (200,300,400 in this case). We do not have a NAC so that is out of the question, hence why I am looking for something to run on the local switch (or core switch for all dorms). Any help would be greatly appreciated!
03-28-2018 07:25 AM
Hi,
I have two ideas to resolve your issue.
1. Use Dot1x authentication for Wireless AP.
2. I hope VLAN 100 is only for AP management and you can block internet on VLAN 100 use your firewall or router or Switch.
Regards,
Deepak Kumar
03-28-2018 08:01 AM - edited 03-28-2018 08:13 AM
I've considered 1x auth for the APs, however, I'm not sure how we would set that up for the management VLAN only. Unfortunately, VLAN 100 has to be able to get out to the internet since the APs are cloud managed...
03-28-2018 08:57 AM - edited 03-28-2018 09:21 AM
Hello,
I can propound you this temporary workaround:
because chances are that your student routers are not 802.1q compatible (or you can count on the fact that they won't know how to set this up) the traffic is untagged
My workaround:
This way, all untagged traffic will be dropped and the port will be shutdown if they connect a switch with STP enabled
Regards, Guillaume
[edit2]Add more fun:
do not shutdown the native vlan, put a captive portal with a page to ask your students to unplug their devices and plug back the AP
03-30-2018 11:48 AM
Your workaround is something I've thought of doing, however, would add some steps when installing new units or replacing units (the APs come up by default to not tag management traffic until they receive a config telling them otherwise). The bpduguard wouldn't do us much good for a router which is mainly what is connected when these issues arise.
We are going to try to work some magic with our DHCP server so that it only hands out IPs to certain OUIs. If this doesn't work, we will most likely go to the tagging of management traffic in some way but I was hoping I could avoid that just so the devices stay more plug-and-play. Thanks for the suggestion!
03-30-2018 01:01 PM
Hello,
Like i stated, the workaround i propounded you is a temporary one, and yours looks temporary too: it does not prevents rogue routers to use static addresses.
I voted Deepak post as helpful because i agree that dot1x is the way to go.
If you want to add some more magic directly within vlan 100, you could break the ARP with a vlan access-map allowing only your APs to use ARP (and the gateway of course) based on MAC addresses, for example:
10 match ARP traffic from AP and GW MAC adresses=> action forward
20 match ARP traffic from any MAC=> action drop
30 match all (default) => action forward
https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3550-series-switches/64844-mac-acl-block-arp.html
Ps. i restrain my suggestion about portfast and bpduguard, AP in autonomous mode could send bpdu.
Regards, Guillaume
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: