DHCP Server wrong function / crash by adding Static Mapping in another VLAN
-
Some weeks ago I registered two Smart Plugs in the Guest wifi ( Guest VLAN ). Yesterday I found the time to move them into the IoT wifi ( IoT VLAN ). First I reseted settings on both devices, then registered them in the IoT wifi. But under "DHCP Leases" I found today both with IP-Adresses from the Guest VLAN.
Thought, it is an old DHCP-lease which is valid for 24h and decided to accelerate the change. Added Static Mappings for both clients in the IoT VLAN. It seemed to work, the status was "online". Some time later I noticed, that my Smartphone, which I was using to configure Smart Plugs, lost the wifi connection. After restarting AP's all wifi clients lost connections. After reboot of pfSense nothing worked anymore, neither LAN clients.
It took me all day to understand why my whole network was broken. Since few minutes I know the reason: config reset and registration in new wifi on the Smart Plugs doesn't work. They are still registered in the Guest wifi. When adding a static mapping in the wrong VLAN, the DHCP Server on pfSense crashes or hangs an all interfaces without any error message.
I was able to reproduce the problem several times today. Connected with serial cable, restored previous configs and rebooted pfSense. When pfSense starts with wrong static mappings, there are no errors, no problems in the PuTTY-Console, DHCP service starts also, but I didn't get even a LAN-connection, because almost all clients and AP's are using static mappings.
I would expect from the DHCP Server to bring an error message and/or to separate threads for each VLAN, so a problem in one VLAN wouldn't affect others.
Regards
justas
-
@justas said in DHCP Server wrong function / crash by adding Static Mapping in another VLAN:
I was able to reproduce the problem several times today.
Your going to have to explain what your doing exactly... Read this like 3 times - not sure what your doing... Post pictures!!
-
Trying again without unnecessary details.
Added a static DHCP mapping to the client 192.168.20.25. DHCP Server on pfSense crashes or hangs an all interfaces without any errors.
Hope, it is clear now.
-
@justas said in DHCP Server wrong function / crash by adding Static Mapping in another VLAN:
Added a static DHCP mapping to the client 192.168.20.25. DHCP Server on pfSense crashes or hangs
No it doesn't... I have reservations (static mappings) on all of my vlans..
Here are examples from 3 of my different vlans... There are more vlans and more reservations - but you get the picture from this
I change these, I add more - even move devices from 1 vlan to another all the time... Never seen any issues with this at all.
Is that switch actually vlan aware? And setup for your vlans?
Here are some reservations for a couple of my smart plugs
-
I have also a lot of static mappings. The feature itself works fine.
The problem is, when the user (in this case me) makes a mistake. A client was registered in Wi-Fi 10, VLAN 10. But I added the static mapping in VLAN 20. Please try it!
When the client gets a Wi-Fi connection, it receives automatically DHCP-Address from VLAN 10. But manually I added a mapping in VLAN 20, which causes the deadlock.
-
It won't let you add wrong IP..
I can for sure take that mac address, and create a mapping for it in a different vlan
Here
If you are having some issues - you going to have to show EXACTLY what your doing..
Now if that client connects to that vlan - they would get that IP..
I have had in the past, not sure if still do - but could for sure duplicate it.. have multiple reservations for the same mac in each vlan... So when connects to vlan X gets that IP in X, and when connects to Y, gets IP in Y subnet.. Use to do that with my Ipad..
here - just looked, my work laptop has reservations in 2 different vlans, my guest wifi and my psk wifi
Depending on which ssid it uses, it gets IP that reserved IP in that specific vlan.
I did this specifically so I always knew what IP my work laptop was, so I could create firewall rules for it depending on what network it was connected too.
-
Depends on how you opened the dialog!
If I click on "+" in the "DHCP Leases" and enter an IP from a wrong VLAN, I get exactly the error you posted.
But I created the mappings directly from the "DHCP-Server"/VLAN:
That dialog didn't bring any errors, mappings were created.
-
No same error.. Those IPs are in the same subnet..
Clicking that add button takes you to the same place as if you clicked on the add button in the current dhcp leases.. When you click it in the dhcp leases, its just going to take you to the dhcp server for whatever vlan that IP is currently in, and prefill the mac address for you.
Are you changing the IP subnet of the interface, after you have created the statics?
example
192.168.100.0/24 on vlanStatic mapping
192.168.100.100 for some client.Then change the interface to 192.168.200/24 or something... then yes those mappings would be wrong.. But it warns you about changing your IP range, etc. And while the dhcp mappings are wrong - is that what your doing?
So no that client sure wouldn't work... But other dhcp clients in different vlans would be fine... After I created the bad scenario... clients still getting their dhcp leases, etc..
Dec 28 10:13:56 dhcpd DHCPACK on 192.168.7.109 to f4:06:16:4f:f6:36 (Johns-XR) via igb5 Dec 28 10:13:56 dhcpd DHCPREQUEST for 192.168.7.109 from f4:06:16:4f:f6:36 (Johns-XR) via igb5
-
@johnpoz said in DHCP Server wrong function / crash by adding Static Mapping in another VLAN:
I think, I know now, what happened.
I tried to create a Static Mapping from the "DHCP-Leases" page, but received the error. Then I removed the DHCP-Lease from /var/dhcpd/var/db/dhcpd.leases. The client was not known anymore in any VLAN. After that I was able to create a Static Mapping in VLAN 20 without errors in the "DHCP-Server" page.Then I connected the client and it received an IP-Address from the VLAN 10. But the registration in VLAN 20 war still valid.
That caused probably the deadlock in the DHCP-Server!
-
NO it doesn't work that way... I have no idea what you did to be honest, or think you did, or what you think was going on. But none of your scenarios about creating leases in the wrong vlan have anything to do with it!!!
There is nothing stopping you from creating a static for a client, even if it holds another lease. etc. etc.. There is nothing wrong with a client having a lease in vlan X, and a static for it in vlan Y, etc. etc..
Now what is possible is these iot devices once they get an IP, don't like to give it up or even ask for another lease.. Nest are like that - once they get an IP, they won't even ask to renew the lease, etc. Horrible design flaw on their part (atleast a while back - hopefully that fix that issue in future firmware).. To get them to change IP you have to reset the network on them and start over..
Maybe something like was happening with your smart switches?
if a client has a lease in vlan X, and then moves to a different network - vlan Y it will ask for its old IP, the dhcp server would tell it no wrong network... And then it should send a discover out and get an IP in the network its in.. If the client doesn't do that - that is on the client, etc.
That happens ALL the time when say your laptop moves from network, it says oh I had this IP before, can I reuse it.. Just sniff the dhcp traffic and you will see that yourself, etc.
-
Last idea.
When creating the static mapping, I was able to use double quotation mark in the cliend-id. I just tried it again, it works. The Log with the error is attached.
dhcp-log.txtThree days ago I didn't look into the DHCP-log, was assuming the error everythere, but not in the DHCP-Server.
Could it be, that after restart and failed parsing of dhcpd.conf, no clients receive any IP-Adresses?Can that be the reason of my problems?
-
@justas said in DHCP Server wrong function / crash by adding Static Mapping in another VLAN:
I was able to use double quotation mark in the cliend-id.
Thought you said there was no error in the dhcp, and it was running, etc.
No shit if the dhcpd is not running nobody could get IPs, or if it fails to parse its conf and runs with no settings... Then again nobody would get IPs either... This is not what you stated!!!
