DHCP, ARP: A classic misunderstanding?

Networking & Firewalls
1

The TL;DR : In a home network or small office environment where the devices present are ‘well known’ and fully accessible is it a reliable/acceptable/recommendable policy to try and restrict network access to only those devices and by what mechanism is this achieved?

Been following Lawrence Systems for years with intentions of getting home network running.

Finally starting and so have been trying to set up and understand network basics for a number of weeks and I’d really appreciate if someone could verify or correct the comprehension I’ve tried to establish thus far. I’m thinking I’m dancing around in the kind of questions a lot of people have when they’re starting out and know just enough to be dangerous. Are my following ‘notes’ largely true or wholly incorrect??

  1. A DHCP server is responsible for handing out IP addresses. If the devices connecting to a device hosting a DHCP Server have static IPs set on/within them, a DHCP server need not be running for them to connect…
    • … so long as they’re connecting to the right subnet as setup on the routing device.
  2. A static mapping within a DHCP server is not the same as a static IP set on a device…
    • The former is an instruction to a DHCP Server that says when device A (represented by a MAC address) asks for an IP, give them this one.
    • The latter is the device not asking for an IP, and merely asserting it has the one you saved within it.
  3. Both approaches independently or in concurrent use, can lead to conflicts, where two devices try to use the same IP, so care should be taken in assignments.
  4. It’s good practice to set on-device the IP of things you want to be able to reach consistently i.e. at a known IP address (NAS, Managed Switch etc)
  5. It’s good practice if running a DHCP Server on the same subnet to create a pool that doesn’t include those device-set static IPs…
    • AND to set a matching static mapping in the DHCP Server anyway as a form of ‘reservation’.
  6. Static Entries in ARP tables and Static Mappings in DHCP look like they’re same but they’re only related…
    • The mapping is just an instruction as stated earlier; Dear DHCP, when MAC approaches you for an IP, give it this one.
    • ARP table is used in the guts of routing. It is the router’s “state” data; the current understanding of the associations of MAC to IP addresses.
    • If you want a consistent MAC/IP pairing, the DHCP can be setup to reliably give a particular MAC the same IP every time the MAC requests one, resulting in the ‘same’ entry appearing in the ARP table.
    • In a router like pfsense you can therefore create a matching permenant ARP entry when creating a static mapping.
    • The mapping and entry however are discrete from one another; deleting the mapping or stopping the DHCP server does not remove the permenant ARP entry(s).
    • So you can have a static mapping without a permenant ARP entry, and you can have a permenant ARP entry without a static mapping (or in fact a DHCP server at all).
  7. Permenant ARP entries can provide some degree of security, because a device only has access to a particular IP if it’s MAC matches the MAC/IP entry and the same combination is not occupied.
  8. A malicious device would have to…
    • Spoof a listed MAC address
    • Set itself to have the same IP as associated with that MAC address
    • Connect when the device the original entry was intended for is not connected.
  9. Firewall rules target subnets and IP addresses, so access to a particular IP address (range of addresses) represents permitted traffic.
  10. In a home environment the machines connecting to the network are most likely a small, finite and known quanitity (e.g. two computers and a laptop), so giving them static IPs is trivial and it could be the case that a there’s no need for the D.ynamic C.onfiguration provided by DHCP.
  11. However any device that knew the subnet and a free IP, could get on the network by just setting it’s own IP statically (assuming it had some connection to the network).
  12. Permenant ARP entries do not prevent this because you can’t have a ‘permenant-only’ table; when the unwelcome device connected an ARP entry would be created for it and you can’t set an instruction that does not permit the entry’s creation.
  13. A DHCP server can be set to only hand out IPs to MACs it recognizes but a device can just use a static IP and not contact the DHCP server.
  14. Firewall rules tend to reference subnets over specific addresses within it. For example you say safe net can communicate with stuff net. You could but typically don’t set up a rule for each expected IP inside of safe net.
  15. Thus even though you know what MAC addresses should be the only ones on safe net, and you only want those devices to access stuff net, neither DHCP, ARP or Firewall rules are particular designed to achieve this.
  16. Additionally “particular device” security policy is not a valid approach because the way in which devices are identified can be spoofed anyway.
  17. Appropriate security instead relies on building layers. Some degree of preventing devices getting access to the network, some degree of MAC/IP lockouts within the network, some degree of password/key/permissions within the software and services of the network.
  18. Thus typically network security focuses on what devices on the network can do, not keeping unwanted devices off.
  19. In a home environment this means making sure you’re widget is on the right subnet/vlan with limitations on traffic between subnets/vlans.
