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

On 16/01/17 17:12, James A. Peltier wrote:
> VLANs are your friend, otherwise DHCPD is not going to understand how to
properly answer your request for different networks on the same interface.
>
> ----- On 14 Jan, 2017, at 11:59, Gregory P. Ennis PoMec at PoMec.net wrote:
>
> | Everyone,
> |
> | I am trying to set up a second internal network  (192.168.0.0/24) and
> | have not been able to get dhcp to start when I have the following in my
> | dhcpd.conf file :
> |
> | subnet 192.168.0.0 netmask 255.255.255.0 {
> |        range 192.168.0.110 192.168.0.130;
> |        option subnet-mask 255.255.255.0;
> |        option broadcast-address 192.168.0.255;
> |        option routers 192.168.0.1;
> |        option domain-name-servers 192.168.0.1;
> | }
> |
> | When i remove the above from dhcpd.conf dhcpd works perfectly
> |
> | I have my internal nic card set with two ip addresses one of which is
> | 192.168.0.1. the other address is my standard internal network address.
> |
> | I have also set up the domain server to allow access from
> | 192.168.0.0/24, and the firewall allows internal access to the same
> | subnet.
> |
> | The error that I get is the following :
> |
> | Job for dhcpd.service failed because the control process exited with
error code.
> | See "systemctl status dhcpd.service" and "journalctl
-xe" for details.
> |
> | When I evaluate journalctl -xe the following is obtained :
> |
> | dhcpd[18763]: Internet Systems Consortium DHCP Server 4.2.5
> | dhcpd[18763]: Copyright 2004-2013 Internet Systems Consortium.
> | dhcpd[18763]: All rights reserved.
> | dhcpd[18763]: For info, please visit https://www.isc.org/software/dhcp/
> | dhcpd[18763]: Not searching LDAP since ldap-server, ldap-port and
> | ldap-base-dn were not specified in the config file
> | dhcpd[18763]: Internet Systems Consortium DHCP Server 4.2.5
> | dhcpd[18763]: Copyright 2004-2013 Internet Systems Consortium.
> | dhcpd[18763]: All rights reserved.
> | dhcpd[18763]: For info, please visit https://www.isc.org/software/dhcp/
> | dhcpd[18763]: Wrote 0 deleted host decls to leases file.
> | dhcpd[18763]: Wrote 0 new dynamic host decls to leases file.
> | dhcpd[18763]: Wrote 2 leases to leases file.
> | dhcpd[18763]: Interface enp0s29u1u2 matches multiple shared networks
> | dhcpd[18763]:
> | dhcpd[18763]: This version of ISC DHCP is based on the release available
> | dhcpd[18763]: on ftp.isc.org.  Features have been added and other
> | changes
> | dhcpd[18763]: have been made to the base software release in order to
> | make
> | dhcpd[18763]: it work better with this distribution.
> | dhcpd[18763]:
> | dhcpd[18763]: Please report for this software via the CentOS Bugs
> | Database:
> | dhcpd[18763]:     http://bugs.centos.org/
> | dhcpd.service: main process exited, code=exited, status=1/FAILURE
> | dhcpd[18763]:
> | systemd[1]: Failed to start DHCPv4 Server Daemon.
> |
> | When I review the information about dhcpd it appears that it can manage
> | the ip addresses for two networks on different nic cards, but is there a
> | problem in having it manage two networks on the same nic card?
> |
> | Does anyone have any ideas?  Would sure appreciate your help.
> |
> | Greg Ennis
> |
> |
> |
> | --
> | Greg Ennis
> | PoMec Corporation
> | www.PoMec.Net
> |
> |
> | _______________________________________________
> | CentOS mailing list
> | CentOS at centos.org
> | https://lists.centos.org/mailman/listinfo/centos
>
Here's an idea - untested.
set up a network on the single nic - say 192.168.55.xx/24
set up the dhcp to offer leases from a subset of this network - say 
192.168.55.128/28
set up fixed leases based upon mac address from the remainder of the 
network - i.e. outside the subset above - e.g. 192.168.55.1/28
then route / firewall as required - i.e. trusted known mac address hence 
IP address allowed vs unknown guest given an IP address we can block or 
otherwise handle.
As indicated, this is not tested but if memory serves, dhcpd will allow 
this kind of allocation.
HTH
Rob

