Bug #8334
closed
Forwarding broadcast through firewall can cause broadcast storm
0%
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.
Updated by Jim Pingle almost 7 years 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.
Updated by Sam Bingner almost 7 years 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.