EAP ACL vs. Switch ACL

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

EAP ACL vs. Switch ACL

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
EAP ACL vs. Switch ACL
EAP ACL vs. Switch ACL
2023-04-20 22:06:13 - last edited 2023-04-21 22:33:08
Tags: #ACL

I've been configuring ACLs for VLANs for LANs and EAPs through the switch ACL only. It's worked for both LANs and EAPs correctly.

 

A colleague recently asked me why there is an EAP section under ACL configuration if we only use Switch. Good question. So, why is it there and when would you use it? I would suppose when you are working on a network with no TP-Link switch or router, but still have EAPs and a Cloud Controller. 

  0      
  0      
#1
Options
1 Accepted Solution
Re:EAP ACL vs. Switch ACL-Solution
2023-04-20 23:15:13 - last edited 2023-04-21 22:33:08

  @Icthus 

 

If you actually think about it, an AP is really just a wireless switch so you can therefore apply an ACL at the EAP level and it will work perfectly fine.  

 

Sometimes you may want the traffic stopped even getting to your switch from the WiFi and an EAP ACL would do that, however honestly in 99% of cases Switch ACLs are the default.    As you say should you have a dumb switch (store and forward, not managed) then ACL at the EAP would make sense to cut out traffic early and stop anything you don't want hitting the switch.

 

The one time I seen this used in vain was the block Apple Bonjour traffic going between the WiFi clients, an ACL was placed on the EAP to stop the Apple devices talking over WiFi as it was causing un-necessary congestion.   An ACL on the switch would not have worked as the traffic was WiFi to WiFi and didnt hit the switchport, so the EAP ACL made sense.

Recommended Solution
  2  
  2  
#2
Options
7 Reply
Re:EAP ACL vs. Switch ACL-Solution
2023-04-20 23:15:13 - last edited 2023-04-21 22:33:08

  @Icthus 

 

If you actually think about it, an AP is really just a wireless switch so you can therefore apply an ACL at the EAP level and it will work perfectly fine.  

 

Sometimes you may want the traffic stopped even getting to your switch from the WiFi and an EAP ACL would do that, however honestly in 99% of cases Switch ACLs are the default.    As you say should you have a dumb switch (store and forward, not managed) then ACL at the EAP would make sense to cut out traffic early and stop anything you don't want hitting the switch.

 

The one time I seen this used in vain was the block Apple Bonjour traffic going between the WiFi clients, an ACL was placed on the EAP to stop the Apple devices talking over WiFi as it was causing un-necessary congestion.   An ACL on the switch would not have worked as the traffic was WiFi to WiFi and didnt hit the switchport, so the EAP ACL made sense.

Recommended Solution
  2  
  2  
#2
Options
Re:EAP ACL vs. Switch ACL
2023-04-21 02:29:12

 @Philbert thank's for the explanation. I need some further understanding. I know how some other APs work with other vendors, but not fully about TP-Link. If you have a network with a fairly dumb router like a Best Buy Netgear router operating with 1 LAN subnet and unmanaged switches, how do the EAPs work? How do the SSIDs get IP addresses? How do they pass on their traffic when the unmanaged switch ignores the VLAN headers?  I know I can go to Wired Networks > LAN and set up a LAN (subnet) with accompanying VLAN and then to Wireless Networks > WLAN and set up SSIDs with VLANs to match, but how does the EAP actually work when there is no router there to assign IP addresses on the LAN (subnet) demarked by the VLAN? Does the EAP just operate with the IP addresses on the 1 LAN subnet that the simple Netgear hands out?

 

Datto and Open Mesh have WAPs that are programmed in the cloud also. They can define up to 4 SSIDs and the WAPs act as mini-routers, creating their own subnets for each SSID. No VLANs need to be defined, although you can define one if you wish. If not, no problem because the WAP is smart enough to know it needs to act as a router and create a subnet and NAT as needed. So, connecting them to a basic router with an unmanaged switch is no problem. I've used these for years and I'm migrating to the TP-Link EAPs now and need some insight.


Thanks for the help.

 

  0  
  0  
#3
Options
Re:EAP ACL vs. Switch ACL
2023-04-21 08:34:04

  @Icthus 

 

Hey

 

So there are 3x types of VLAN traffic, namely tagged, un-tagged and native.  Tagged simply means its added to the header when the data is sent, so your DHCP reply will have VLAN10 in the header.

Un-tagged in the opposite, not sent with any VLAN requirements

Native VLAN is more for switches.  You can say anything on port 1, 2 and 3 are tagged for VLAN10.  So if data arrives on port 1 untagged, its now VLAN10 data..  once it leaves on port 3, its un-tagged again.  Basically its temporary VLAN for that switch (or connection of switches).    This is really how most dumb switches work, every switch has a VLAN or some type.. in dumb switches its just VLAN1 for all ports and you cant change that so its pretty much can be treated as dumb..

 