On 1/16/2017 12:44 AM, Rob Kampen wrote:
>>
> Here's an idea - untested.
> set up a network on the single nic - say 192.168.55.xx/24
> set up the dhcp to offer leases from a subset of this network - say 
> 192.168.55.128/28
> set up fixed leases based upon mac address from the remainder of the 
> network - i.e. outside the subset above - e.g. 192.168.55.1/28
> then route / firewall as required - i.e. trusted known mac address 
> hence IP address allowed vs unknown guest given an IP address we can 
> block or otherwise handle.
> As indicated, this is not tested but if memory serves, dhcpd will 
> allow this kind of allocation. 
the untrusted wireless users will be able to access other LAN machines 
without going through the firewall.

-- 
john r pierce, recycling bits in santa cruz

On 16/01/17 21:54, John R Pierce wrote:
> On 1/16/2017 12:44 AM, Rob Kampen wrote:
>>>
>> Here's an idea - untested.
>> set up a network on the single nic - say 192.168.55.xx/24
>> set up the dhcp to offer leases from a subset of this network - say 
>> 192.168.55.128/28
>> set up fixed leases based upon mac address from the remainder of the 
>> network - i.e. outside the subset above - e.g. 192.168.55.1/28
>> then route / firewall as required - i.e. trusted known mac address 
>> hence IP address allowed vs unknown guest given an IP address we can 
>> block or otherwise handle.
>> As indicated, this is not tested but if memory serves, dhcpd will 
>> allow this kind of allocation. 
>
> the untrusted wireless users will be able to access other LAN machines 
> without going through the firewall.
>
surely that depends upon the subnet they operate on (i.e the subnet mask 
in old vernacular) - the two I show above are mutually exclusive but can 
both talk to the server.

On Mon, 16 Jan 2017 at 03:44 -0000, Rob Kampen wrote:
> On 16/01/17 17:12, James A. Peltier wrote:
> > VLANs are your friend, otherwise DHCPD is not going to understand how
to
> > properly answer your request for different networks on the same
interface.
Be careful about expecting VLANs to provide security.  VLANs are for
traffic management are not directly a security tool.  They might be
useful in a carefully designed security model.
> Here's an idea - untested.
> set up a network on the single nic - say 192.168.55.xx/24
> set up the dhcp to offer leases from a subset of this network - say
> 192.168.55.128/28
> set up fixed leases based upon mac address from the remainder of the
network -
> i.e. outside the subset above - e.g. 192.168.55.1/28
> then route / firewall as required - i.e. trusted known mac address hence IP
> address allowed vs unknown guest given an IP address we can block or
otherwise
> handle.
> As indicated, this is not tested but if memory serves, dhcpd will allow
this
> kind of allocation.
I do something like this (although FreeBSD is my dhcp server) only I
do like the original proposal, two addresses on the DHCP server and
both subnets configured.  Part of my dhcp configuration includes:

    shared-network shared {
        # Primary subnet
        subnet 192.168.30.0 netmask 255.255.255.0 {
            option routers 192.168.30.1;
            max-lease-time 86400;
            default-lease-time 86400;
            authoritative;

            range 192.168.30.48 192.168.30.59;
        }

        # Secondary subnet
        subnet 192.168.40.0 netmask 255.255.255.0 {
            option routers 192.168.40.1;
            max-lease-time 86400;
            default-lease-time 86400;
            authoritative;
        }
    } # end of shared-network shared

    host ip-phone-1 {
        hardware ethernet 00:0b:82:xx:xx:xx;
        ## fixed-address 192.168.30.129;
        fixed-address 192.168.40.129;
    }

There are other things necessary to make this all work.  I also have a
FreeBSD system acting as a router between the subnets and my ISP
connection.  I also have a caching dns service on both subnets (I
didn't include the dns related configuration in the example above).

As others have suggested, this also is NOT a security technique.  The
systems in each address space will have access to systems in the other
address space even without a router.  I don't distinguish between
trusted and untrusted networks, I assume all are untrusted and secure
the systems themselves as needed.

Stuart
-- 
I've never been lost; I was once bewildered for three days, but never lost!
                                        --  Daniel Boone