Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved DHCP and DNS
    5 Posts 5 Posters 4.6k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      sjwk
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • M
        Metu69salemi
        last edited by

        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

        1 Reply Last reply Reply Quote 0
        • C
          cmb
          last edited by

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

          1 Reply Last reply Reply Quote 0
          • M
            micha 0
            last edited by

            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

            1 Reply Last reply Reply Quote 0
            • jimpJ
              jimp Rebel Alliance Developer Netgate
              last edited by

              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.

              Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

              Need help fast? Netgate Global Support!

              Do not Chat/PM for help!

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.