DHCP Reservations not working?

heper · Apr 3, 2016, 9:23 PM

I just came to the forum looking for someone else with the same problem. There's a major problem with DHCP reservations, indeed!

ok. post screenshots of the configuration & packet-captures when a clients asks/receives a lease

johnpoz · Apr 4, 2016, 1:23 AM

Running latest 2.3

2.3-RC (amd64)
built on Sun Apr 03 14:24:26 CDT 2016

On esxi 6u2

My boxes don't seem to be having any issues with reservations..

I just deleted my reservation, got a new ip in my pool 192.168.9.225… I then created a reservation for .100, released and renewed my lease on the client and big bang zoom got my 192.168.9.100 as I had setup.. As the correct domain, everything..

If you say your not even getting the correct domain - sure you don't just have another dhcp server running on your network..

cmb · Apr 5, 2016, 5:09 AM

Everything here works fine. Sounds like the usual expecting a client renewing its existing lease to not have that lease renewed. That's not how dhcpd functions, if a machine asks for its existing lease to be renewed, it'll be renewed. A release and renew on the client will obtain its reservation.

Bradford1040 · Apr 5, 2016, 5:33 AM

@browncoat:

@heper:

unrelated to your problem but:

The DHCP server is using the full 10.0.0.0/8 range

you need more then 16million ip's in the same broadcast range ?

Why limit yourself unnecessarily?

Tell the truth I set my network mask to /8 as well, felt having no limits "EVER, lol" was the way to go. After all I plan on running multi WAN and hosting, but 16 million is a bit excessive lol. But I am running 2.3 in Proxmox-VE and no DHCP issues at all.

Derelict · Apr 5, 2016, 6:09 AM

The main reason not to do it is address space collisions. If you set up a VPN into your network, it'll be broken from any location using 10/8, 10.x/16 and 10.x.x/24. That's a LOT of places.

But other than that it really doesn't matter what the subnet size is in a broadcast domain. It only matters how many actual hosts are on it.

(No DHCP issues here either.)

Bradford1040 · Apr 5, 2016, 6:44 AM

@Derelict:

The main reason not to do it is address space collisions. If you set up a VPN into your network, it'll be broken from any location using 10/8, 10.x/16 and 10.x.x/24. That's a LOT of places.

But other than that it really doesn't matter what the subnet size is in a broadcast domain. It only matters how many actual hosts are on it.

(No DHCP issues here either.)

Wait so if my home is 10.0.0.1/8 and work is the same VPN wont work?

Derelict · Apr 5, 2016, 6:50 AM

Not without Herculean effort and much added complication.

phil.davis · Apr 5, 2016, 6:56 AM

Yep - if home is 10.0.0.1/8 (LAN IP) and thus all your home devices are in 10.0.0.0/8 somewhere, then when they want to send to anything else with a "10" address they will deduce that the target system (e.g. at 10.20.30.40) lies in the same subnet. So the home device will just do ARP locally to try and find the target system. pfSense (or any router) won't even get a chance to see anything.

If you are VPNing to work directly from a VPN client on a home device, then you might get lucky if it gives itself a route through the VPN to the work subset of "10" (e.g. 10.20.30.0/24) and then the local device network stack works out to send stuff in 10.20.30.0/24 across the VPN, even though it is part of the local LAN also. But of course if you have an actual device on your LAN at 10.20.30.40 then you can never get to both!

You are much better off choosing a "random" bit of private address space, of the size you reasonably need, so as to minimize the chance of a conflict if you have incoming or outgoing VPN links to/from pfSense or local client laptops…

Bradford1040 · Apr 5, 2016, 7:02 AM

@phil.davis:

Yep - if home is 10.0.0.1/8 (LAN IP) and thus all your home devices are in 10.0.0.0/8 somewhere, then when they want to send to anything else with a "10" address they will deduce that the target system (e.g. at 10.20.30.40) lies in the same subnet. So the home device will just do ARP locally to try and find the target system. pfSense (or any router) won't even get a chance to see anything.

If you are VPNing to work directly from a VPN client on a home device, then you might get lucky if it gives itself a route through the VPN to the work subset of "10" (e.g. 10.20.30.0/24) and then the local device network stack works out to send stuff in 10.20.30.0/24 across the VPN, even though it is part of the local LAN also. But of course if you have an actual device on your LAN at 10.20.30.40 then you can never get to both!

You are much better off choosing a "random" bit of private address space, of the size you reasonably need, so as to minimize the chance of a conflict if you have incoming or outgoing VPN links to/from pfSense or local client laptops…

Well Thank You! I have not tried a VPN yet but used XRDP plenty and that worked fine, still a novice on VPN's and VLAN's tell the truth. But learning new stuff everyday. Who said you can't teach an old dog huh?? lol. Thank you for the advice guys. Back on topic now, (But Thank you, very much)

johnpoz · Apr 5, 2016, 11:44 AM

"It only matters how many actual hosts are on it."

Agreed, but come on - using a /8 on any interface anywhere is just nonsense… You for sure could never actually put that many hosts on the same broadcast domain and expect it to work.

And yup for sure its most likely going to cause problems if you try and vpn.. No matter how you look at it is not a realistic mask to place on an interface anywhere..

MikeV7896 · Apr 5, 2016, 2:16 PM

Just to get this back on the topic of DHCP reservations… I've not had any issues with DHCP reservations functioning. I have at least 12 of them set on my home network and all work just fine.

I even tried DHCPv6 reservations for a bit and those work too.