Can't stop broadcast - specifically udp 137

  • 1
  • Question
  • Updated 2 years ago
Hive Manager 6.6r3 and HiveOS 6.5r3

I have a user profile that puts users on VLAN 1 with they attach to a given SSID.  I have IP firewall rules set up on that user profile to block NetBIOS traffic going to and from and on the user profile under 'IP Firewall Policy' the 'Default Action' is set to 'Deny'.  There are also some wired clients on VLAN 1.  I don't know what else I can do, but I can not stop NetBIOS traffic coming from the wired clients showing up on a packet capture taken from a Wireless client on that wireless network using that user profile.  It isn't a big deal with NetBIOS, but it really worries me that I can't stop a particular type of traffic.
I have changed the config of the SSID and told it to disable broadcast and multicast traffic forwarding onto wireless, but that only seems to break DHCP traffic until I add a specific rule to allow DHCP traffic, again no big deal.  Here are the IP firewall 'To' and 'From' rules that I have in place.  Just to make sure I knew for sure how the NetBIOS traffic was defined, I made my own custom network services. Can someone please tell me what I am over looking here.  Many thanks.
=======Custom Network Services=========
service NetBIOS_NS protocol udp port 137 timeout 60
service NetBIOS_SSN protocol tcp port 139 timeout 1800
service NetBIOS_DGM protocol udp port 138 timeout 60
================
=======IP Firewall=========
ip-policy VLAN1_To
ip-policy VLAN1_To id 3 from 0.0.0.0 0.0.0.0 to 0.0.0.0 0.0.0.0 service DHCP-Client action permit
ip-policy VLAN1_To id 2 from 0.0.0.0 0.0.0.0 to 0.0.0.0 0.0.0.0 service NetBIOS_NS action deny
ip-policy VLAN1_To id 4 from 0.0.0.0 0.0.0.0 to 0.0.0.0 0.0.0.0 service NetBIOS_SSN action deny
ip-policy VLAN1_To id 5 from 0.0.0.0 0.0.0.0 to 0.0.0.0 0.0.0.0 service NetBIOS_DGM action deny
ip-policy VLAN1_To id 1 from 0.0.0.0 0.0.0.0 to 172.20.16.0 255.255.240.0 service any action permit
ip-policy VLAN1_From
ip-policy VLAN1_From id 3 from 0.0.0.0 0.0.0.0 to 0.0.0.0 0.0.0.0 service DHCP-Server action permit
ip-policy VLAN1_From id 2 from 0.0.0.0 0.0.0.0 to 0.0.0.0 0.0.0.0 service NetBIOS_SSN action deny
ip-policy VLAN1_From id 4 from 0.0.0.0 0.0.0.0 to 0.0.0.0 0.0.0.0 service NetBIOS_DGM action deny
ip-policy VLAN1_From id 5 from 0.0.0.0 0.0.0.0 to 0.0.0.0 0.0.0.0 service NetBIOS_NS action deny
ip-policy VLAN1_From id 1 from 172.20.16.0 255.255.240.0 to 0.0.0.0 0.0.0.0 service any action permit
================
Photo of rbentley

rbentley

  • 12 Posts
  • 0 Reply Likes

Posted 2 years ago

  • 1
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
If the subnet in question is 172.20.16.0/20 then surely the very first rule will allow the broadcasts (to the subnet broadcast address, 172.20.31.255)?
Photo of rbentley

rbentley

  • 12 Posts
  • 0 Reply Likes
Hi Roberto,
Thank you for your reply.  I read through the documentation for the IP Firewall Policies and I understood it to say that it evaluates the rules in order from top to bottom.  In the GUI the top rule is the one that allows DHCP traffic, I have the permit rule for all traffic to and from the subnet at the bottom, so I thought that the NetBIOS traffic wouldn't make it to the bottom rule.
Did I misunderstand the way the IP firewall polices evaluate traffic?
Is there a way to see what rule is allowing specific traffic in HiveOS?
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
I was making the (incorrect) assumption that the ID parameter on the CLI reflected the ordering of the rules. That'll teach me! Instead, the rules seem to get added in order (but if you want to "insert" a rule on the CLI directly, you can use the "before id" or "after id" options to do that).

