Change of behaviour with Static Mappings
-
Morning, all.
We upgraded to 2.1.5-RELEASE (i386) a little while ago and have found an irritating change in behaviour. To explain…
We all operate off Laptops here and have the ability to connect via WiFi or cabled. Due to various internal biz requirements, several machines need to be allocated the same IP regardless of the interface they connect with. Previously, we could bind the same IP to 2 MACS (2 entries - "Jon's Laptop (Wired)" and "Jon's Laptop (WiFi)"), but on setting up a new user, we discover that we cannot do this anymore as it complains about a duplicate IP.
Anyone else notice this? Whilst we can see a valid reason to detect and prevent creation of a record if the MAC is duplicated, surely the Hostname and IP should be allowed again...
Any tips on how to cheat and create duplicates pending a (hopeful) reversion of behaviour?
TIA,
Jon
-
What you should be looking to do is change your idiotic biz requirements ;) From a security standpoint it shouldn't even be possible to have the same IP since wifi and wired should be on different segments so you can firewall between what is inherently less secure connection medium - wifi vs a wire, etc. Is possible for someone to sit outside your offices and connect with wifi, while with a wire they have to be on site, etc..
If you wanted, you could give same octet to the device be it wired or wireless, for example wired they might be 192.168.1.42, while wireless 192.168.2.42, etc..
Only the smallest of the smallest ma and pa shops, would have wifi and wired on the same segments - those just plugging in AP with no one in IT to correctly configure their network ;)
If you really want go down this path, why don't you just edit the laptops to have the same mac on their wired and wireless interfaces..
-
Not sure that requiring a workstation to have a static IP is an idiotic biz requirement and I wouldn't class ourselves as a small Ma & Pa shop either - I'd imagine they'd not be running pfsense in the first place…
Still, I hear what you're saying about segregating the WiFi net, but back in the real world with a two story office that's a grade 2 listed building and people moving between rooms / teams on a daily basis we need to take a pragmatic view of risk (don't make assumptions about how we auth our WiFi either!).
Point was this has changed from earlier releases and I'm wondering if this is for a reason that I've failed to fully appreciate. We can allow statics on WiFi only, but it'll be a bit of a backward step.
Thanks for your feedback anyway ;)
-
That input validation has gone back and forth in the past, though generally yeah we try to keep that scenario usable for the reasons described. I'll check 2.2 more closely later, but it appears to prohibit that as well. You can remove the input_error line in /usr/local/www/services_dhcp_edit.php that contains the text of that error (or just add // in front of it to make it a comment) and you'll be able to configure that again. Though be careful as that removes more input validation than is desirable possibly.
-
That makes sense - thanks for the steer. We'll give it a crack tomorrow and see how we get on.
Cheers,
Jon
-
What does the building grade and or users movements have to do with wifi being on its own segment?
A dhcp server should not allow reservation of the same IP to different macs - this is in conflict with the very nature of a reservation ;) Especially with wifi - clients go off the network in a instant - move out of range for example. Now they didn't release the lease.. Now the wired mac shows up.. But the lease has been given and has not yet expired to the other mac.. See my point!
If you want to go this route - then on your laptops, change the MAC of one of the interfaces to be the same.. Takes 2 seconds to do.. Now you only have 1 reservation on the dhcp server.. 1 IP to 1 MAC - no conflict. Your laptop gets the same IP no matter if using wireless or wired.
I would most likely have the laptops setup to turn off wireless on wired connection, most every someone modern laptop I have seen supports this.
Having pfsense not do checks for an invalid dhcp server setup is not the correct direction to go in.. If you want to remove code to prevent the check, that is on you - but I really would not remove the check from the default release.
Better solution is segment your wired from your wireless network!
-
I can't begin to list the ways that setting the MACs the same for both adapters is a bad idea…
It may be dhcpd abuse, but the problem's resolved thanks to cmb's reply; everything working just fine the same way it has for years :)
Jon