Stop Inter-station Traffic per User Profile or VLAN?

  • 3
  • Question
  • Updated 4 years ago
  • Answered
I am trying to stop Inter-Station Traffic on a specific User Profile or VLAN.  I was following Crowdie's write up at https://community.aerohive.com/aerohive/topics/proper_dhcp_setup (which is wonderful and thank you Crowdie) but ran into an issue when I tried to expand upon that.

I have two SSID's.  One for Guest which this works for...one for Corp.  On the Guest SSID I have set a traffic filter to remove SSH, Ping, and Inter-station Traffic.  On the Corp SSID...I have multiple User Profiles...one for BYOD Devices and one for Company Issued Devices.  The Corp SSID is using 802.1x and matching an AD group to reassign Domain Based Computers to the Company Issued Devices Profile. 

I would like to block the BYOD User Profile from having Inter-station Traffic capability while not blocking my Company Issues Devices Profile..however the Traffic Filter is assigned per SSID.  Is there any way to set a traffic filter per VLAN or User Profile?  I can set separate IP Firewall Policies...but not DoS Settings.

Thank you.
Photo of Smitty

Smitty

  • 37 Posts
  • 3 Reply Likes

Posted 4 years ago

  • 3
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Great question... and the answer is that this is unfortunately not possible today. This is an issue that I have had in the past seeking to get AppleTVs using a PPSK on the same SSID as guest access while 802.1X support was broken in Apple's code, incidentally now resolved.

Ideally, controlling the ability of a client to send inter-station traffic would be on a per-profile basis rather than SSID basis to give granularity and avoid the proliferation of SSIDs, which has performance overheads as well as logistical implications.

Have you contacted your point of support about this issue? I would ask them to put this forward as a feature request to see what Aerohive say.

Alternatively, following the less formal approach, repost this here as an idea and frame it as a feature request and I am sure that somebody from Aerohive will get back to you. I will certainly add my vote to it.

(Edited)
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
I am glad you liked the DHCP post Smitty.

When a company issued/BYOD device joins the wireless network does it get assigned to the same VLAN as the wired devices? 

I tend to design my wireless networks around security zones with the LAN as the most secure followed by the company issued wireless devices followed by the BYOD devices.  With each of these clients placed in a unique VLAN:

* Company issued device connected to LAN - VLAN 100
* Company issued device connected to WLAN - VLAN 110
* BYOD device connected to VLAN - 120

you can now utilise the integrated firewall in each access point to limit access.

I find this type of design also keeps the security engineers happy :-)

If you are in a situation where you don't want to run a number of VLANs across your site(s) you can tunnel the different VLANs back to a single point (as a centrally switched wireless LAN controller does) using a Cloud VPN Gateway.  This way the different VLANs only need to exist from the Cloud VPN Gateway to the switching core.  If your security engineers want traffic to terminate in a DMZ this is the way to do it.
 
(Edited)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Crowdie makes a great point which is that if you are in a different VLAN, there is Layer 2 isolation between broadcast domains (zones) so a Layer 3 filter via an IP firewall may be accepable. This is because a routed boundary would have to be crossed for clients in different broadcast domains to talk.

You may wish, however, to have isolation between clients in the same broadcast domain. I always do this to limit the ability of a bad acting client in a broadcast domain to impact on another in the same broadcast domain, where there is no need for them to communicate in a peer fashion, of course.

This may not be an accepable workaround for you therefore. If this is a concern to you, you would still need to prohibit inter-station traffic. For untrusted guest access, I personally consider this to be a must in a good design.

All depends on your use case, requirements and expectations! :)
(Edited)
Photo of Smitty

Smitty

  • 37 Posts
  • 3 Reply Likes
Thank you both very much for the replies. 

Nick - I would contact my point of support...but I am a little bit on my own with this pilot project we are running.  Our original partner didn't want to work on our pilot because they did not have an office in that city and our new partner/vendor doesn't have any trained Aerohive Engineers.  So...we are trying to figure it out ourselves and using remote Aerohive presales engineers and support.

Crowdie - When a device joins the wireless network...it is in a dedicated VLAN.  In our case...

* Company issued device connected to LAN - VLAN 10-19 (depending on building floor)
* Company VoIP LAN - VLAN 20-29 (depending on building floor)
* Company issued device connected to WLAN - VLAN 30-39 (depending on building floor)
* BYOD device connected to WLAN - VLAN 50-59 (depending on building floor)
* Guest device connected to WLAN - VLAN 60-69 (depending on building floor)