3

That’s a lot of questions. I’ll try and answer as many as I can one by one.

Let me start by clarifying that DHCP and ARP solve two distinct problems. Networking protocols are organized in a stack (cf. TCP/IP or OSI) with multiple layers. In the TCP/IP model, nodes are addressed using MAC addresses on the link layer. All nodes that share the same “link” can communicate with each other and form a network or broadcast domain. On top of that, a logical addressing system (IP) is used which is also required to reach any node in another network. The data exchanged on different layers of the stack is called different names; on the link layer it is called a frame and on the internet layer it is called a packet. Disregarding the higher layers for brevity, when a systems wants to send an IP packet to another system, it hands that packet down the stack to the link layer. The destination IP address is embedded in the packet. The link layer encapsulates the packet in a frame and sends it to another node. But since it can only communicate with other nodes’ link layers using MAC addresses, it has to look up in a table which MAC address is associated with the packet’s destination IP address. When there is no match in the table, this is where ARP comes into play. Using ARP, a node can ask other nodes on its network “Who has the IP address xyz?”. It then knows who to send the frame to (if the destination IP address is outside of the network, the frame will be sent to the gateway). Ok, enough with the exposition.

Essentially, yes. A network can function entirely without DHCP. However there is not really a notion of “connection” on the link and internet layers.

Correct.

I’m not sure what you mean by “Both approaches independently or in concurrent use”, since that about covers any possible case (only dynamic configuration, only static configuration, mixture of both). Maybe this is answered by question 5.

Yes, very much so. If for some reason the DHCP server failed, nodes with static IP configurations can still be connected to.

The first part: absolutely. You don’t want, by chance, the DHCP server assigning an address that you know is used by another node. Regarding the second part, I have never done that and I have never heard anyone claim that to be useful. Static mappings still have to be inside the pool (at least in pfSense), so it contradicts with the first part.
Edit: I got this backwards. Static mappings have to be outside of the pool.

Correct.

Yes, except it has little to do with routing. Routing happens on the internet layer, not on the link layer. The internet layer is not aware of MAC addresses.

Correct.

Correct. And for that matter, it doesn’t remove dynamic ARP table entries either.

Correct.

I don’t understand that statement. First of all, within a link layer broadcast domain, each device “has access to” every other device in the sense that it can directly address them. Secondly, each device maintains its own ARP table, meaning an attacker will not have the same table as your firewall. So for static ARP entries to provide any degree of security, the question is on which device they are present. Since traffic within a broadcast domain is not routed, it never reaches the gateway/firewall, so it won’t help to have them there.

It can also be on the network at the same time as the genuine device.

I don’t understand what you mean by that. A firewall usually sits at the router, meaning at the interconnection point of multiple networks. Therefore, yes, it works on IP addresses.

Yes. As stated above, DHCP is not a requirement. It is purely for convenience.

Correct. If an attacker had access to a switch port, they could send and receive network traffic.

It is generally possible to turn of ARP, as in the protocol, and use static entries only. But again, it is a question of which device that is done on. Turning off ARP on the firewall will not protect other devices on the network from becoming victims of ARP spoofing attacks.

But what we haven’t mentioned so far is switching. Switches will build a table of which MAC addresses are “connected” to which switch port (which is in part what distinguishes them from hubs). Some switches have a feature which is often called “port security”. That allows to restrict ports to only accept traffic from certain MAC addresses.

Correct.

Yes. There is no harm in making the rules as specific as possible, but without further IP spoofing countermeasures, it does not provide reliably security.

Correct because firewalls operate on the internet layer, not on the link layer.

Correct.

This is kind of a vague statement. Ask 10 people and they will give you 10 different answers as to what is “appropriate”.

I disagree. Think about WiFi, the first thing you do is restrict who can join a network by using a password. There are security mechanisms on the link layer such as 802.11X, so you can “enable” a particular switch port only after success authentication.

Splitting a network up into multiple broadcast domains / subnets is definitely one of the best things you can do for security since all traffic between networks has to go through the firewall.

