DHCP over VLAN not working



  • Hi,

    I got a VLAN setup (VLAN5) and its using the same interface as the standard LAN.

    I have 2 DHCP servers setup, one for LAN and one for VLAN5. The switch is a managed switch and supports VLAN. The device does not get an IP addresss from the DHCP server when on the VLAN.
    If I enter the IP information manually, it works flawless.

    Any suggestions?


  • Netgate

    Show us what you've done.

    There is nothing special about a DHCP server running on a tagged VLAN interface.



  • 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

    That's all great but he said if he sets a static IP it works fine, so layer 2 might be intact.  Impossible to know what the deal is until he tells us exactly what he has done.

    No magic here.  Tagged, untagged, whatever. Set it up right for the particular circumstances and it works.



  • I know it's "Impossible to know what the deal is until he tells us exactly what he has done."

    I'd speculate that it'd be more likely for a switch or other device to not play nice with VLANs than for pfSense to mess things up.
    Of course, we won't know where to look until OP give us more info.

    I was just suggesting one thing to check before getting too technical - as fixing those settings on my switch solved my DHCP issues.



  • Hi folks,

    sorry, should have provided some details.

    This is the setup:

    UNIFI AP –>(on port 25)--> Force10 S50 Switch -->(on port 48)--> pfsense (latest update)

    This is the setup on the UNIFI AP:
    Main SSID for employees with password, no VLAN assigned, net is 192.168.1.0/24  (EDIT: Typo corrected)
    Guest SSID for public with simple password, VLAN 5, net 10.0.0.0/28

    Force10 S50 Switch:
    *All ports are on VLAN 1 as default (not tagged). I think the switch only works with VLANs.
    Added VLAN5 for the port 25 where the UNIFI is connected to as a TAGGED port. So that port belongs to VLAN 1 & 5 (To allow net 192.168.1.0 & 10.0.0.0).

    PFSense:
    Default LAN setup, nothing fancy, Standard out of box setup. IP is 192.168.1.254 and with DHCP for the lan port. Port NIC is em1.
    Added VLAN5 on em1. Also added DHCP server for 10.0.0.0/28 for VLAN5. I also assigned a static IP to VLAN5 (10.0.0.1; DHCP range is 10.0.0.2-10.0.0.14)

    So, regular LAN is working just fine. The employee wifi is working just fine.

    When I try to connect to the guest wifi, it will not connect (on DHCP). If I assign the ip address manual (IP: 10.0.0.5; 255.255.255.240; Gateway 10.0.0.1; DNS 10.0.0.1), it starts working immediately. By working I mean, that browsing works and I cannot see the 192.168.1.0 network. I also have firewall rules that allow only certain ports and disallow to access to the 192.168.1.0 network. That seems to be working fine.

    So, I hope this helps, if you need something clarified, let me know.

    Cheers,

    Eddi

    PS: I saw the similar post, after posting my reply. Just to clarify, I am not the person posting here: https://forum.pfsense.org/index.php?topic=97816.0.


  • Netgate

    Main SSID for employees with password, no VLAN assigned, net is 192.168.0.0/24

    Is that a typo?  You say 192.168.1.0/24 everywhere else.

    Are you sure you set the right netmask in the guest DHCP server?

    Does the guest wifi get any DHCP at all or nothing?

    The last time I helped someone with something like this it turned out to be some DHCP security settings in the switch.

    You might have to packet capture on the em1_vlan5 interface to see what's actually going on.



  • Hi,

    I corrected the typo.

    The netmask cannot be set in the guest DHCP server (for VLAN5), its there automatically, because I assigned a static IP to VLAN 5 (10.0.0.1/28).

    The netmask is correct, I double checked it again.

    One thing that I thought of when I was writing the detailed description is: I have not added the port 48, where the pfsense/LAN (em1) is connected, to VLAN5. So the port 25 is tagged VLAN5 but not port 48.

    I will have to test it later to night when I am on site. Will report back.

    Any other ideas?



  • You do know that you should never combine tagged and untagged traffic on the same interface, don't you? Not unless absolutely necessary.
    And avoid using VLAN 1 for anything else than nothing. It is used internally in lots of gear and sometimes cannot be changed.

    Configure your LAN as VLAN4 and the other as VLAN5 (or what have you), stack them on one physical interface and connect it to your switch as trunk.
    Setup the switch accordingly and you're ready to go.

    corrected typo


  • Netgate

    How do you expect pfSense to get traffic on VLAN5 if the port isn't tagged with VLAN5?



  • Hi,

    @Derelict:

    How do you expect pfSense to get traffic on VLAN5 if the port isn't tagged with VLAN5?

    I am new to VLANs. Added port 48 to VLAN5 and its working now like a charm.

    @jahonix:

    You do know that you should never combine tagged and untagged traffic on the same interface, don't you? Not unless absolutely necessary.
    And avoid using VLAN 1 for anything else than nothing. It is used internally in lots of gear and sometimes cannot be changed.

    Configure your LAN as VLAN4 and the other as VLAN5 (or what have you), stack them on one physical interface and connect it to your switch as trunk.
    Setup the switch accordingly and you're ready to go.

    corrected typo

    Yes I am aware of that, and in the process of setting up the VLANs properly.

    Thank folks for the good thoughts on this.

    Cheers,

    Eddi


  • Netgate

    I am new to VLANs. Added port 48 to VLAN5 and its working now like a charm.

    The fact that it worked "flawless" with a static IP makes me think something is still probably pretty hosed somewhere.



  • What OP Has Now (in theory):

    • End-to-end communication possible for both networks.
    • DHCP working and isolated appropriately.

    What OP Had (in theory):

    • Communication with other devices on the guest network would be possible.
    • Communication with psfense (and therefore DHCP) should not be possible.

    If two-way communication with pfsense was possible for devices on the guest network, that raises other concerns:
    Was VLAN5's traffic able to return to pfsense untagged somehow…?

    or

    That would make two-way communication possible, but not DHCP, as the lease request and assignment would be on different "interfaces"
    It would also mean that you don't have complete isolation: Traffic from the guest network would be able to bypass the firewall to enter the Main network (but not return that way)…

    To illustrate jahonix's suggestion:

    This should improve isolation and ease-of-management as all traffic would be assigned to a specific VLAN from end-to-end.
    I believe the recommended best practice for pfSense is to remove the untagged interface entirely and use only VLANs. (with the exception of VLAN1 - which should not be used at all: since OP's Force10 S50 switch uses it internally for untagged traffic)


  • Netgate

    Right.  I don't have any Ubiquiti gear right now but I have used it in the past.  It seems to really like being managed on the untagged VLAN, unfortunately.

    You put a lot of time into those diagrams.  Thanks, and welcome to the forum.

    It's better to untag VLAN 4 and tag VLAN 5 to the APs than use VLAN 1.  I got tired of telling people to forget VLAN 1 exists when you start tagging and trunking traffic.



  • @Derelict:

    … Ubiquiti ... really like being managed on the untagged VLAN

    This leads to using tagged and untagged traffic on the same IF as kind of default. Really? Or do they have multiple IFs on the unit to separate VLAN feeds?


  • Netgate

    I have tried to get them to deal with a tagged management VLAN and they reverted back to untagged for some reason.  Might have just been that code level but it left a bad taste in my mouth.