DHCP problem

H

hac3ru

Hello,

I have a network (/20) divided on 16 aliases. I want to allow unknown MACs on this network in 192.168.14.0/24 and 192.168.15.0/24 networks. I edited dhcpd.conf so it looks like this:
Code: 
default-lease-time 86400;
ddns-update-style interim;
log-facility local3;    # Note: syslog-ng filters by program
#
# Network options
#
shared-network camin
{
    authoritative;
    option domain-name "home.ro";
    option domain-name-servers 8.8.8.8;

    subnet 192.168.15.0 netmask 255.255.255.0
    {
        default-lease-time 600;
        option routers 192.168.15.9;               #Alias15's IP
        option subnet-mask 255.255.255.0;
        option broadcast-address 192.168.15.255;

        pool
        {
            range 192.168.15.10 192.168.15.100;
        }
    }


    subnet 192.168.0.0 netmask 255.255.255.0
    {
        option routers 192.168.0.9;             #Alias0's IP
        option subnet-mask 255.255.255.0;
        option broadcast-address 192.168.0.255;
        server-identifier 192.168.0.0;
    }
include "/usr/local/etc/defined_hosts.list";
}
This is just the beginning of the dhcpd.conf file. The subnets declarations repeat with IP's changed accordingly.
The problem is that the PCs connected to the network sometimes get an IP address but no connection to the server (can't ping the server), sometimes they don't get an IP at all. I am talking about the PCs that don't have their MAC address written in the defined_hosts.list file. In the dhcpd.log file I can see:
Code: 
Feb 26 14:06:45 c3 dhcpd: DHCPDISCOVER from 00:11:00:11:22:00 via bge1
Feb 26 14:06:45 c3 dhcpd: icmp_echorequest 172.23.15.10: Invalid argument
Feb 26 14:06:46 c3 dhcpd: DHCPOFFER on 172.23.15.10 to 00:11:00:11:22:00 (Hac3ru-PC) via bge1
Feb 26 14:06:46 c3 dhcpd: Unable to add forward map from Hac3ru-PC.home.ro to 172.23.15.10: timed out
Feb 26 14:06:46 c3 dhcpd: DHCPREQUEST for 172.23.15.10 (172.23.0.1) from 00:11:00:11:22:00 (Hac3ru-PC) via bge1
Feb 26 14:06:46 c3 dhcpd: DHCPACK on 172.23.15.10 to 00:11:00:11:22:00 (Hac3ru-PC) via bge1
Feb 26 14:06:49 c3 dhcpd: DHCPINFORM from 172.23.15.10 via bge1
Feb 26 14:06:49 c3 dhcpd: DHCPACK to 172.23.15.10 (00:11:00:11:22:00) via bge1
Feb 26 14:06:49 c3 dhcpd: send_packet: Invalid argument
Feb 26 14:06:49 c3 dhcpd: dhcp.c:1305: Failed to send 305 byte long packet over fallback interface.
Feb 26 14:06:52 c3 dhcpd: DHCPINFORM from 172.23.15.10 via bge1
Feb 26 14:06:52 c3 dhcpd: DHCPACK to 172.23.15.10 (00:11:00:11:22:00) via bge1
Feb 26 14:06:52 c3 dhcpd: send_packet: Invalid argument
Feb 26 14:06:52 c3 dhcpd: dhcp.c:1305: Failed to send 305 byte long packet over fallback interface.
What is that dhcp.c:1305 error? I opened the dhcp.c file, located at /usr/src/usr.sbin/sysinstall/dhcp.c and line 1305 is the last line, which is empty...
 
hac3ru said:
What is that dhcp.c:1305 error? I opened the dhcp.c file, located at "/usr/src/usr.sbin/sysinstall/dhcp.c" and line 1305 is the last line, which is empty...
Click to expand...
It's the wrong file. The file you're looking at is part of the source for sysinstall(1). It has nothing to do with the sources of net/isc-dhcp43-server.

Did you bind the DHCP daemon to an interface?
Code: 
dhcpd_ifaces="bge1"                          # ethernet interface(s)
 
Ohh. I have installed the net/isc-dhcp41-server. Where is the dhcp.c file then?
whereis dhcp.c only returns the above mentioned location.

Yes I did bind the interface because the known hosts get the addressed that they have been assigned.
 
hac3ru said:
Ohh. I have installed the /net/isc-dhcp41-server. Where is the dhcp.c file then?
Click to expand...
It's part of the sources that built the executable. It's not something that's actually installed. Messages like that are usually the result of an assertion in the code.
 
Okay. So how do I resolve this? I need DHCP allowing unknown hosts to connect to the network and can't do that right now :(

Got another question that's not related: What's the difference when installing a package from ports or using pkg_add?
 
Are you using a relay? And are the two network segments also on different broadcast domains?
 
Looking at your configuration makes me think that it's not really possible to serve IP addresses in such fashion because now dhcpd(8) has no way of telling which subnet it should use for an unknown client. The initial requests will have 0.0.0.0 as source address and 255.255.255.255 as destination so it can not really make a decision which subnet to select because all the subnets are on the same interface, bge1.
 
A configuration like that can work but only if you have two separate broadcast domains and are using DHCP relays to forward the requests to the DHCP server. If both network segments are in the same broadcast domain the DHCP server indeed won't know which pool to use. If I recall correctly it'll always use the first pool but I've never tested it that way.
 
No, I am not using a relay. The /etc/rc.conf looks like:
Code: 
ifconfig_bge1="inet 192.168.0.0 netmask 255.255.240.0"
ifconfig_bge1_alias0="inet 192.168.0.2 netmask 255.255.255.0"
ifconfig_bge1_alias1="inet 192.168.1.2 netmask 255.255.255.0"
... and so on
So every alias should have it's own broadcast address.

@kpa
I don't understand why is that?
Since I have a pool of IPs only in subnet 192.168.15.0/24 shouldn't it use that to assign IPs to unknown hosts?

Ideas about what can I do?
 
Last edited by a moderator:
I'm intrigued at what problem you're trying to solve with all these subsets. Judging by your interface configuration it looks like you only have one broadcast domain (Your server has all these addresses on one interface and I assume all your computers are on the same switch network). In standard networking theory it's considered bad practice to have more than one IP subnet defined in the same broadcast domain. In fact in the Cisco exams some of the correct answers rely on you assuming this.

First of all you are assigning the bge1 interface an address of 192.168.0.0/20. This sits in the 192.168.0.0-192.168.15.255 subnet. 192.168.0.0 is actually the 'network address'. Some devices will let you use this IP, others won't. It's generally considered bad practice to use this address and network admins will pretty much never use it.

You're then assigning more addresses with /24 masks, that overlap the original /20 subnet. This seems like an awkward and badly designed configuration. It would be considered wrong by most people.

Is there a specific reason you have 16 /24 networks? Do you need 256x16 addresses?
Considering this is all on the same broadcast domain anyway, is there any reason you can't just assign the server one address - 192.168.0.1/20, give your computers an address in the 192.168.0.x-192.168.13.x range and have a dynamic pool of 192.168.14.0-192.168.15.254. All with a mask of 255.255.240.0 and gw of 192.168.0.1.

I can't help much with the dhcp.conf problems specifically as I do very little with isc-dhcpd, I just find this a very strange setup.
 
In theory, having 16 x /24 networks will give me 16 broadcast addresses, for each /24 network. I took this design from one of the ISPs here, which say that it's better in case of a virus that's broadcasting trash for example. They said that if one of the computers have a virus or something that's generating traffic on the broadcast address, it would broadcast on 192.168.x.255, therefore affecting only PCs in 192.168.x.0/24 network. I didn't test this. Still, the network is working, the computers receive IPs from different networks, with that network's broadcast address. The problem is that sometimes the PCs get an IP address from the pool without being able to connect to the server and sometimes they don't get an IP address at all.
I'm all out of ideas. I was thinking that maybe something was wrong when installing isc-dhcp41-server but I did a clean reinstall and the problem is still there. To go on, I created a virtual machine with the same configuration which seems to work, even though I am getting:
Code: 
Unable to add forward map from XXXXXXX.hostname to 192.168.x.x: Request timed out
Still, even if I get that error, the IPs assigned from the pool are able to access the network, the server and the internet. I have no idea what's happening with the main server and what can I do to fix it. A clean FreeBSD reinstall would mean about 4 hours of downtime and I can't afford to do that only as a last resource so I'm open to any other ideas.

Thank you for your help.
 
I see no value in having multiple subsets on the same LAN (broadcast domain) or how it would help broadcast storms. All broadcasts will reach every machine on the same LAN regardless of their configured address. If the ISP want to limit the possibility of problems, they need to segregate the networks onto independent broadcast domains properly and have routers provide connectivity between the subnets.

As I mentioned, running multiple subnets on the same physical network is, by the book, incorrect. I think you're introducing complexity for the sake of it with no real benefit. Most medium sized companies make do with less than 16 networks, and if they do have multiple subnets, they'll probably be correctly used for independent network areas with routers in between.
 
Okay so I'll just create a big /20 network again. That's easy. The hard part is to get the pool to work.
 
hac3ru said:
In theory, having 16 x /24 networks will give me 16 broadcast addresses, for each /24 network. I took this design from one of the ISPs here, which say that it's better in case of a virus that's broadcasting trash for example. They said that if one of the computers have a virus or something that's generating traffic on the broadcast address, it would broadcast on 192.168.x.255, therefore affecting only PCs in 192.168.x.0/24 network. I didn't test this.
Click to expand...
There are very few viruses that actually do this, it's called a Smurf attack. Most network devices and hosts can be configured not to respond to this kind of traffic. So you're worried about something that may never happen and can be mitigated through other means. Besides that, it's common to use VLANs for this purpose, not to run multiple networks on the same "wire".
 
The smurf attack relies on sending a directed broadcast, which is the only real use for the 'subnet broadcast' address (Although irrelevant these days). A packet is sent to a router with a destination of, for example, 192.168.0.255. If the router happens to have a network with that range on another interface, it will broadcast the packet out on that interface. The standards have required that routers do not forward these packets by default for the last 15 years (and no-one really has a reason to enable it) so this kind of attack is fairly historic.

For general use you can assume that a broadcast sent by one host will be received by every other host on the same physical network, regardless of their address. Broadcasts are handled by switches and forwarded out on all ports (that is a member of the same VLAN) automatically so everyone receives it even if they don't want it.

I suspect the ISP in this case actually are using independent physical networks or VLANs, just like any other ISP would to split their address space between customers. The OP has replicated the subnet layout but not the actual network segregation, so the separate ranges provide no real benefit.
 
usdmatt said:
The smurf attack relies on sending a directed broadcast, which is the only real use for the 'subnet broadcast' address (Although irrelevant these days). A packet is sent to a router with a destination of, for example, 192.168.0.255. If the router happens to have a network with that range on another interface, it will broadcast the packet out on that interface. The standards have required that routers do not forward these packets by default for the last 15 years so this kind of attack is fairly historic.
Click to expand...
You can still find a lot of network printers responding to a subnet broadcast, unfortunately. Which is one of the reasons why they should be put on their own network or VLAN.
 
So, back to my problem :D

I created the 192.168.0.0/20 network again. Last night, I got an IP from the pool, it worked for around 10 minutes, got server and internet access on that PC. After 10 minutes it dropped and couldn't get it back anymore :(

Ideas? :) I really don't want to reinstall the OS
 