4

You’re on the right track with the thoughts here.
#8: A malicious device can actually get all or most other devices to communicate with it instead of the normal device on an IP by sending out a flood of unsolicited ARP responses. Unsolicited ARP responses on their own aren’t an issue and there are valid reasons for them to happen - one example is that after a device gets an IP from DHCP it will often send an ARP response as a broadcast at both L2 and L3. But if you flood the network with these, you can more or less take over an IP. This is one way a MITM middle attack can happen on unsecured wifi.

The defense against this is to program static ARP entries in both directions (on the router and the clients), which is impractical. The other defense is to having your router and/or switches intelligent enough to detect and alert for this type of malicious behavior, and possibly isolate it at the switch or AP level. This is something you might see in an enterprise but I wouldn’t do at home.

5

If the DHCP server is integrated with DNS, meaning it uses the hostname from the DHCP request to update the DNS infrastructure, this can be a convenient way to have all your stuff in one place. I do this with Pihole (Pihole is both my DHCP and DNS server, and for things with static IP I configure them statically on the host as well as creating a DHCP reservation. This is instead of entering the static hosts into the Local Entries area, because I just like to see all IPs on the DHCP page)

6

I prefer using the DNS Host overrides for this, but I get your point. Also I mixed things up here; static mappings have to be outside of the pool, not inside, so it doesn’t actually get in the way of the static assignment.

7

Amazing, amazing responses! I think for the beginner (though I’m sorry to lump them all into my mistakes) the actual-vs-analogy of networking is often the point of confusion. We the uninitiated tend to see networks like roadways, data like parcels, routers like sorting offices… and I guess to torture the analogy, MACs as people and IPs like home addresses. This all leads to assumptions that when device A want’s to send something to device B there’s a very structured “route” to do so, handled by a centralized and singular authority; A just sends the data to the postal service who handles the transfer from start to finish. So we buy old hardware off ebay, install untangle/pfsense etc and then starting asking how to rule our networks with an iron first. I at least assumed node B is whoever I allow it to be, residing wherever I permit it to, and that this state is live and synced to the millisecond because the devices are connected as definitvely as the CAT5 lying across the living room floor suggests they are. The nature of time-limited leases, multi-layered protocol stacks, decentralized ARP tables and broadcasts escapes me. I am only starting to correct my mental modeland to see actual networking is more like a bunch of independent nodes making a complex set of interelated agreements.

You could have…

  • a DHCP assign a static IP to one device, but another device not using DHCP use the IP for itself.

  • two devices, neither using the DHCP, set statically to the same IP.

  • the DHCP assign the same IP to two different devices (though the ui/settings work to prevent this)

Sorry I’m probably using the wrong terminology. When setting up a DHCP server in pfsense I’m told the available range, say 192.168.1.0 - 192.168.1.255 and then I input a range to use, (192.168.1.10 - 192.168.1.245).

I’m calling that range an input a pool, meaning the addresses the DHCP server will allocate automatically. This leaves the first and last 10 IPs outside of the pool, and thus free to be used in static mappings without the risk of conflict.

I think this is part of my key misunderstanding based on the mental model of a ridgid authority regulating all traffic.

Perhaps appropriate should be re-worded; I was meaning more technique than strategy. For example as I have learned, you don’t lock down IPs within a link layer because that’s not possible / how they work!! So equally blocking devices with unknown MACs is not possible, and where it is (say in DHCP allocation) it’s important to appreciate what security that doesn and doesn’t provide.

