Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: per-pool routers in dhcpd.conf? (glenn.satch...@uniq.com.au)
2. Re: MAC randomisation and DHCP pools (glenn.satch...@uniq.com.au)
3. Re: per-pool routers in dhcpd.conf? (Michael De Roover)
4. Re: MAC randomisation and DHCP pools (Rudy Zijlstra)
----------------------------------------------------------------------
Message: 1
Date: Sun, 26 Jul 2020 12:46:27 +1000
From: glenn.satch...@uniq.com.au
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: per-pool routers in dhcpd.conf?
Message-ID: <0c5ee5ce359b62cea50135b76b22c...@uniq.com.au>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Hi Alexis
You don't strictly need allow and deny caluses, since when you use an
allow statement, everything else is implicity denied. There are also
notes about not mixing allow and deny, since the logic doesn't always
work the way you expect, even though the simpler case does seem to work.
pool {
range 192.168.1.101 192.168.1.150;
allow known-clients;
# deny unknown-clients;
}
option routers *should* work in the pool, but config changes could use a
different code path and mess this up I guess.
As someone else suggested, looking at the actual packets with tcpdump
might be useful. Is it possible the client is caching the old gateway or
something strange like that?
I also use the same logic at home to separate the younger kids to
different IP ranges and proxy ACLs:
subnet 192.168.14.0 netmask 255.255.255.0 {
option routers router.example.com.au;
pool {
allow known-clients;
range 192.168.14.210 192.168.14.229;
}
pool {
deny known-clients;
range 192.168.14.230 192.168.14.245;
}
}
regards,
-glenn
On 2020-07-26 00:23, Alexis Huxley wrote:
> Hi, I have dhcpd.conf at home containing:
>
> host { ... }
> ...
>
> subnet 192.168.1.0 netmask 255.255.255.0 {
> option routers 192.168.1.1;
> option domain-name "pasta.net";
> option domain-name-servers 192.168.1.21;
> option ntp-servers time.pasta.net;
>
> # 1-100 are reserved for statically configured hosts.
>
> # 101-150 are reserved for known dynamic hosts (known because
> they're in host stanzas above).
> # e.g. my Android phone on wifi.
> pool {
> range 192.168.1.101 192.168.1.150;
> allow known-clients;
> deny unknown-clients;
> }
>
> # 151-200 are for unknown dynamic hosts. e.g. visitors' phones on
> wifi.
> pool {
> range 192.168.1.151 192.168.1.200;
> allow unknown-clients;
> deny known-clients;
> }
> }
>
> This works fine.
>
> I now want to force 'known dynamic hosts'' to use a different gateway.
>
> (In case you're curious: Since, when using wifi, my Android
> phone silently refuses to use the DNS server proposed by the above
> dhcpd.conf, I now want to change the phone's gateway to a masqueraing
> Linux box, where I can hopefully use iptables to force the phone to
> use the DNS server proposed by the DHCP server, and thereby block ads.)
>
> The dhcpd.conf man page says:
>
> In general, any parameter can appear anywhere that parameters
> are allowed, and will be applied according to the scope in which
> the parameter appears.
>
> and I don't see anything special documented about 'option routers'.
>
> So I thought this should work:
>
> subnet 192.168.1.0 netmask 255.255.255.0 {
> #option routers 192.168.1.1; <--- commented
> out at subnet level
> ...
>
> pool {
> range 192.168.1.101 192.168.1.150;
> ...
> option routers 192.168.1.32; <--- this is
> the different gateway
> }
>
> pool {
> range 192.168.1.151 192.168.1.200;
> ...
> option routers 192.168.1.1; <--- this is
> the original gateway
> }
>
> but it looks like *no* host gets told its gateway.
>
> To confirm that it wasn't a problem with my new gateway itself, I
> put the original gateway in *both* pools, i.e. only the *location* of
> the router declaration changes compared to the original configuration:
>
> subnet 192.168.1.0 netmask 255.255.255.0 {
> #option routers 192.168.1.1; <--- commented
> out at subnet level
> ...
>
> pool {
> range 192.168.1.101 192.168.1.150;
> ...
> option routers 192.168.1.1; <--- this is
> the original gateway
> }
>
> pool {
> range 192.168.1.151 192.168.1.200;
> ...
> option routers 192.168.1.1; <--- this is
> the original gateway
> }
>
> The result was the same: no gateway.
>
> My googles didn't turn up anything relevant and my experiments (using
> 'groups' failed), so any advice would be appreciated. I'm using
> isc-dhcp-server 4.4.1 on Debian 10. Thanks!
>
> Alexis
> _______________________________________________
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
Message: 2
Date: Sun, 26 Jul 2020 13:02:16 +1000
From: glenn.satch...@uniq.com.au
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: MAC randomisation and DHCP pools
Message-ID: <18face18f358747de33cf8e03a2c0...@uniq.com.au>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Hi Mike,
I think in the short term setting the lease time to 24 hours would free
up old leases after the MAC address changes, meaning the old client
effectively goes away. Public places like shopping malls, should already
have shorter leases due to the massive churn in clients, so it's not
going to bother them much.
But that doesn't address any of the issues with identifying individual
devices, eg to put into different classes. For that I think it will need
an education scheme with your users to turn off the feature on networks
where identifying the client matters, eg corporate or home networks.
I think this will evolve to having some other persistent identifier for
systems to use.
regards,
-glenn
On 2020-07-25 11:46, Joshua Stark wrote:
> The user can decide to turn the feature off on the Apple device per
> WiFi network:
>
> Rarely, a network might allow you to join with a private address, but
> won't allow Internet access. If that happens, you can choose to stop
> using private addresses [1] with that network
> (https://support.apple.com/en-us/HT211227)
>
> I agree, this will make things different, harder initially. One
> example that comes to mind is white/black lists on WiFi networks, that
> will go out the window.
> And the other of being able to set a static IPv4 will be next to
> impossible.
>
> But was that not the point of IPv6 - totally random
>
> In my mind this means we need an evolution of how we do things, like
> how AWS/GCP have taken the classic firewall of IP/Port to a Service
> Layer Firewall.
> There is going to need to be another way to identify a device to allow
> automatic re-authentication, like public WiFi where you purchase
> access for greater then 24hrs.
>
> How we do that, I don't know, but it's time to start thinking about
> how to implement the next evolution in technology!
>
> Thanks
> Josh
>
> On 24/7/20 20:59, Mike Richardson wrote:
>
>>> Hi Mike,
>>>
>>> This is not something new, it has been around since IOS 8 in 2014.
>>> I think
>>> this page summarises how it works and has links to Apple's site
>>> with more
>>> details.
>>>
>>>
>>
> https://9to5mac.com/2014/09/26/more-details-on-how-ios-8s-mac-address-randomization-feature-works-and-when-it-doesnt/
>>>
>>> It appears that it randomises the MAC address when the device is
>>> passively
>>> scanning for networks and other particular settings are enabled or
>>> disabled,
>>> so systems can't use the MAC address to persistently track
>>> wherever you go.
>>> However, it seems that any associations/joining of networks is
>>> based on the
>>> actual MAC address.
>>>
>>> Or am I talking about something else entirely different?
>>
>> Something new I believe:
>>
>>
> https://wifinowglobal.com/news-and-blog/new-private-wi-fi-address-iphone-feature-could-severely-impact-the-wi-fi-industry-expert-says/?mc_cid=9ff8988c11&mc_eid=000d85d9e3
>> https://support.apple.com/en-us/HT211227
>>
>> Apple, in IOS14, are going to implement the changing of MACs every
>> 24 hours
>> as the default, and different ones for each SSID, I believe.
>>
>> I'm just trying to evaluate the impact on things like DHCP, but I'm
>> not sure
>> about exactly what happens when pools are, sort of, exhausted.
>>
>> Thanks,
>>
>> Mike
>
>
>
> Links:
> ------
> [1] https://support.apple.com/en-us/HT211227#onoff
> _______________________________________________
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
Message: 3
Date: Sun, 26 Jul 2020 07:00:26 +0200
From: Michael De Roover <i...@nixmagic.com>
To: dhcp-users@lists.isc.org
Subject: Re: per-pool routers in dhcpd.conf?
Message-ID: <18c1ae68-3f88-5040-01b2-7ef502131...@ghnou.su>
Content-Type: text/plain; charset=utf-8; format=flowed
On 7/25/20 4:23 PM, Alexis Huxley wrote:
> I now want to force 'known dynamic hosts'' to use a different gateway.
>
> (In case you're curious: Since, when using wifi, my Android
> phone silently refuses to use the DNS server proposed by the above
> dhcpd.conf, I now want to change the phone's gateway to a masqueraing
> Linux box, where I can hopefully use iptables to force the phone to
> use the DNS server proposed by the DHCP server, and thereby block ads.)
I have a similar setup at home with host declarations and a set of DNS
servers being pushed to the devices. On all of my Android devices they
seem to be taking these settings normally. So it might be worth
double-checking the client devices before doing such masqueraded setup
(which could end up being overkill).
Off the top of my head, I can think of the Private DNS settings in newer
versions of Android overriding the DNS settings pushed by the DHCP
server, as well as any VPN connections. Perhaps one or both of these are
active and interfering?
I don't know if this is relevant, but in my dhcpd.conf I also have the
options for domain/search and DNS servers to use above the host settings.
--
Met vriendelijke groet / Best regards,
Michael De Roover
------------------------------
Message: 4
Date: Sun, 26 Jul 2020 10:26:13 +0200
From: Rudy Zijlstra <r...@grumpydevil.homelinux.org>
To: dhcp-users@lists.isc.org
Subject: Re: MAC randomisation and DHCP pools
Message-ID:
<e6549653-3b8b-fe17-9665-a0a51baa3...@grumpydevil.homelinux.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Glenn,
The DHCP Id should be stable, at least according to the dhcp RFC. I need
to start playing around a bit...
I do understand the privacy concerns here, and why this is being
implemented.
Cheers
Rudy
On 26-07-2020 05:02, glenn.satch...@uniq.com.au wrote:
> Hi Mike,
>
> I think in the short term setting the lease time to 24 hours would
> free up old leases after the MAC address changes, meaning the old
> client effectively goes away. Public places like shopping malls,
> should already have shorter leases due to the massive churn in
> clients, so it's not going to bother them much.
>
> But that doesn't address any of the issues with identifying individual
> devices, eg to put into different classes. For that I think it will
> need an education scheme with your users to turn off the feature on
> networks where identifying the client matters, eg corporate or home
> networks.
>
> I think this will evolve to having some other persistent identifier
> for systems to use.
>
> regards,
> -glenn
>
> On 2020-07-25 11:46, Joshua Stark wrote:
>> The user can decide to turn the feature off on the Apple device per
>> WiFi network:
>>
>> Rarely, a network might allow you to join with a private address, but
>> won't allow Internet access. If that happens, you can choose to stop
>> using private addresses [1] with that network
>> (https://support.apple.com/en-us/HT211227)
>>
>> I agree, this will make things different, harder initially. One
>> example that comes to mind is white/black lists on WiFi networks, that
>> will go out the window.
>> And the other of being able to set a static IPv4 will be next to
>> impossible.
>>
>> But was that not the point of IPv6 - totally random
>>
>> In my mind this means we need an evolution of how we do things, like
>> how AWS/GCP have taken the classic firewall of IP/Port to a Service
>> Layer Firewall.
>> There is going to need to be another way to identify a device to allow
>> automatic re-authentication, like public WiFi where you purchase
>> access for greater then 24hrs.
>>
>> How we do that, I don't know, but it's time to start thinking about
>> how to implement the next evolution in technology!
>>
>> Thanks
>> Josh
>>
>> On 24/7/20 20:59, Mike Richardson wrote:
>>
>>>> Hi Mike,
>>>>
>>>> This is not something new, it has been around since IOS 8 in 2014.
>>>> I think
>>>> this page summarises how it works and has links to Apple's site
>>>> with more
>>>> details.
>>>>
>>>>
>>>
>> https://9to5mac.com/2014/09/26/more-details-on-how-ios-8s-mac-address-randomization-feature-works-and-when-it-doesnt/
>>
>>
>>>>
>>>> It appears that it randomises the MAC address when the device is
>>>> passively
>>>> scanning for networks and other particular settings are enabled or
>>>> disabled,
>>>> so systems can't use the MAC address to persistently track
>>>> wherever you go.
>>>> However, it seems that any associations/joining of networks is
>>>> based on the
>>>> actual MAC address.
>>>>
>>>> Or am I talking about something else entirely different?
>>>
>>> Something new I believe:
>>>
>>>
>> https://wifinowglobal.com/news-and-blog/new-private-wi-fi-address-iphone-feature-could-severely-impact-the-wi-fi-industry-expert-says/?mc_cid=9ff8988c11&mc_eid=000d85d9e3
>>
>>
>>> https://support.apple.com/en-us/HT211227
>>>
>>> Apple, in IOS14, are going to implement the changing of MACs every
>>> 24 hours
>>> as the default, and different ones for each SSID, I believe.
>>>
>>> I'm just trying to evaluate the impact on things like DHCP, but I'm
>>> not sure
>>> about exactly what happens when pools are, sort of, exhausted.
>>>
>>> Thanks,
>>>
>>> Mike
>>
>>
>>
>> Links:
>> ------
>> [1] https://support.apple.com/en-us/HT211227#onoff
>> _______________________________________________
>> ISC funds the development of this software with paid support
>> subscriptions. Contact us at https://www.isc.org/contact/ for more
>> information.
>>
>> dhcp-users mailing list
>> dhcp-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
> _______________________________________________
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
Subject: Digest Footer
_______________________________________________
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 141, Issue 14
*******************************************
