Project

General

Profile

Bug #8334

Forwarding broadcast through firewall can cause broadcast storm

Added by Sam Bingner over 1 year ago. Updated over 1 year ago.

Status:
Not a Bug
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
02/16/2018
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.4.2_1
Affected Architecture:

Description

I had a secondary IP on a windows system to test connectivity to a proprietary system. When it was added to windows, windows was kind enough to send out a netbios broadcast to port 137. I, unfortunately, had an allow all outgoing rule in my firewall that did not have the source locked down to only the LAN subnet. This allowed the firewall to pick up the broadcast and send it out my WAN interface. It then picked it up with the secondary firewall ON THE WAN INTERFACE, where there were no rules to allow it, and broadcast it back out the WAN interface again. This repeated ad infinium and caused a broadcast storm. The only states that were somehow allowing this were on the LAN interface.

I have mitigated the issue by only allowing LAN source addresses out from my LAN, but it seems that there should have been something to stop such a broadcast storm, it did not seem to be properly decrementing the TTL but I did not verify that as my tcpdump did not include the TTL and I don't want to induce a new storm to bring down the connection. There were very few broadcasts from the LAN side, I didn't find it in tcpdump within 20 seconds but only found it in the state table.

00:10:05.371079 xx:xx:xx:xx:xx:xx > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 172.20.200.201.137 > 172.20.200.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

States
Interface    Protocol    Source (Original Source) -> Destination (Original Destination)    State    Packets    Bytes    
LAN    udp    172.20.200.201:137 -> 172.20.200.255:137    NO_TRAFFIC:SINGLE    5.341 M / 0    397.30 MiB / 0 B    
LAN    udp    172.20.200.201:60728 -> 239.255.255.250:1900    NO_TRAFFIC:SINGLE    1 / 0    202 B / 0 B

Firewall is x86_64 on VMware, running latest 2.4.2p1.

History

#1 Updated by Jim Pingle over 1 year ago

  • Status changed from New to Not a Bug

The firewall in this case does not have any knowledge that the packet is broadcast. It does not know the subnet directly. You cannot always assume that the last IP address in a subnet is used as a broadcast, nor can you assume that every subnet is a /24. For example .255 is a valid address in the middle of a /23. Also, pf cannot inspect the MAC address so it cannot tell that the destination is broadcast in that way, either.

We have seen similar issues with APIPA traffic in the past (See #2073)

The solution is to use proper rules to control your traffic.

#2 Updated by Sam Bingner over 1 year ago

All that I understood, the part I think was a bug was it continuing to accept the packet on the WAN interface when there was no rule that should have allowed it.

Also available in: Atom PDF