The issue I am facing: I want to use Pi-Hole as my dhcp server but my modem (xfinity xb7) wont allow me to change my DNS settings. I also can't disable the DHCP server on my modem.
Details about my system: I am running Pi-Hole off of a raspi os VM with the vm network set to bridged mode. If I turn my modem to bridged mode can't I technically use Pi-Hole as the DHCP server?
What I have changed since installing Pi-hole: Just added domains to be blocked. Nothing network related.
small note, will my xfinity account get put on a hold if I go and setup pi-hole? My dad is way too worried that our account would get suspended.
I tried this on an old LTE modem Huawai E5170s-22 - doesn't work.
used an IP range of two IPs for the DHCP server of the modem (just one didn't work). Those are already statically configured on two of my devices and in use (192.168.3 - 192.168.1.4).
defined a range outside of this two IPs on Pi-hole and activated DHCP server
result was that the DHCP server of the modem gave a lease for those two IPs to random other devices, although the IPs were already in taken. caused a mess in the network off course (ip conflicts).
The IP address ranges of your router's and your Pi-hole's DHCP server must not overlap.
For example:
a) Set Pi-hole's DHCP range to start with 20 and end with 220.
b) Set the router's DHCP range to start with 2 and end with 2 (or 3, if it doesn't allow 2).
c) Assign the .2 address to Pi-hole's host machine, as fixed IP address / DHCP lease reservation in your router, and statically on-device (optional).
You may have to restart your Pi-hole host machine before its IP address changes take effect.
Likely, that would have indicated a misbehaving client.
IP conflicts may well happen if you define an IP address statically on device, with increased likelihood when that device is not on the same link as the DHCP server that handles conflicting leases. (click for more)
The DHCP protocol tries to safeguard against that by ways of duplicate address detection (DAD): During DHCP lease negotiation, a client(!) is expected to perform DAD, and if the client detects that IP address is already in use, it must decline the DHCP lease offer.
Some clients may work with a very short timeout for DAD or skip it completely, in order to join a network more quickly.
(And similar would apply if the very same IP address is statically defined on-device on two separate machine. The machine that comes up second should detect that its self-designated IP address is already in use, and auto-configure a link-local IPv4 (range 169.254.0.0/16) for itself if it isn't set up to request a DHCP lease.
IP address conflicts caused by such a duplicate static on-device configuration can only be resolved on the client side, by adjusting the on-device configuration.)
One way to address a mismatch between server-side managed and client-side static IP definitions is to configure the DHCP server with a respective DHCP lease reservation for the MAC and fixed IP in question, either instead of or in addition to the existing static on-device definition.
So if your router, lofty155, is handling a .2 to .3 range, make sure to configure a DHCP lease reservation for that .3 also, so it wouldn't hand out the .3 to arbitrary clients.