Try setting your lease time to about 10 minutes.

If the client loses connection what IP address does it have at that moment? You may also want to check your network for rogue DHCP servers. I've had it happen were some department decided they wanted wireless and just hooked up a wireless router to the network. Unfortunately it also started serving DHCP for the rest of the network which conflicted with the settings we used.
 
Well, the default lease time is 86400 (24 hours). I'll set it to 10 minutes and see if it works.

The clients still has the 192.168.15.x IP address, can communicate with other PCs on the network (the switches offer this functionality most probably) but cannot communicate with the server (192.168.0.1) and cannot access the network (since the server is not doing NAT for that IP).

There is no other DHCP server on the network because it should affect other computers as well. I also tried to connect directly to the server (internal NIC to laptop) and it gives me an IP address but again, cannot ping the server or anything on the internet.
 
hac3ru said:
The clients still has the 192.168.15.x IP address, can communicate with other PCs on the network (the switches offer this functionality most probably) but cannot communicate with the server (192.168.0.1)
Click to expand...
Check your subnet masks, it's the most common thing to get wrong in this case.
 
If I write the MAC address as a fixed host, from network 192.168.15.0/24 it works so it's not a problem.

I quadruple checked the config. Still, I don't know what's with that error from dhcp.c. On the virtual machine, I don't get that error and everything works ok.
 
