pfsense

Clamping Down HARD on DHCPd MACs…

Posted on by dk

There is an eight year old issue (at the point of writing this) with pfSense DHCPd that somehow did not restrict DHCPd IP “handouts” despite the chosen setting to “Deny unknown clients”… Which, after some digging, turns out more to be of a misunderstanding than what the “common people” would think.

Despite the “Deny unknown clients” setting, certain clients requesting an IP from a pool/interface that does not explicitly list its MAC address will still get an IP address. It turns out that said client is considered “known” if the MAC is listed anywhere else (i.e. in some other MAC address list)…

Anyway, I got fed up with this seemingly insecure behaviour and managed to hack a fix… some 8+ months ago… Just that I never got around to posting the details for people willing to hack their own pfSense fix (unlike my other SSHd configuration fix which was documented in full)…

Well, to cut the long story short, the pull request (merged with another upstream fix) has now been accepted and merged (actual changes)… You will see this fix some-time-soon-now in some upcoming pfSense release… Enjoy!

2021/02/28 Update: A year later and only now is the DHCPd fixes released with a new stable release (2.5.0), instead of the expected 2.4.x! Well, it’s “finally out there”…

2021/06/01 Update: As of time of writing, it appears that 2.5.0 and 2.5.1 are, unfortunately, bugged and I do not recommend upgrading to 2.5.0/2.5.1…

2021/07/07 Update: pfSense 2.5.2 is now released… YMMV…

Forcing dhcpd On pfSense To Forget…

Posted on by dk

So I was playing around with 2 new TP-Link HS110 units I bought from Amazon, and I was attempting to swap the two with two other existing units (which had older firmware), having the two new units take the identity (name/ID and pfSense dhcpd statically defined IP addresses) of the “older” units… Review of that device aside, I was pulling my hair out because the old units kept getting their old IPs, as did the new units!

Funnily enough, the units appear to “take turns” “phoning home” – such that in the Kasa control application, there were duplicates of the old unit name/IDs shown, and it “flip-flopped” on showing the availability (and also the recorded energy consumption).

I figured it must be the DHCP service/daemon, since I kept seeing the DHCPDISCOVER and DHCPOFFER in the dhcpd logs.

Time to roll up my sleeves and fix this…

Continue reading →

Securing pfSense SSH2…

Posted on by dk

So, as exposing the HTTPS administration page of pfSense to the big, bad, Internet is a big “no no”, the only proper way should be to set up SSH2 and allow port forwarding.

Now, there are already articles out there telling you that using username+passwords to secure SSH2 is not the way to go… Using certificates is. However, I wanted more… I wanted both… Why is it that pfSense will only allow one or the other when sshd already allows enforcement of both?

So, once again, rolling up my sleeves, I dived into the murky waters of the pfSense shell…

Continue reading →