We have the firewall rules established for the BYOD and guest VLAN's to something very similar to Guest_From_IP_Policy from your post.  That does restrict them from the company network and isolates to a broadcast domain.  On the Guest SSID I added the traffic filters you described in your post.  However...the BYOD VLAN does not have the traffic filters and they can all see each other.  It is not a huge issue...I just was trying to eliminate the possibility of them spreading a virus to each other or other frankly unknown issues from a bad acting client.  Eliminating Inter-Station Traffic seemed ideal. 

I could break the BYOD on to a dedicated SSID...but I was trying to keep the number of SSID's to a minimum.  I don't think creating a whole separate SSID to eliminate the Inter-Station Traffic on the BYOD VLAN is probably worth the cost. 

However...if they could add this as a feature...it would be really nice.

Thank you both very much.  Also...thank you for all the posts, they have been very helpful in trying to get my Aerohive pilot project moving forward.
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes


As your BYOD devices are placed into unique VLANs I would just use the integrated firewalls to drop all traffic from a BYOD device to VLANs 20-39 and 50-69.  Obviously you would also have firewall rules limiting access to the corporate LAN.

This firewall policy would be assigned to the BYOD device's user profile.


(Edited)
Photo of Smitty

Smitty

  • 37 Posts
  • 3 Reply Likes
I have a firewall rule set to drop 10.0.0.0/255.0.0.0...which should eliminate all of my other VLANs and isolate them to their one BYOD broadcast domain.

Thank you for the assistance!
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I did some research on this by hunting through the source of the open source Linux kernel drivers and associated user mode code, and a few mailing lists.

The reason is that the driver for the wireless chip implements this feature, usually with hardware support, and does so on a per-BSS basis. That is for performance reasons and means that we cannot easily or realistically see such support on a per-profile basis which is much higher up the abstracted stack - it would require handling via the CPU and quite a lot of code churn and work to implement it.

(The feature on a per-BSS basis is a standard one and is typically known as ap_isolate.)
(Edited)
Photo of thewifigeek

thewifigeek, Champ

  • 86 Posts
  • 12 Reply Likes
Some really good tips from both Crowdie & Nick.  One more consideration is separate DNS server for BYOD and/or GUEST depending on your security stance.  

Generally, it's my preference to have BYOD users using DMZ or public DNS server and GUEST users using only public DNS servers.
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes

