DHCP Server not working on VLANs



  • DHCP Server is not working on VLANs but connectivity fine when client machine configured static.    Only entry in DHCP Server log is after listening / sending is: dhcpd: Sending on Socket/fallback/fallback-net.  Any ideas about how to diagnose / fix?


  • Rebel Alliance Global Moderator

    Well are you seeing the discovers?  Impossible to send a offer if never seeing a discover.

    Simple packet capture on your vlan interface would show you if seeing the discover.  If you see the discover and no offer sent then what is in the discover could point to why its not working.  The dhcp server doesn't think its for it?



  • @VBS:

    Does your endpoint VLAN switch untag the packets on egress and apply tags on ingress?

    I had the same issue with VLANs not receiving DHCP until i realized that my switch was passing the packets still tagged.
    The only reason for packets to leave a switch still tagged is when it's en-route to another vlan-capable switch/router that needs to deal with it accordingly.

    By having the switch untag the packet when it exits the port that the PC is connected to, the PC will be unare of the existance of a "vlan5" an treat "vlan5" as it's physical network.
    The same port must also be set to tag incomming packets with the VLAN ID so your router knows what to do with them.
    (A PC may ignore traffic with VLAN tags as it may not know it's supposed to be a member of a VLAN - and which one.)

    Process:
    [pfsense]–"vlan=5"-->[Switch]–->[PC]
    1. pfsense sends the packets out tagged as "vlan5"
    2. the switch receives the packets tagged as "vlan5"
    3. the switch allows the packets to exit on a port that is a member of "vlan5"
    4. the switch untags the packet as it leaves the port to the PC.
    5. the PC receives the packet untagged.

    [PC]–->[Switch]–"vlan=5"-->[pfsense]
    1. the PC sends the packet untagged.
    2. the switch tags the packet as it enters the port from the PC.
    3. the switch allows the packets to exit on a port that is a member of "vlan5"
    4. the packets leave the switch still tagged as "vlan5"
    5. pfsense receives the packets tagged as "vlan5"

    You'll also need to make sure your switch doesn't send any of the untagged traffic to "vlan5" member ports so you don't end up with a DHCP war. (How easy that is to accomplish will depend on the specific device.)
    Also: Only 1 vlan per port - with the exception of "trunk ports" to other switches/routers that handle traffic for multiple vlans.
    I just opted to convert my main LAN to a VLAN too and use only VLANS to avoid confusion when managing the switch.

    To Illustrate:

    • Traffic between VLAN-capable devices has VLAN tags - those ports are "tagged" members of all VLANs.
    • Traffic between the last VLAN-capable switch and PCs / standard (non-VLAN) APs has no tags - the switch adds/removes the tags as traffic exits/enters the port. (e.g. The first red port is an "untagged" member of VLAN 10, with the PVID set at 10)

  • Netgate

    Yet another who says it works fine if they set a static IP.  Wonder if it's the same person.

    Port 2 [Connected to "LAN 1" that doesn't need to be further segmented] =  Member of: vlan10 - Untagged Egress, Tagged Ingress: "vlan10"

    WTF is that?  This is why I do not mix tagged and untagged traffic on interfaces unless absolutely necessary.

    Let's take a closer look at this described behavior.  Port 2, as stated, sends VLAN 10 frames untagged but expects to receive them tagged.  I have never seen a switch configurable like that, but I will assume there are some that, if the PVID is 10, will place frames received tagged with the PVID or untagged on the PVID.

    So it sends frames on VLAN 10 untagged.  That means the other side is treating that VLAN as untagged and will send frames on that VLAN untagged.  But that means Tagged Ingress: "vlan10" cannot happen because the port sending to that device will send the frames untagged, not tagged, so which is it?

    D-Link might do it one way, TP-Link, another, Cisco, another, TrendNET another and hopefully whatever I'm using will just drop the damn thing.

    untagged ports should be untagged.  Tagged should be tagged.  You will save yourself half-a-lifetime of hair-pulling if you just do that.



  • ^ Maybe my wording was unclear.
    Traffic gets "untagged" upon egress and it gets "tagged" upon ingress. The PVID is applied to traffic entering the port untagged.

    Ports can be configured for traffic to enter and leave the switch with VLAN tags intact. (e.g. For ports which are members of multiple VLANs: for traffic to/from pfSense or other switches)
    However, the switch can be configured to remove the VLAN tag upon egress (in order to pass the traffic untagged to a non-vlan-capable devices) and add the VLAN tag by PVID to untagged traffic entering on that port.

    That way, everything beyond that port is blissfully unaware of the VLAN environment.

    TP-Link, Netgear, and HP layer 2 switches (possibly others as well) work this way.

    I just suggested one thing to check - as fixing those settings on my switch solved my DHCP issues.
    (Leaving the packets tagged all the way to the devices broke DCHP in my case.  It works perfectly with the setup I described, so I won't be messing with mine any further.)


  • Netgate

    The only time a frame is tagged or untagged is when it is coming in from or going out on the wire.

    Referring to tagged/untagged anywhere else is confusing.

    When it's inside the switch it's on a particular VLAN without regard to the terms tagged or untagged.