I wouldn't start messing with manual MAC entries. If the hosts can communicate with each other, which they must if they get a DHCP response, then you must have fairly simple problems.

Can you not just do something simple like the following?

/etc/rc.conf
Code: 
ifconfig_bge1="192.168.0.1/20"
dhcpd_enable="YES"
dhcpd_ifaces="bge1"

/usr/local/etc/dhcpd.conf
Code: 
option subnet-mask 255.255.240.0;
option routers 192.168.0.1;
option ..

subnet 192.168.0.0 netmask 255.255.240.0 {
  option ...

  pool {
    range 192.168.12.1 192.168.13.254;
    deny unknown-clients;
  }

  pool {
    range 192.168.14.1 192.168.15.254;
    allow unknown-clients;
  }
}

host static-host-1 {
  hardware ethernet 00:11:22:33:44:55;
  fixed-address 192.168.x.x;
}

I'm not 100% on the DHCP config as I spent literally 60 seconds checking it but it shouldn't be far off (I've not bothered to find out how you define 'known clients'). I see no reason to make it any more complicated than this unless you want to start physically splitting networks. I'm still not convinced you need 4000 addresses though.

Being able to get DHCP but not talk to the server makes no sense unless you're mixing up subnet masks and confusing all the hosts.
 
Did that, same problem. As I said, on a virtual machine with the same configuration (same pf.conf, ipfw.rules, dhcpd.conf, and rc.conf is working. The physical server is not working though)

One funny thing I have observed, if I restart the server, the clients get IP addresses and they can communicate with the server for about 5 minutes. After that, no new clients get IPs from the pool and the old ones can't communicate with the server anymore.... What is this???
 
The leases are set as
Code: 
default-lease-time 86400
They should not expire. And still, even if they expire, I should get a new one if I disable and re-enable the NIC
 
You must log in or register to reply here.
Back
Top