OK so checking my new understanding and leaving out wireless to avoid complicating the concepts.

  1. Three devices A, B, C are plugged into an old dumb hub (basically a cable splitter). This is the “link” layer which we could layman describe as the physical copper cords between them. Each of them has a MAC address (a unique hardware id) and they freely exchange data without restriction by shouting (broadcasting)? No IP, no router, no central plumbing at all. If a malicious device ends up on the same copper as your precious ones, you’re toast.

  2. If a device want’s to send data to someone(s) else specifically, they do so on the next layer which is a purely logical ‘network’ laid over the top of the underlying physical one.

  3. At this layer we need devices at the intersections, not just cabling junctions, so you get routers and switches; which essentially connect independent link layers together with a bit of intelligence; subnets/vlans et al.

  4. In this layer we use IP addresses to navigate, but this is just an abstraction, the packet eventually arrives the same way, by being broadcast over a link layer.

  5. To do that we need to get the data parcel (frame/packet) to the right link layer.

  6. If that is the same link layer the sender is in the sender finds this out by looking at it’s own lookup table?

  7. If not it yells out to everyone in it’s own link layer to see if they have the IP it’s looking for.

  8. Crucially then it’s the devices themselves that report which IP they have (within a link layer) and only then in order to initiate broadcast not as a mechanism of making sure the data is hand delivered to them personally.

  9. Central authorities like DHCP servers only hand out IPs to organize everyone getting the appropriate one.

  10. A router remembering which IP it gave to whom is an adminstrative step but not some sort of concrete reality, because devices in ‘earshot’ of a broadcast (link layer) can just hold their hands up and claim to be whatever IP they like.

  11. So if a device fails to find anyone in it’s broadcast domain claiming an IP it sends it up the chain to a router, which in turn may forward it across (broadcast) in another a sub-network, or forward it up to the next gateway in the chain (until you reach the mighty internet).

  12. The router’s ARP table is it’s list of what IPs lie in it’s sub-networks.

  13. It can have some authority over this (static entries) but it’s mostly a phonebook dictated by the residents of the various link layers.

  14. If another device, connected via another cable to another interface (or same cable / vlan) claims to have a MAC address and an IP, the router just makes a note in it’s ARP and upon recieving something addressed to that IP broadcasts it on the associated interface.

  15. Firewall rules however in the router can basically prevent these broadcasts because before looking up the MAC for an IP (and what interface the MAC lies downstream of) it looks at a set of IP based rules.

8

I suppose when I say malicious device, I’m often mistakenly inter-changing between two different concepts: one, a device owned by a third party not supposed to be on the network, and two, a device meant to be present but behaving maliciously (infected laptop with virus, security exploit etc)

I was (again mistakenly) trying to use network security to handle both eventualities where it applies only to the former. I guess in the case of the latter the advice is use software techniques and good practices to avoid infection, and from a networking perspective not move a portable device (e.g. a laptop) between unsafe public networks and private networks you want to keep safe?

9

No, that’s alright. I made a mistake there, see my answer to brwainer’s post.

There is virtually no security (as in authentication, confidentiality, access control, etc.) on any of the link layer protocols. It was simply not thought necessary when they were invented and we’re still stuck with them today.

Well, switches can do that, but again, there is no authentication. MAC addresses are easily spoofable. So blocking unknown MAC addresses is possible, but it’s not ultimately secure.

Judging by your list I seem to have caused more confusion than clarification. I’ll try to summarize the process.

The idea of a network stack is that any layer does not need to know how the layer below it operates. It just passes data to it and receives data from it. So as far as the Internet Protocol (internet layer in TCP/IP or layer 3 in OSI) is concerned, Ethernet (link layer in TCP/IP or layer 2 in OSI) could use magic to handle the data it gets passed.

Again, for brevity, I’ll disregard the layers above the internet layer. Say there are 3 nodes in a network, A, B and C. A wants to send an IP packet to B. It finds that B is in the same network / broadcast domain as itself (judging by its own IP address, netmask and B’s address), so it encapsulates the IP packet in an Ethernet frame. The ethernet frame needs a destination address. Don’t be deceived by the term broadcast domain. This frame is addressed directly to node B (unicast). The MAC address that corresponds to that IP address is looked up in the ARP table. Since the two nodes haven’t communicated before, the table is empty. So A sends out an ARP message asking “who has B’s IP address?”. B will respond, so A now knows B’s MAC address and updates its ARP table. It can now send the frame out on the wire. There is no security here at all and pretty much everything can be spoofed. On the way from A to B, there can (and will most certainly) be switches which will forward the frame only to the port where B is connected to, if it already has that knowledge. This is the first instance where security can be applied (by virtue of the aforementioned “port security” mechanism). If A wants to send another packet to B, the process repeats. However, B’s MAC address can now be read from the ARP table.

Assume C is a router. If A wants to send a packet to a node D outside of its network, it will again encapsulate that IP packet in an Ethernet frame. A knows that it must send that frame to C for routing to the target network, so the gateway’s MAC address is set as the frame’s destination. The router receives the frame, restores the IP packet from it and can now decide whether it wants to accept forwarding the packet or drop it based on firewall rules. If it decides to forward the packet, it encapsulates it in a new frame which is sent out on the correct NIC.