You can confirm on the CLI by doing "show ip-policy VLAN1_to". You can also turn on logging for the rules to see when they are being hit.

So in principle, I can't see why the above rules should not deny the traffic. You obviously could be more specific and specify source IP as 172.20.16.0/20 and destination IP as 172.20.31.255, but this shouldn't be necessary.

I'm going to do some testing now on my AP here and I'll let you know the results.

Was the behaviour the same on an older version of HiveOS, or have you only tested this on 6.5r3?
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
Hmmm. Yes, I see the same behaviour. I've never tried to suppress IP broadcasts with a firewall policy before, so haven't looked at this in detail up until now...though I probably should have!

I think this might be "as designed" behaviour for broadcast traffic originating from the backhaul network.

There is a logic behind that. As it would be possible to have multiple user-profiles associated with the same SSID and VLAN but with different assigned firewall policies, and as broadcasts can and will be received by all stations associated with the SSID regardless of which user-profile (or indeed VLAN) the station is "in" - this is because of the nature of the way broadcasts are transmitted in 802.11 - it wouldn't be possible for the AP to allow broadcasts to some stations while denying broadcasts to others.

From my testing, it looks like the "to access" firewall policy does not apply for packets where the destination MAC address is ff:ff:ff:ff:ff:ff - they are just allowed. This is corroborated by the fact that I also never see the forwarding engine create a session for "allowed" broadcasts from the backhaul network, while it does do so for "allowed" broadcasts from the access to the backhaul.

As of 6.6, you have the option in the SSID Advanced Settings (which you mentioned in your post):

"Disable multicast and broadcast traffic forwarding onto wireless"

This will block ALL multicast and broadcast traffic from being forwarded from the backhaul network to the wireless network (i.e. it reverses the "always allow broadcasts" logic described above). This shouldn't break ARPs because the AP converts ARP requests to directed unicast ARPs for stations it knows about, and it shouldn't break DHCP provided your DHCP server/relay agent isn't configured to broadcast (and of course provided your DHCP server isn't a wireless device!). But obviously it's a bit of a brutal setting.

From my testing, with this setting configured, the NetBIOS and other broadcasts are indeed suppressed. Is this not the case for you - it wasn't clear from your original post.

I guess what you're looking for is an SSID-level (rather than user-profile level where it doesn't make sense) option to SELECTIVELY block IP broadcast traffic, but I don't think that's possible currently.
Photo of rbentley

rbentley

  • 12 Posts
  • 0 Reply Likes
Hi Roberto,
You are correct.  I would like to block this at the SSID-level not the user-profile level.  I just thought the only way to do this was to try at the IP firewall level since the "Disable multicast and broadcast traffic forwarding onto wireless" didn't seem to be working for me.  I am going to try making a fresh SSID and test to see if there might be something not working properly with the SSID I am using.

I have tested this in previous HiveOS versions though and experienced the same behavior of still seeing broadcast and multicast traffic.  I haven't tested it with HiveOS 6.6r1 yet.  I had tried updating to that a few months back and had some unexpected behaviors with some clients and "Client Classification Policies".  I haven't gotten back to trying to see what the issue was yet, I just rolled the HiveOS version back on the AP230s.  It was crazy busy then and the problem effected a good portion of our resident students here.

I had also tried creating an IP Object of '172.20.31.255', just to see if I could block traffic to and from that with an IP firewall policy, but the Hive Manager won't let me create that, it just tells me that the IP is in an invalid format.  Oh well.

I will post back once I create a new SSID and test.

This really isn't a big deal though most of the time.  The main reason I even found this is because we have some new Lenovo computers that have an issue with their drivers.  When 2 or more go to sleep they crush our network with IPv6 multicast traffic, stupid bug I know.  Our software folks have it mostly taken care of, but every so often someone will use an old image to load a few computers, then when those computers go to sleep all hell breaks loose. :)  It isn't to bad for the other wired computers on the network depending on how many different machines are blathering away, but just a few will make the wireless network unusable.  On that part I know I am looking in the wrong place for a solution for the underlying issue, which is a bad wired NIC driver and too large of a broadcast domain.  Both of which are slowly being fixed.  I just thought it was weird that I still saw the NetBIOS broadcast traffic after taking the steps I already have.

Thanks for you time in looking at this though.  I really appreciate it.