In short all devices are set as dumb out of the box and will just pass traffic un-touched out the LAN port.   In reality for your example, should you have a EAP with VLAN10 tagged to its SSID, the un-mananged switch it is connected too wont read or care about the tagging.. it will just forward based on the frame header (ethernet) totally ignoring anything VLAN related, therefore in essence the packet will be sent untouched and should still contain the VLAN10 tagging.

 

If you do have a VLAN set on your EAP, you will need to ensure that that VLAN can get a DHCP ok.. 

 

example 1.    Router (Omada) tags a packet with VLAN10 and sends out LAN port - dumb switch ignores VLAN tag and just looks at the MAC address of the destination, sends out the port the MAC address is connected too..  VLAN10 is still tagged to the frame, the switch didnt read that bit.   -   EAP receives data, checks if its for VLAN10, if so accepts, otherwise discards. 

 

example 2.    Router (dumb) sends DHCP out LAN port untagged (no VLAN) - dumb switch just looks at the MAC address of the destination, sends out the port the MAC address is connected too.. still no VLAN tagged here  -   EAP receives frame, checks if its for VLAN10, 11 and 12 (the ones it knows about) as none of them are mentioned in the header (there is no VLAN tagging done by router or switch), it discards it.  In this case DHCP would not work for example, the router or switch needs to be able to provide DHCP traffic tagged on the correct VLAN for the device.

 

OK so those are simplified, but hopefully makes sense!

 

In short, using an un-managed switch generally isnt an issue with VLANs (tagged) as long as you have the traffic tagged when being sent, else it wont be read at the other end.

 

If you want to keep it simple, dont use VLANs and just let all devices work un-tagged, therefore it will recieve and read all data including DHCP

  0  
  0  
#4
Options
Re:EAP ACL vs. Switch ACL
2023-04-21 12:56:43

  @Philbert 

 

Great explanation. Thank you. If I understand this all correctly, if you have a dumb router and a dumb switch that feeds internet to an EAP:

 

  1. Don't use VLANs.
  2. All SSIDs will get the same subnet that the dumb router manages and provides DHCP.
  3. Enabling Guest Network will wirelessly isolate any device from both LAN devices and other Wi-Fi devices, giving only internet access.

 

My next question is if all SSIDs get the same subnet in this scenario, how do you create rules to allow devices on each SSID to talk to each other, but not talk to devices on another SSID? In Network Security > ACL rules, I can see how Source can be an SSID, but Destination is only based on IP address(es) or on a defined Network (which does not matter when using a dumb router and dumb switch).

 

Thanks again for the help.

  0  
  0  
#5
Options
Re:EAP ACL vs. Switch ACL
2023-04-21 22:09:04

  @Icthus 

 

Hey

 

Read your reply earlier and was thinking for a bit on how you could implement this, pondering on one thing..

 

Segmentation of the separate SSIDs won't work for you as they are still joined at the same switch on the same vlan (default) and on the same IP range.    Therefore i can think of an easy way to do this without blocking the traffic via VLANs. 

 

The only thing i can come up with is manually setting IP addresses for the devices as they connect, say SSID1 192.168.0.2-35   SSID2   192.168.0.36-50  etc etc.. it would however mean setting every device with a DHCP reservation which is messy.   Then creating Profile Groups based on those IPs to segment into 3 seperate groups, then a EAP ACL to stop group1 seeing group 2 etc etc..  its really messy!

 

Honestly cant see an easy way to do this mate.

 

 

  0  
  0  
#6
Options
Re:EAP ACL vs. Switch ACL
2023-04-21 22:32:47

  @Philbert 

 

Yeah, brother, I don't see how to do it either. I hoped you might pull a rabbit out of your hat. wink

 

Thanks, cheers and have a great weekend!

  0  
  0  
#7
Options
Re:EAP ACL vs. Switch ACL
2023-04-21 22:40:26

  @Icthus 

 

The only other thing i can think of is to use PPSK and segment it based on the PSK.  

 

Never done this so just thinking out loud here..   as its one network anyways there is no real advantage to using multiple SSIDs, have one SSID and segment it via PPSK

 

Incase you are not aware, PPSK is Private PreShared Keys.. basically you could create 3x PPSKs called whatever you want..  IOT..  HOME... PHONES.. etc   each would have its own unique PSK but all will connect to the same SSID.  Its basically multiple PassCodes in the same SSID. 

 

My thinking from what little i have played with this, if devices share the same PPSK they can see each other as it will be able to decrypt the data.   Another PPSK, it cant decrypt so wont see it if scanned.   

 

Im just guessing here, if you had 3x devices on PPSK1, they would see each other.. but not the 5 devices you have on PPSK2... it might work that way as you are not sending over the LAN so its blocked by the encryption, rather than the network.. 

 

You would need to test this, I could be in fantasy world   lol

 

  0  
  0  
#8
Options