CentOS - Jan 2017 - Centos 7 dhcpd failure to allow a 2nd network over same interal nic

On 01/15/2017 09:11 AM, Gregory P. Ennis wrote:
> All I can say is that when I looked at the dhcpd.conf examples and read
> the man pages as well as the explanations of how dhcpd works, we should
> be able to use dhcpd for more than one subnet :


You can, provided they're on different physical interfaces.

I'm mostly certain you can have two DHCP scopes on one physical 
interface, provided that the DHCP server itself only has addresses on 
one of them.  That is, if eth0 has 192.168.1.9 and only that address, 
you should be able to offer addresses for 192.168.1.0/24 and also 
192.168.2.0/24 on that interface.  Any host you want to assign an 
address in 192.168.2.0/24 will have to be manually added to that subnet 
with a "host" entry in dhcpd.conf.  Otherwise, imagine that you have
an
Ethernet LAN that includes a WAP.  When the DHCP server gets a request 
from a new host, how does it know whether that client is on Ethernet or 
WiFi?  There's no indication in the request the server receives that 
indicates which media the client is using.

However, attaching two IP subnets to the same broadcast domain is 
usually a bad idea.  Networks are typically segregated for one of two 
reasons: either to establish access controls or to reduce traffic to 
improve service.  You'll accomplish neither.  Hosts on each subnet won't
be able to communicate with each other directly, but they will all see 
all of the address discovery traffic broadcast on the network.  A host 
that wanted to communicate with a host in another subnet could simply 
add a new address manually and bypass any access controls that the 
router had in place. Worse, because any communication you *do* want to 
allow has to pass to the router and then be sent back out the same 
network interface, you've actually doubled the amount of traffic on your 
LAN.

Having multiple subnets on a single broadcast domain can be an 
interesting, inexpensive way to experiment with access control or 
simulate multihosting, but you don't want to do it for any longer than 
is necessary for experimental purposes.

On 01/15/2017 09:11 AM, Gregory P. Ennis wrote:
> All I can say is that when I looked at the dhcpd.conf examples and read
> the man pages as well as the explanations of how dhcpd works, we should
> be able to use dhcpd for more than one subnet :


You can, provided they're on different physical interfaces.

I'm mostly certain you can have two DHCP scopes on one physical 
interface, provided that the DHCP server itself only has addresses on 
one of them.  That is, if eth0 has 192.168.1.9 and only that address, 
you should be able to offer addresses for 192.168.1.0/24 and also 
192.168.2.0/24 on that interface.  Any host you want to assign an 
address in 192.168.2.0/24 will have to be manually added to that subnet 
with a "host" entry in dhcpd.conf.  Otherwise, imagine that you have
an
Ethernet LAN that includes a WAP.  When the DHCP server gets a request 
from a new host, how does it know whether that client is on Ethernet or 
WiFi?  There's no indication in the request the server receives that 
indicates which media the client is using.

However, attaching two IP subnets to the same broadcast domain is 
usually a bad idea.  Networks are typically segregated for one of two 
reasons: either to establish access controls or to reduce traffic to 
improve service.  You'll accomplish neither.  Hosts on each subnet won't
be able to communicate with each other directly, but they will all see 
all of the address discovery traffic broadcast on the network.  A host 
that wanted to communicate with a host in another subnet could simply 
add a new address manually and bypass any access controls that the 
router had in place. Worse, because any communication you *do* want to 
allow has to pass to the router and then be sent back out the same 
network interface, you've actually doubled the amount of traffic on your 
LAN.

Having multiple subnets on a single broadcast domain can be an 
interesting, inexpensive way to experiment with access control or 
simulate multihosting, but you don't want to do it for any longer than 
is necessary for experimental purposes.

-------------------------------------------------------------------

Gordan,

Thank you for such a good explanation.  It seems apparent to me that a
better way to do what I wanted would be to have two wireless routers,
one wifi being controlled by the dhcpd server that assigns ip addresses
through it to known and trusted connections with one subnet, and the
other wifi router assigning addresses on a different subnet to less
trusted users with less access.

Greg

On 01/15/2017 10:19 AM, Gregory P. Ennis wrote:
> It seems apparent to me that a
> better way to do what I wanted would be to have two wireless routers,
> one wifi being controlled by the dhcpd server that assigns ip addresses
> through it to known and trusted connections with one subnet, and the
> other wifi router assigning addresses on a different subnet to less
> trusted users with less access.

Probably, but if you're trying to restrict access, you need to be clear 
about how you're going to achieve that.  If your router only has one 
internal interface, it may be difficult to achieve.

If you have two WAPs behind your router, with one in bridging mode 
(therefore getting addresses from your CentOS DHCP server) and the other 
in NAT or routing mode, you will have effectively segregated the two.  
However, systems behind the NAT/routing WAP would still typically have 
access to the other subnet.  You'd need to not only have the untrusted 
clients behind a WAP of their own, but that WAP would need to allow you 
to specify firewall rules for outbound traffic.  That's not a feature 
present on most consumer devices.

On 1/15/2017 10:19 AM, Gregory P. Ennis wrote:
> Thank you for such a good explanation.  It seems apparent to me that a
> better way to do what I wanted would be to have two wireless routers,
> one wifi being controlled by the dhcpd server that assigns ip addresses
> through it to known and trusted connections with one subnet, and the
> other wifi router assigning addresses on a different subnet to less
> trusted users with less access.
you'd be better off with a single Wireless Access Point (not router) 
that has support for a guest network, and requires authentication for 
connecting to the secure network.   I have a couple Ubquiti UniFi AP's 
that support this (not that I've configured them that way as I don't
need

these guest networks function best if you have a switch and router that 
supports VLANs


-- 
john r pierce, recycling bits in santa cruz