Afgelopen week zag ik dat Netgate een nieuwe versie van pfSense CE (2.9.0) had uitgebracht. Ik gebruik deze software al jaren als router/firewall in plaats van de standaard door internetproviders geleverde routers. De upgrade verliep soepel: na een klik op de knop ging het helemaal automatisch en na een herstart werkte alles direct weer.
De volgende dag meldde SolarEdge echter dat de verbinding met de zonnepanelen was verbroken; de omvormer kreeg geen DHCP-lease. Op de Cisco-switch stond de poort waar de omvormer op aangesloten zat vrolijk te klapperen tussen verbonden en niet-verbonden. Kabels gecontroleerd, poort gecontroleerd, maar nog steeds geen DHCP-adres. Een andere poort met een ander VLAN gaf geen probleem, maar terug op het oorspronkelijke VLAN was er wederom geen DHCP-adres.
Na uren zoeken — waarbij AI overigens heel behulpzaam kan zijn, maar je soms ook compleet de verkeerde kant op stuurt — leek alles naar behoren te werken, behalve dat het in de praktijk niet werkte. Inmiddels begonnen er meer apparaten in huis te sputteren, waardoor de SolarEdge al snel niet meer de enige verdachte was.
Uiteindelijk zag ik in de instellingen van pfSense CE 2.9.0 dat je de loginstellingen voor de Kea DHCP-server nu hoger kunt zetten. Hieruit kwamen regels naar voren zoals:
failed to allocate an IPv4 address after 50 attempt(s)
Het getal 50 bleek precies overeen te komen met de hoeveelheid beschikbare leases in mijn ingestelde pools. Oftewel: er was zogenaamd geen enkel adres meer beschikbaar in de range. De melding was onjuist, maar de knop “Clear All DHCP Leases” bleek de verlossende oplossing.
Of dit een eenmalig probleem is na de upgrade, moet nog blijken. Voor een klein netwerk zoals bij mijn thuiskantoor raken vijftig adressen per VLAN normaal gesproken natuurlijk niet zomaar vol. Maar in grotere omgevingen kan dit wel degelijk een probleem worden als het vrijgeven van leases niet goed gaat en er ‘onzichtbare’ adressen achterblijven.
Daarom bij deze een korte tip, mocht je tegen hetzelfde probleem aanlopen!