Pathological packet causes saturation of limiters

RobEmery

Hello,

I'm not too sure whether this belongs in here or in the CARP section however:

Setup:
There are two pfSense boxes on a CARP setup with two upstream links, WAN1 and WAN2 (WAN1 is used by default, WAN2 is our failover connection). The WAN links are traffic shaped to 10Mbps. Let WAN1 network be 198.51.100.0/28,
with a default route to 198.51.100.1, which is the upstream router. The LAN network is 10.0.0.0/16.

Incident:
A laptop was plugged in to the LAN network and had the following configuration:
IP: 172.16.2.1
MASK: 255.255.255.248
GATEWAY: none

This laptop generated NetBIOS traffic destined to 172.16.2.7. On the LAN interface the source MAC address was the MAC address of the laptop and the destination MAC address was FF:FF:FF:FF:FF:FF. The packet capture performed
on the WAN interface, showed the same packet being broadcasted continuously on the 198.51.100.0/28 network, with source IP 172.16.2.1, destination IP 172.16.2.7, source MAC address was the MAC address was alternating between
the primary's and secondary's WAN1 interfaces, whilst the destination MAC address was still FF:FF:FF:FF:FF:FF. It would appear that the packet was bouncing between the two firewalls leaving no bandwidth remaining on the
limiters.

We triaged the issue by unplugging the WAN interface on the secondary, thus breaking the loop.

Question:
I don't understand why the destination MAC address of the packet was still broadcast, instead of unicast to the upstream router (198.51.100.1, which would have dropped the packet). Short of blocking source addresses
outside of the LAN network on the LAN interface, I also don't see any way of preventing this behaviour?

Many Thanks,
-Rob

doktornotor

@RobEmery:

Short of blocking source addresses outside of the LAN network on the LAN interface, I also don't see any way of preventing this behaviour?

This (any many others) are preventing by using properly configured "smart" switch. pfSense won't protect your from someone plugging in a rogue DHCP server either.

RobEmery

@doktornotor:

This (any many others) are preventing by using properly configured "smart" switch. pfSense won't protect your from someone plugging in a rogue DHCP server either.

This is true; however I wouldn't expect PFSense to save us from a rogue DHCP server for example, I would expect it to not rebroadcast packets between differing networks?