4

I am using centos 7 with dhclient 4.2.5:

$ uname -a
Linux hostname 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

$ dhclient -V
Internet Systems Consortium DHCP Client 4.2.5
Copyright 2004-2013 Internet Systems Consortium.
All rights reserved.

Recently I noticed that logs contains lots of following records:

Dec 14 10:12:32 hostname dhclient[4186]: DHCPREQUEST on enp5s0f0 to 10.23.0.4 port 67 (xid=0xe1a88f7)
Dec 14 10:12:49 hostname dhclient[4186]: DHCPREQUEST on enp5s0f0 to 10.23.0.4 port 67 (xid=0xe1a88f7)
Dec 14 10:13:09 hostname dhclient[4186]: DHCPREQUEST on enp5s0f0 to 10.23.0.4 port 67 (xid=0xe1a88f7)
Dec 14 10:13:23 hostname dhclient[4186]: DHCPREQUEST on enp5s0f0 to 10.23.0.4 port 67 (xid=0xe1a88f7)
Dec 14 10:13:41 hostname dhclient[4186]: DHCPREQUEST on enp5s0f0 to 10.23.0.4 port 67 (xid=0xe1a88f7)

It seems to be due to DHCP server which ignores unicast requests. There are other people with such problem: https://forum.pfsense.org/index.php?topic=51701.0

I have tried to change packet destination ip to 255.255.255.255 with iptables:

sudo iptables -t nat -I OUTPUT 1 -d 10.23.0.4 -p udp --dport 67 -j DNAT --to-destination 255.255.255.255

But for some reason rule is not matching packets from dhclient. However it is matching packets from nc: echo 123 | nc -u 10.23.0.4 67

I have found this link where said that dhclient works in a different way that is not processed by iptables:

For most operations, DHCP software interfaces to the Linux IP stack at
a level below Netfilter. Hence, Netfilter (and therefore Shorewall)
cannot be used effectively to police DHCP. The “dhcp� interface option
described in this article allows for Netfilter to stay out of DHCP's
way for those operations that can be controlled by Netfilter and
prevents unwanted logging of DHCP-related traffic by
Shorewall-generated Netfilter logging rules.

So I have a couple of questions:

  • is it correct that dhclient uses some lower level API that is not processed by iptables?
  • are there any way to reduce amount of logs from dhclient for unanswered unicast requests?
4
  • is it correct that dhclient uses some lower level API that is not processed by iptables?

Short version: yes, for some DHCP servers (isc-dhcp and early versions of dnsmasq), no for some other servers (later versions of dnsmasq).

Longer version: the origin of the matter is a raw socket. A raw socket is, according to Wikipedia,

... an internet socket that allows direct sending and receiving of Internet Protocol packets without any protocol-specific transport layer formatting.

This ISC Wiki page (the Internet Systems Consortium is the author of the most common DHCP program) states that:

The DHCP protocol has some specific requirements to really work properly - in particular being able to transmit to and receive packets sent to the all-ones limited broadcast address (255.255.255.255), and being able to send a unicast without an ARP. It's not possible to do this via BSD/UDP sockets although dhcpd does also open a BSD/UDP socket (called the "fallback interface") that you will see in netstat.

This is interesting, because it explains why you will often find, by Googling, people trying to control DHCP requests in iptables via the UDP ports 67 and 68. Of course, it is not that these ports are not opened, it is only that this is not the only channel thru which communication between server and client takes place.

This however cannot be fully successful: some guys have gone to the extreme of shutting out their machine completely (iptables drops everything!), yet they were unable to close themselves off to DHCP via raw packets).

Another interesting experiment is to use, once again iptables to shut off one's pc, and then to use a raw socket for DNS, or for TCP connection: despite iptables, these communication attempts succeed.

A very authoritative comment on this can be found on the Netfilter site, where it is stated:

Raw sockets bypass the TCP/IP stack. Netfilter hooks, and consequently iptables, sit inside the IP stack.

And the same applies to packet sniffer.

Here they also explain how to circumvent the problem: careful, it's a joke, Schaaf states

That's not a weekend project.

Lastly, I would also like to point out that the situation is different for dnsmasq: in a Debian Wiki page, dnsmasq's author Simon Kelly states:

Dnsmasq opens a raw socket but it never reads data from the socket: instead it's used to talk to DHCP clients which are not yet fully configured and cannot do ARP. This is not a security problem. Later versions of dnsmasq use a different technique, and no longer have a raw socket open.

Edit:

are there any way to reduce amount of logs from dhclient for unanswered unicast requests?

This is not trivial, because the CLI option to reduce the output from dhclient, -q, can be invoked from the CLI, but not from dhclient.conf. Also, dhclient is called directly not by your Network Manager in general, but by an executable, ifup: in fact,

# strings `(which ifup)` | grep dhclient
/sbin/dhclient
/sbin/dhclient3
dhclient -v -r -pf /run/dhclient.%iface%.pid -lf    /var/lib/dhcp/dhclient.%iface%.leases %iface%
dhclient3 -r -pf /run/dhclient.%iface%.pid -lf /var/lib/dhcp3/dhclient.%iface%.leases %iface%
dhclient -1 -v -pf /run/dhclient.%iface%.pid -lf /var/lib/dhcp/dhclient.%iface%.leases %iface%  [[-e IF_METRIC=%metric%]]
dhclient3 -pf /run/dhclient.%iface%.pid -lf /var/lib/dhcp3/dhclient.%iface%.leases %iface%      [[-e IF_METRIC=%metric%]]
dhclient -6 -r -pf /run/dhclient6.%iface%.pid -lf /var/lib/dhcp/dhclient6.%iface%.leases %iface%
dhclient -1 -6 -pf /run/dhclient6.%iface%.pid -lf /var/lib/dhcp/dhclient6.%iface%.leases %iface%
dhclient -1 -6 -S -pf /run/dhclient6.%iface%.pid -lf /var/lib/dhcp/dhclient6.%iface%.leases %iface%

As you can see, ifup invokes dhclient with the -v (= verbose!) option, the opposite of what you wish.

What are your options?.

  • Download the source code, modify the invocation above, and recompile it for your kernel. It should be a cinch.

  • You can use a binary editor to convert the -v into -q.

  • You can modify a script file, /etc/init.d/networking, by replacing the invocation of ifup with

    ifup .... > /dev/null 2>&1
    

    A reboot, or a restart of the networking service, will complete this modification. This is less than ideal because it throws into the garbage both useless warnings and serious error messages.

  • Lastly, you can carry out the following hack: move /sbin/dhclient to /sbin/dhclient-true, then create an executable file called /sbin/dhclient with the following content:

     #!/bin/bash
     ARGS=$(echo "$@" | sed 's/ -v / /g')
     exec /sbin/dhclient-true "-q" "$ARGS"
    
  • added version information, it is centos 7 with dhclient 4.2.5 – misha nesterenko Dec 14 '15 at 20:11
  • Oh, this is windows server 2012, but I don't have access to configure it unfortunately – misha nesterenko Dec 15 '15 at 8:57
0

DHCP is how a client gets an IP in the first place, so if it used IP it would be chicken and egg. Thus, it operates on a level below, L2, using MAC addresses. Thus IP routing is oblivious to its existence.

I don't use PFSense at the moment so I cant point your specifically but there should be a log verbosity setting, if you set it lower you should only see warnings.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.