10

This is honestly all the time I can dedicate to this thread, but if you want to dive deep into the network stack, I can recommend this excellent video series by Ben Eater.

11

That is a wonderfully concise example and the kind of explanation I wish preceded more tutorial materials for basic networking setup. I understand most people probably don’t want the theory so much as the practical steps, but not knowing the why of something I’ve found quite quickly leads to confusion and an inability to begin any research or self diagnosis of problems. I am deeply appreciative of the time you have given to educating me on the matter!

12

You are most welcome!

13

Every DHCP server maintains a list of the leases it has assigned and when they expire, so unless you have more than DHCP server in the same broadcast domain (VLAN, or lack thereof) you’ll never see your server assign the same lease more than once. Some DHCP servers perform an active ARP/ping check before assigning an IP, and some clients (most notably iOS) will do the same before accepting an IP.

There is one hole in the scheme: some routers, especially the embedded kind in a home router, will only store their lease file in RAM, so when they crash or lose power or even intentionally reboot, the leases file is lost.

14

To give another example from my professional life:
The enterprise I work for has centralized DHCP and DNS for 1500 branches. If the branch can’t connect to the datacenter, you’ve got no DHCP and no DNS. The DHCP, DNS, and IPAM (IP Address Management, a database to help you remember what IPs you have assigned statically) is one integrated product. This type of product is known as DDI, examples are Infoblox and EfficientIP. By definition within our organization, an IP address is available if the state in the DDI is “Unused”. In this system, these are the states we can manually set for an IP:

  • Fixed Address - what people would otherwise call a “DHCP Reservation”, you supply a name and a MAC
  • Reserved Address - means that the address is defined statically on the device, you only provide a name (you can optionally input a MAC if you want it in the database anyway, but it will not respond to DHCP if the MAC comes calling)
  • DHCP Pool - available for leases, which are then tracked as “Active” and “Expired” and will record the name and MAC

So, we don’t create a reserved or permanent DHCP lease for things that are statically defined, but we do have to do just about the same work, otherwise it is our fault if someone else comes along and picks an “Unused” IP from DDI.

16

So a static mapping says: “give this MAC this IP”, and a Reserved Address in your DDI system says "this IP is claimed by (optionally: this MAC), so just be aware that even though you did not issue a lease for that IP it is not “unused”?

In a smaller network without an IPAM like that however it’s not common, or maybe even recommended, to simulate a reserved address with an un-utilized static mapping. Instead best to leave any on-device IP’s outside of the DHCP pool/range and just make a manual note for what IPs you’re putting statically on what devices?

17

In all cases, statically programmed IPs should exist outside of the DHCP Pool. Some DHCP servers allow you to create lease reservations outside of the pool, and for those I see no issue in creating a reservation that duplicates the static programming. If you put in the correct MAC, it can even make things easier if you do something like reinstall the OS, when it initially uses DHCP it’ll end up on the same address (if you properly input the MAC address). If the DHCP server is the rare kind that requires reservations be inside the Pool, then you obviously can’t do this, and have to rely on something else.

For a home or small business with 1-2 locations and less than 5 subnets, IPAM and even a spreadsheet is unnecessary. Beyond that though, having at least a spreadsheet becomes a huge help, and beyond 10 subnets some type of IPAM is recommended, especially if you set it up to do period ping checks to discover used IPs (maybe ignoring the DHCP pool). I wouldn’t go DDI if not an enterprise with hundreds of IT professionals supporting tens of thousands of users.

For open source IPAM, the hot name is NetBox, but that is designed for datacenter use - it was created by Netflix or Cloudflare, don’t remember which and don’t care to look it up. Some of the HomeLab YouTube channels have shown it, and it doesn’t look like a good fit for me (four VLANs for home, plus three VLANs for homelab/freelance, plus three remote networks I actively monitor for friends and family). Instead I use phpIPAM, which was average difficulty to set up compared to other projects in the pre-container era.

19

Thanks you, that has helped me get a much better basis for making decisions going forward.

This is a great forum and I really appreciate the time and patience you have shown in answering my question.