One of many purchasers I work with makes use of a pfSense system and Ubiquity {hardware} to energy their separate unattributed analysis strains, however nonetheless have it arrange as an ordinary Enterprise grade community. This community exists separate from their regular “company” community however is a crucial enterprise operation for one of many packages.
Lately, the analysis line was linked to and arrange for Cell Malware, that may be a single Ubiquity AP broadcasting 5 wifi networks for the Cell Malware initiative (sure, this shopper captures packet site visitors, exercise, and so forth. and extracts indicators and offers them to companions to safe their networks with). Whereas each different hard-wired gadget on the community works completely, the wifi facet of issues has some MASSIVE DHCP VLAN leakage and I am not solely positive why.
This can be a tough diagram of the community between the AP and the pfSense equipment (which handles DHCP and all IP routing on this analysis community setup):
When any gadget on vlans 640 by way of 645 request DHCP, it finally ends up that that’s obtained on the pfSense gadget, however then it sends a DHCP NAK for all different VLANs besides the VLAN the gadget is on. This ends in it the Edge swap forcibly disabling site visitors on the trunk line to the Ubiquity AP as a result of it seeing greater than 300 packets per second (pps), probably as a result of there’s over 40 DHCP packets in response to the preliminary REQUEST packet, and since the shopper endpoints or some config choice someplace is damaged the shopper is resending the request after which we’re getting further spam from the identical ACK/NAK chain being resent.
This was evidenced once we checked out client-side packet captures on a Home windows machine to try to see what was taking place beneath the hood with DHCP packets and we get this (particular identifiers of {hardware} addresses and IP area are blacked out):
The opposite IPs within the NAKs are the DHCP server on the pfSense on all VLANs on the interface responding, which is Not Regular habits.
The pfSense has no particular configurations on the ethernet port, and the port is a single bodily port, there isn’t a virtualization at play.
I am unsure the place to take a look at subsequent – the pfSense configs, or the community config in Ubiquity – to see why that is taking place. Does anybody have any concepts of what could be flawed or how we are able to cease VLAN leakage on this method for BROADCAST packets?