DHCP relay listening on networks it hasn't been configured to.

[sjwk]

pFSense 2.0.1: I have multiple LANs configured (as VLANs), and pFSense configured to act as a DHCP relay for those networks, and pass requests on to the DHCP server which is in the server VLAN.

Ignoring some of the other networks, I have interfaces for 'Servers' (vlan 300), 'Students' (vlan 20) and 'Production' (vlan 10).  The DHCP relay is configured to relay requests from 'Students' and 'Production' only, and is configured to pass on circuit information as the DHCP server is configured with classing to match on the source interface when assigning an address from the various subnet pools.  That part of it works fine.  However, on client renewals I'm seeing multiple requests coming in.  The server sees requests with no circuit ID, circuit ID=lagg0_vlan10 (which is correct for this client) and circuit ID=lagg0_vlan300 which is the server VLAN and shouldn't be being relayed.  This causes a slight issue, as the server sends ACKs for the first two and NAK for the third as the IP being requested is not valid for that network, so depending on what order the packets are received it may cause clients to disconnect.

I'm guessing that since the client renews by initially trying to talk directly to the DHCP server rather than broadcast, that explains the packet without circuit ID, plus pfSense also sees the packet so relays it on (unnecessary but not a lot can do about that).  Not quite sure why the request originating from vlan300 though, unless the relay is seeing the packet that it just routed itself on the output network?  But it shouldn't even be listening on that interface.

Looking in the system logs I can see that it is listening on three interfaces rather than the two:
Jul 13 11:54:02 dhcrelay: Listening on BPF/lagg0_vlan300/68:05:ca:01:df:58
Jul 13 11:54:02 dhcrelay: Sending on BPF/lagg0_vlan300/68:05:ca:01:df:58
Jul 13 11:54:02 dhcrelay: Listening on BPF/lagg0_vlan20/68:05:ca:01:df:58
Jul 13 11:54:02 dhcrelay: Sending on BPF/lagg0_vlan20/68:05:ca:01:df:58
Jul 13 11:54:02 dhcrelay: Listening on BPF/lagg0_vlan10/68:05:ca:01:df:58
Jul 13 11:54:02 dhcrelay: Sending on BPF/lagg0_vlan10/68:05:ca:01:df:58

So, the question is, why is it doing this?  Is it just that the relay has to also listen on the interface that holds the DHCP server so that it can catch the reply packet and relay it to the client?  But that return packet is being directed to the router IP anyway, so shouldn't need to listen for all packets?

Is there any way to block this?  Largely to avoid cluttering up the network and logfiles with triple the number of packets…  I could block incoming DHCP requests that aren't being sent to the broadcast address, but that'll add a delay to any renewal attempt as it has to wait for the direct connection to timeout before it falls back to broadcasting a discover packet.

Steve.

[Metu69salemi]

Not sure if this brokes something..
I'd put dchp discover(dp UDP 67, sp UDP 68) blocking rule on vlan 300, and set that rule top-of-the-list

[cmb]

dhcrelay has to listen on the interface where the server resides.

[micha 0]

Hi Chris,
can you please tell me why the dhcprelay has to listen on the interface where the server resides?
it is possible to eliminate this?

thx
Michael

[jimp]

IIRC it needs to do that because in some cases the replies from the upstream server may not be directed back at the IP as expected, so by listening on that interface it can receive broadcast traffic there as well.