1) Instalation of an DHCP server ----------------------------- 1a) Download the packages The packages necessary for the DHCP server (and client) can be installed with yum install dhcp (for CentOS) apt install isc-dhcp-server (for Ubuntu) 1b) Configuration of the server There is a configuration file after instalation, but it just contains directions regarding where one can see a sample configuration file. It is located in /etc/dhcp/dhcpd.conf The sample configuration file is in /usr/share/doc/dhcp-4.1.1/dhcpd.conf.sample 4.1.1 will be different when the server's version will change. So in the original file from above it says "*" instead of "-4.1.1" In my installed version, actually this file is called different and located in a different location, so you need to update many of the commands that follow according to the (real) location and filename. Here is the complete path to the file: /usr/share/doc/isc-dhcp-server/examples/dhcpd.conf.example The simplest way to configure the server is to replace dhcp.conf with the sample file and then edit the file to obtain your desired configuration. For the ones that like to get everything on a plate so they do less work, this time I will be more explicit: - rename the old configuration file: mv /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.old - copy the sample file: cp /usr/share/doc/dhcp*/dhcpd.conf.sample /etc/dhcp/dhcpd.conf - edit the just copied configuration file by mofifying some of the lines presented below: default-lease-time 6000; max-lease-time 72000; I've just added a zero at the original values, the times are in seconds. 600 is 10 minutes and that was the value for the time a client will have the IP address given by the DHCP server. Now it's 100 minutes, a bit longer, so we can see it work and test it. Then I've commented a lot of lines by adding the # character at the begining of the line. All of them declared some subnets of the local network. We only have 2 virtual machines, so I've left only one subnet, the one starting with the line: # A slightly different configuration for an internal subnet. subnet 10.5.5.0 netmask 255.255.255.224 { range 10.5.5.26 10.5.5.30; option domain-name-servers ns1.internal.example.org; option domain-name "internal.example.org"; option routers 10.0.2.2; option broadcast-address 10.5.5.31; default-lease-time 6000; max-lease-time 72000; } The commented zone, I will give you below. Be aware that in your file this is not commented and you probably will want to do so yourself: # No service will be given on this subnet, but declaring it helps the # DHCP server to understand the network topology. #subnet 10.152.187.0 netmask 255.255.255.0 { #} # This is a very basic subnet declaration. #subnet 10.254.239.0 netmask 255.255.255.224 { # range 10.254.239.10 10.254.239.20; # option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org; #} # This declaration allows BOOTP clients to get dynamic addresses, # which we don't really recommend. #subnet 10.254.239.32 netmask 255.255.255.224 { # range dynamic-bootp 10.254.239.40 10.254.239.60; # option broadcast-address 10.254.239.31; # option routers rtr-239-32-1.example.org; #} Ok, let's come back to the subnetwork I left uncommented. By looking at the first line subnet 10.5.5.0 netmask 255.255.255.224 { one can see that it has the IP's between 10.5.5.0 - 10.5.5.31 By looking at the second line range 10.5.5.26 10.5.5.30; one can see that it will allocate to DHCP clients only the interval between 10.5.5.26 - 10.5.5.30 By looking at the line option routers 10.0.2.2; one can see that the gateway that the DHCP server will give to the clients will be 10.0.2.2 Originally here, in the sample file was 10.5.5.1, that is the address of the DHCP server! So now we have this file and let's arrange all the rest to fit those numbers. That will be: - assign 10.5.5.1 as address to the DHCP server (somehow solved on step 1b2) - make the second VM to find the DHCP server so it will get the IP from it and not from the one that we have in Virtualbox. For those who don't remember, we configured a DHCP server when we configured the "Host network manager", from the VirtualBox's File menu. So we have 2 DHCP servers and we want ours to assign the IP address to linux7 and not Virtualbox. Also we want everything else to continue functioning! 1b2) configure the server continued: We need to create an alias for the eth3 network interface with ifconfig eth3:0 10.5.5.1 netmask 255.255.255.224 up (in CentOS) ifconfig enp0s8:0 10.5.5.1 netmask 255.255.255.224 up (in Ubuntu) We assigned to it the IP of the DHCP server. Why exactly there? Because the DHCP server will use exactly that network interface to assign IP addresses to clients. Automatically a route is added for IPs from the interval 10.5.5.0-10.5.5.31 because of the subnetmask 255.255.255.224 put on eth3:0 (or on enp0s8:0 for Ubuntu) Unfortunately this step is not persistent, meaning that the alias will not survive a reboot and we need (eventually) to fix that. That is Network interface configuration and is not covered here. See this for a model (not remotely solving the problem by just copy-pasting from it!): https://www.serverlab.ca/tutorials/linux/administration-linux/how-to-configure-networking-in-ubuntu-20-04-with-netplan/ 1b3) To complete the settings for the DHCP server we need to say which interface to use (that is eth3:0). We do that like this: a) in CentOS: nano /etc/sysconfig/dhcpd we will write there DHCPDARGS=eth3:0 and save the file. b) in Ubuntu sudo nano /etc/default/isc-dhcp-server we will write there INTERFACESv4="enp0s8" and save the file 1b3) We start the DHCP server service dhcpd start (on CentOS) systemctl start isc-dhcp-server (in Ubuntu) Now the server configuration is complete! --------------------------------------------------------------------------------------------------------------- 2) Client configuration on Ubuntu --------------------------------- follow the steps from this tutorial: https://www.tecmint.com/install-dhcp-server-in-ubuntu-debian/ 2) Configuration on the client on CentOS: -------------------------------------- 2a) See what dhcp client we are using: cat /etc/rc.local we can see that we have there a line which says: /sbin/dhclient which tells us we are using the dhcp client called dhclient The rest of this lab is based on fact. We are configuring dhclient, not another client. For other clients the configuration might de different. 2b) See what network cards we have on the client (with ifconfig). One of them is configure to use NAT, the other is configure to use "host-only adapter". We need to modify the setings of the one second one. How can we identify which ome is that? Let's see on my computer what is the output of the ifconfig command and explain eth0 Link encap:Ethernet HWaddr 08:00:27:BF:A8:C4 inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:febf:a8c4/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:19 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2505 (2.4 KiB) TX bytes:3421 (3.3 KiB) eth1 Link encap:Ethernet HWaddr 08:00:27:96:3A:80 inet addr:192.168.56.102 Bcast:192.168.56.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe96:3a80/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:39 errors:0 dropped:0 overruns:0 frame:0 TX packets:83 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:7326 (7.1 KiB) TX bytes:9135 (8.9 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:2940 errors:0 dropped:0 overruns:0 frame:0 TX packets:2940 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:180968 (176.7 KiB) TX bytes:180968 (176.7 KiB) Since, on the other VM we see something similar, namely, there is also an network interface with the same IP address as eth1, (10.2.0.15), we conclude that this one (eth1) is the NAT interface, and the other one is the one we need to modify (eth1)! On your VM, maybe you have other names for the network interfaces, e.g. eth5 and eth6. So you need to pay attention here, and configure the right interface. 2c) We release the "lease" we had from the VirtualBox DHCP server for the required interface (in my case eth1) dhclient -r eth1 (on CentOS) sudo dhclient -r enp0s8 (on Ubuntu) that will release the old dhcp lease from interface eth1 only. It seems if we just say dhclient -r that will release both network interfaces eth1 and eth0 as well, although eth0 has beet configured as NAT. Remember that when installing virtualbox's VM's we have configured eth0 as NAT interface and eth1 as host-only network interface. Maybe on your machines the names of the 2 network interfaces might differ, e.g. eth1 and eth2 or eth5 and eth6. 2d) Restart dhclient with the command dhclient If everything works well the new DHCP server will take precedence and will assign an IP address to eth1. It is possible to be necessary to stop the firewall for that to succeed: iptables -F setenforce 0 If we still get the old address (the one with 192), then inticating which is the DHCP server that should assign us Ip might help, that is, we release the IP again, then specify the server dhclient -r eth1 dhclient -s 10.5.5.1 or even dhclient -4 -s 10.5.5.1 From some reasons, on my VM sometimes the commands: dhclient -s 10.5.5.1 dhclient and dhclient -4 -s 10.5.5.1 Don't behave how they should do, and only get the IPv6 address, and now the one which has the most chances of success is the one without parameters (dhclient), provided that the old dhclient has the address released Before each try we should say dhclient -r eth1 because eth1 got an IP address, only that it is not an IPv4 address) 2d errors) If this procedure does not work to obtain an valid IP address from the DHCP server, we can also configure the DHCP client to overcome the errors First, let's see an extra option on a previously used command: dhclient -4 -d -s 10.5.5.1 The -d option is used for debugging purposes for us to see what happens. On my DHCP client VM, for example, I got a lot of these messages, we'll call them error messages since nothing happend in reply to them: DHCPREQUEST on eth1 to 10.5.5.1 port 67 (xid=0x325ca856) DHCPOFFER from 192.168.163.2 The 1st message had a lot of occurences and one can see that we just requested the IP but never received any. The 2nd one told me that from time to time, an IP lease offering came from the VirtualBox DHCP host (that we didn't want to receive) On reading a lot of forums I found out that on CentOS 7 one can configure the dhclient so that it rejects the unwanted IP leases (the one from the VirtualBox host-only DHCP server, in our case). I've tried that and it also works on CentOS 6 and is very simple to acquire: 2d-err-a) Create on the client VM a file called (*) /etc/dhcp/dhclient.conf with the following content: interface "eth0" { reject 192.168.215.0/24; } Or, in the same file (**): interface "enp0s8" { reject 192.168.215.2; } It seems that rejecting an entire interval of IP's somehow will also eliminate the offers from my DHCP server. I got this by analizing the output of a debugging launch of dhclient. (that is, I used sudo dhclient -r sudo dhclient -data The 1st one to give the old IP lease. And the 2nd one to see the debug messages. Here is an excerpt of the debugging data for the case I used all the interval of IP's (256 IP's) (*). Actually let's write all the steps after that. Internet Systems Consortium DHCP Client 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/enp0s8/08:00:27:8a:10:78 Sending on LPF/enp0s8/08:00:27:8a:10:78 Sending on Socket/fallback DHCPDISCOVER on enp0s8 to 255.255.255.255 port 67 interval 3 (xid=0x886ca527) DHCPOFFER from 192.168.215.4 rejected by rule 192.168.215.0 mask 255.255.255.0. DHCPOFFER from 192.168.215.2 rejected by rule 192.168.215.0 mask 255.255.255.0. DHCPDISCOVER on enp0s8 to 255.255.255.255 port 67 interval 7 (xid=0x886ca527) DHCPOFFER from 192.168.215.4 rejected by rule 192.168.215.0 mask 255.255.255.0. DHCPOFFER from 192.168.215.2 rejected by rule 192.168.215.0 mask 255.255.255.0. DHCPDISCOVER on enp0s8 to 255.255.255.255 port 67 interval 11 (xid=0x886ca527) DHCPOFFER from 192.168.215.4 rejected by rule 192.168.215.0 mask 255.255.255.0. DHCPOFFER from 192.168.215.2 rejected by rule 192.168.215.0 mask 255.255.255.0. Now, let's interpret that and see why this manner is not good! Notice the DHCPOFFER messages. One can clearly see that 2 hosts give away DHCP addresses (or at least they try to do so): 192.168.215.2 and 192.168.215.4. Now, the 1st one of the 2 is the DHCP server that comes with Virtualbox. The second, however, is the one just installed by us on the other VM. So our rule rejects offers from both DHCP servers, because the entire interval of IP's 192.168.215.0/24 is rejected. We can see thus that we cannot do so, so, only the variant (**) can work, and there we should reject only from exactly the IP of the DHCP server offered by Virtualbox, and that is 192.168.215.2 Let's confirm our hypothesis, obtaining the debugging data from the case (**) Internet Systems Consortium DHCP Client 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/enp0s8/08:00:27:8a:10:78 Sending on LPF/enp0s8/08:00:27:8a:10:78 Sending on Socket/fallback DHCPDISCOVER on enp0s8 to 255.255.255.255 port 67 interval 3 (xid=0xdc301371) DHCPOFFER from 192.168.215.2 rejected by rule 192.168.215.2 mask 255.255.255.255. DHCPOFFER of 10.5.5.26 from 192.168.215.4 DHCPREQUEST for 10.5.5.26 on enp0s8 to 255.255.255.255 port 67 (xid=0x711330dc) DHCPACK of 10.5.5.26 from 192.168.215.4 (xid=0xdc301371) bound to 10.5.5.26 -- renewal in 2605 seconds. Confirmed! we got the IP 10.5.5.26 from the DHCP server running on 192.168.215.4 And we rejected the offer from the other DHCP server from 192.168.215.2 Also, here we can see all the messages passed between the client and the server. DHCPDISCOVER - the client asks for an IP DHCPOFFER - varois servers respond DHCPREQUEST - the client picks one of the offers and asks to get that IP DHCPACK - the server confirms the request and send the confirmation message "bound to 10.5.5.26 -- renewal in 2605 seconds." That would be practically all we neeed to do and this is a more complicated situation that, probably the one you will need to do in the real life. The cause of the complications is that I didn't want to stop the original DHCP server supplied by Virtualbox. The promissed missing steps don't really exist, I will only tell you how I obtained the debugging data sudo dhclient -d > one-ip.txt 2>&1 Or, for the other one replace one-ip.txt with all-ip.txt. Of course, in between the 2 output files we need to write the reject rule as stated in step 2d-err-a). We wait a while (nothing shows on the screen, since we redirected the output and the error streams into the file) Then stop the debugging seddion with Ctrl-C That is either (**) interfce "enp0s8" { reject 192.168.215.2; } or in the other case (*) interfce "enp0s8" { reject 192.168.215.0/24; } 2d-err-b) Use the command dhclient -r eth1 to release the IP for eth1 dhclient -d to acquire a new one The 2nd one needs to be stopped with Ctrl-c after it succeeds. So if that happens, practically we don't need to use the -d option. It will take a while to complete, because the other DHCP server also is offering but the client will reject the offers. 2e) Test the client works We need to see first (we did that at the previous step) that we got an IP starting with 10.5.5 for eth1 ifconfig eth1 The output, on my VM is: eth1 Link encap:Ethernet HWaddr 08:00:27:96:3A:80 inet addr:10.5.5.26 Bcast:10.5.5.31 Mask:255.255.255.224 inet6 addr: fe80::a00:27ff:fe96:3a80/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:39 errors:0 dropped:0 overruns:0 frame:0 TX packets:83 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:7326 (7.1 KiB) TX bytes:9135 (8.9 KiB) Try to reach an Ip on the internet by pinging it 4 times ping -c 4 8.8.8.8 The response looks like that if it works: PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=54.4 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=55.2 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=58.7 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=54 time=52.5 ms --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3060ms rtt min/avg/max/mdev = 52.581/55.256/58.711/2.219 ms Test if yum also works yum search top 2f) Why do we still have Internet on the client machine? The answer to that question is not because we configured the routing table so that it works, but because we are using the other network interface, the one configured with NAT for that! In the real world, with desktop PC's and laptops this is not possible. There we will have onlu one network interface, so there, we need to put on the server in the dhcpd.conf file the line option routers 10.0.2.2; not with the IP above, but rather with that of the DHCP server (in our case 10.5.5.1) That will be the gateway the client will use to exit on the internet. We can see that on out VM by looking at the routing table, which looks like that [root@linux7 ~]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.5.5.0 * 255.255.255.224 U 0 0 0 eth1 10.0.2.0 * 255.255.255.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 1002 0 0 eth0 default 10.0.2.2 0.0.0.0 UG 0 0 0 eth0 So, the last line says that if I want to access some address which is not described by the above rules I will use the gateway 10.0.2.2. This rule is for internet addresses. 2g) and 1c) See the leases on the server Each time the server gives away an IP address this is recorded in a file. The newest instance of the file is /var/lib/dhcpd/dhcpd.leases But maybe you want older instances (backups) of the file, these are also in the same folder (/var/lib/dhcpd ). The name of the older files are a bit longer dhcpd.leases , probably some extra letters. I assume a fresh file is created (and the old one is backed up) each time I restart the dhcp server. 2h) If the Internet is not working on the client because the gateway is the default one (10.5.5.1) this problem can be solved on the server in 2 manners: - by enabling IPv4 forwarding - by changing the line that specifies the gateway from the dhcpd.conf file into option routers 10.0.2.2; and thus correcting the gateway to 10.0.2.2 Enabling IPv4 forwarding is done as follows (but we don't need it now!): nano /proc/sys/net/ipv4/ip_forward write 1 in this file (instead of 0) to enable IP forwarding and save it with Ctrl-X