DHCP Server provider the same IP for two different VMs
-
@SteveITS yeah you would hope no dupe should be assigned. So if the 1st device was on.. the ping check dhcpd should be doing before offer should catch it and not offer what the client requested.
And then you also have the client that should be sending out a arp probe for that IP before.. client should send a arp probe and if something answers it should send a decline vs ack..
As a simple test I was going to fire up a vm.. have it get an IP, and then shut it down and change its mac and then boot it and see if it requests the same IP and gets it.. Or could just create another clone of the vm, leaving it online and then fire up the clone with different mac and see if also requests - but this time it shouldn't get it because there is something actually online with the IP.
-
This post is deleted! -
@pwood999 said in DHCP Server provider the same IP for two different VMs:
ARP before the discover as that's broadcast.
where did I say there would be an arp before discover? The dhcp server would do a ping to the IP, this could produce an arp if the IP is not in the arp cache already.
The client upon getting an offer for IP X, would do an arp probe for that IP before it sends its ack, if it gets a response to that arp probe it would send a decline instead so the dhcpd would send another offer with different IP.
I haven't seen a dupe IP issue in years and years and years - other than static duplication, ie PEBKAC.. Both dhcpd and dhclient have safety measures in place to prevent duplication. Not saying that can not happen.. But they should be rare for sure, and some sort of mitigating circumstances have to be at play.. Like disable of the features that try and prevent duplication.
edit:
Example from my previous example of client requesting a specific IP - can see that the client was probing for that IP 192.168.9.100 that it was requesting
A probe is different than a normal arp, asking hey this is IP X who has IP Y..
-
@NollipfSense
Sorry for the delay in answering. I changed the DNS, but the problem continues. -
@aloisiobilck And what does dns have to do with anything? What did you change exactly?
-
-
@aloisiobilck yeah that has zero to do with it that is for sure. And I highly doubt you want pfsense to not be able to resolve its own records.. The default is what you would most likely.. I resolve so there is nothing to fall back to.. So I use local only.. But again that has zero to do with anything..
I don't see where he told you to change that.. He said that pfsense validates host overrides..
-
Is there something I did wrong in pfsense for this to happen?
Simply the DHCP Server hands over the same IP to a new VM. -
@aloisiobilck lets go over this again.. If your new VM asks for an IP, it will get it..
Did you sniff to see if the new vm is asking for the same IP?
I specifically showed an example where box was asking for the old IP..
Please do a packet capture of the dhcp and look to see if the client is asking for the same IP.. You could prob clear up the problem by just doing a release and then renew on the client. So it doesn't ask for an old IP.
-
What is happening is the following:
I clone two VMs.- VM1 starts and gets an IP
- VM2 starts and gets the same IP as VM1.
If I go through the VM2 terminal and give a dhclient <interface> it gets a new IP.
-
@aloisiobilck I would think that duplicate ip detection would prevent that.. Did you disable that on pfsense dhcp server?
The client itself should also be doing duplication checks as well.. What specific client OS is this VM?
Is VM1 still on when you start up VM2?
-
@johnpoz I will install tcpdump to see the DHCP packets.
-
@aloisiobilck no need:
https://docs.netgate.com/pfsense/en/latest/diagnostics/packetcapture/index.html -
@johnpoz
I didn't disable it, it's the way you sent the image.
VM1 is up -
@SteveITS
I was talking about the Linux VM, sorry. In Pfsense I am aware that I must use "Packet Capture"Thanks
-
@johnpoz I'll test it with "Disable ping check"
-
@aloisiobilck said in DHCP Server provider the same IP for two different VMs:
@johnpoz I'll test it with "Disable ping check"
You want the ping check enabled. That tells pfSense to not assign an IP if anything responds to a ping. Does the firewall on these VMs allow ping?
-
@aloisiobilck where did I say to do that?
Even if this first vm doesn't answer ping, the arp probe that the 2nd vm sends out or should send out would be answered if its online.
Is the first vm still up when you turn on the 2nd vm??
What OS are you running on these VMs.. These are basic questions, that you didn't answer but jump straight to disabling the very thing that would help prevent duplicate IPs..
There are a billion flavors of linux - they can all have different dhcp clients, etc.. What distro are you running, so can look - and or even try duplicate exactly what your doing with the same OS..
-
answering your questions:
- OS is Ubuntu 22.04
- VM1 is UP (running) when I turn on VM2.
- "ping check" is enabled. I misunderstood, sorry!
-
@aloisiobilck so I have a ubuntu vm 22.04.. Let me try and duplicate your issue.
edit: take that back my clean vm I use for new vms is only 20.04, grabbing 22.04.3 now.. server - don't want/need desktop and will install it clean.. And then clone it and see what happens.
edit2: ok I have duplicated your problem..
I created a vm, ubuntu 22.04.3 LTS, min server install. updated it.. And installed the net-tools so I could use ifconfig.. Rebooted it, etc. Then shut it down.. Cloned it..
And yup duplicate IP.. 192.168.3.117.. This shouldn't happen I agree with you.. It is a different mac, and the duplication systems in both dhcpd and the dhcp client should prevent this.
Now I did start a packet capture before I booted the first vm, and left it running while booted the clone.. Let me look at the capture and see what is not happening.. The client for sure should of done an arp probe and not agreed to the IP that was in use..
edit3: ok yeah this weird.. So the clients are never sending an arp probe - which they should.. And I only see a ping test from pfsense once, when the first machine boots.. I don't see another one when the 2nd vm asks.. But there is no answer to the first one..
But since the client is a clone - it does have a duplicate client ID.. Hmmm
Going to have to look at this for a bit.. Going to look first to why ubuntu dhcp client isn't sending an arp probe before it accepts that IP..
edit4: Ok figured out what is going on.. stupid if you ask me.. No wonder I always have disabled netplan in the past.. Seems they use the duid and IAID to create the client identifier since prob back in version 18.. And since you cloned - its the same.. I changed my 2nd vm to use mac..
And now it gets a different IP.. .118
So yeah seems cloning could cause what your seeing for sure.. But there is a quick work around for you.. There prob a way to have it generate a different identifier when you clone the vm.. And want to look into having it send the arp probe as well.. I was thought from the rfc it was a "must" that client send arp probe for duplicate IP detection.. But seems its really only a "should" and ubuntu figures they shouldn't I guess ;)
The docs for netplan can be viewed here..
https://netplan.readthedocs.io/en/latest/netplan-yaml/Not sure if that is the official place - but was first place I found that had the info about netplan I was looking for.
Glad you mentioned that you using 22.04, since then I was able to duplicate.. My linux vm isn't using netplan :) so it sends a mac as the identifier..
edit5: another way to fix it vs switching to mac, is change the machine-id.. You should be able to do that with deleting /etc/machine-id and then running systemd-machine-id-setup
Now the client ID sent via dhcp discover should be different than your other VM.. And shouldn't get a dupe.
edit6: just to validate.. I removed the mac setting from the yaml file from above.. And after I did that change in the machine-id, it did send a different identifier and did get a different IP as well..
This was fun! Still not a fan of netplan - but learned more about it.. I guess just old school ;)