And (for anybody who hasn't read the DHCP post) utilising the integrated DHCP server in each access point to allocate IP addresses to BYOD and/or guest wireless clients allows you, with the use of public DNS servers, to keep your corporate servers isolated from BYOD and/or guest wireless clients.
(Edited)
Photo of Smitty

Smitty

  • 37 Posts
  • 3 Reply Likes
Crowdie,

Question on the DHCP servers. You mentioned assigning the DHCP server to a mgt subinterface like 0.1. I was trying to put a seperate DHCP server in each physical office but use the same network policy across most of my offices. Would this mean I would be limited to 16 offices with DHCP servers...one on each different sub interface?

Thanks.
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
You specify the DHCP server object in the AP's Service Settings. You can therefore assign different DHCP server objects (serving different scopes as needed) to APs in different offices as you like and everything can still use the same network policy.

You only need to use different management subinterfaces (i.e. mgt0.1, mgt0.2 etc.) if you have multiple VLANs in the same location for which you want the APs to be DHCP server. i.e. you can have up to 16 DHCP instances PER AP, each on a different VLAN.

A typical deployment would be to have two APs at each location acting as a DHCP servers, each with half the address space in their pool - very similar to how you would configure a pair of Windows DHCP servers. You could also have both APs serving the same pool, relying on the ARP check for conflicts to prevent the same address being allocated to different clients by the two servers. Personally I prefer to split the scope (e.g. 10.1.1.1 - 10.1.1.124 for one and 10.1.1.124 - 10.1.1.250 for the other, leaving you a few spare addresses for the mgt0.x interface and default gateway).
Photo of Smitty

Smitty

  • 37 Posts
  • 3 Reply Likes
Ahh...that is what I was missing with the subinterfaces. Thank you for the clarification. I just need the one.
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
IP firewall policies can block traffic within the subnet as well as to other subnets (just be careful to ensure DHCP is still allowed). They can only block IPv4 traffic though. Non-IPv4 protocols will still get through, including IPv6 link-local communication which is increasingly being specifically targeted by malware as a lot of firewalls (including currently, and sadly, Aerohive's IP firewall) are IPv4 only and all modern clients support and enable IPv6 by default and will therefore have link-local addresses available. Thanks to LLMNR (Link-Local Multicast Name Resolution), link-local IPv6 communication is made VERY easy.

You can however achieve station isolation at layer-2 using a MAC firewall policy configured in the user profile. If your definition of station isolation is to prevent communication to and from other devices within the same broadcast domain (both at layer-2 and layer-3), i.e. if the only things the clients need to talk are hosts that are outside of their local subnet, then all unicast traffic that we want to allow will have a destination MAC of the default gateway. With a bit of consideration for non-unicast traffic, we can achieve what we need with just a few rules.

Define a "From-Access" MAC firewall policy with two rules:

1. source "Any", destination "Default Gateway MAC", action Permit
2. source "Any", destination ff:ff:ff:ff:ff:ff, action Permit

Set the default action to "Deny". The broadcast destination is required to allow the client to ARP for the default gateway and for DHCP to function.

Also, define a "To-Access" MAC firewall policy with one rule:

1. source "Default Gateway MAC", action Permit

Set the default action to "Deny".

This is sufficient if the default gateway is also performing DHCP relay for the subnet as the DHCP replies will be sent from the default gateway's MAC address.

If you have another device performing DHCP relay for the subnet or the DHCP server is in the same subnet you will need also to add that MAC address to both the "From-Access" and "To-Access" rules to allow for the correct operation of DHCP in both broadcast and unicast modes.

If the Aerohive APs are acting as the DHCP server or DHCP relay, you can use the Aerohive OUI MAC entries rather than specifying each virtual management interface MAC individually.

If you have a need to support multicast within the subnet, you will also need to add the required multicast MAC addresses to the policies both for the multicast groups being used and for IGMP.

If your default gateway is an HSRP/VRRP virtual address, you will need to take this into account to (the HSRP/VRRP virtual MAC address should be used in the "From-Access" rule and the individual routers' interface MAC addresses should be used in the "To-Access" rule.

If the DNS server is in the same subnet, this will also need to be allowed. I would typically recommend using a DNS server outside the subnet (e.g. a public DNS server or a server in another DMZ) or using a secure DNS proxy (e.g. Palo Alto firewalls can act as DNS proxies and DHCP relays).

Now, even if a tricksy user adds a static route to another host in the same subnet with next hop of the default gateway (causing the traffic to that host to route to the default gateway and back in to the subnet), although packets sent to that host will indeed reach the host, replies will not get back (as the responses will NOT go via the gateway).

Two users who conspire and BOTH add routes to each other via the default gateway WILL be able to talk to each other at the IP-level...but in fact this is also the case for the SSID-based station isolation feature as this also operates only at layer-2. If two clients add static routes to each other via the default gateway, the AP only sees layer-2 traffic to and from the default gateway, which is not "inter-station" and so will happily forward it.

An IP firewall policy in addition to the MAC policy will allow you to further block IPv4 traffic to other subnets (for example corporate networks or other BYOD subnets) as well as blocking the above hairpin forwarding technique.

Although Nick is right that a station isolation feature is implemented inside many wireless drivers, this function can only block traffic between stations associated to the same AP (as the driver itself is only aware of other directly-associated stations - it cannot distinguish between a station connected to the same SSID via another AP and a wired device on the same layer-2 broadcast domain).

In a controller-based environment, it is the controller that enforces the station isolation further so that clients connected to the same SSID but via different APs are still isolated - provided they are controlled by the same controller. In the case of Aerohive, this is instead taken care of by the Aerohive Mobility Routing Protocol (AMRP) and the forwarding engine.

A MAC firewall policy serves to provide station isolation not only to wireless connected devices, but also prevents communication with any wired devices on the same subnet, other than those specifically allowed by the policy.

Apologies for the long post. This started out as one paragraph, then it got me thinking...
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
If this doesn't elicit a bunch of TL;DR responses, nothing will :)
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
Actually:

If your default gateway is an HSRP/VRRP virtual address, you will need
to take this into account too (the HSRP/VRRP virtual MAC address should
be specified in both the "From-Access" and "To-Access" rules in addition to the individual routers' interface MAC addresses).

Also, just to mention that if you have multiple VLANs where users may connect, you would need to add the gateway MAC addresses of each of those VLANs to your MAC policy.