2100 DHCP VLAN configuration
-
Hey folks,
I have followed several guides about how to go about setting up VLANs with the 2100 (updated to version 24.11) and its built-in LAN switch ports, and as far as I can tell I've got everything configured correctly - but I'm having some trouble getting devices to get addresses via DHCP.
The symptom is that I don't get a DHCP address. In the DHCP server logs, I see that the server is regularly receiving DHCPREQUESTs on the configured VLAN interface, and is returning a DHCPOFFER, those packets apparently never make it back through the switch to the client.
My goal here is to have each switch port drop untagged traffic (or dump it into a VLAN that we don't listen on or care about, which I think is what we get with the default VLAN 1 as long as you don't configure the LAN interface?), but support ~4 tagged VLANs with different non-overlapping subnets so that I can control routing between them with firewall rules. In my screenshots later you'll no doubt notice some of the rules I already applied...I can reapply those easily with Ansible so if I need to nuke them for debugging that's fine but I'd rather just shove an allow-all at the top to avoid that.
Reading the docs, I don't think I want to change the port VID in the switch config - my reading of that value is that this would be how you would separate the switch ports out to be separate from each other and I don't really want that, I just want these ports to pretty much all be the same config, so having them all VID 1 seems fine...but maybe that's where I'm going wrong? I don't know.
Here are a few screenshots of what I hope are all of the relevant configuration...
First, the switch VLAN config:
Next the VLAN definitions for the router:
Next the firewall rules for LAN and MANAGEMENT interfaces (LAN being as far as I can tell the switch uplink to the router SOC,
mvneta1).I think these temporary allow-all rules should make sure we're good to go passing all traffic.
LAN:
MANAGEMENT:
Lastly here's what the DHCP server logs say, this is repeated every few seconds but it's always the same 2 lines:
Anyway I'm sure I'm just missing something, but unfortunately the docs for the switch ports on the 2100 are far from comprehensive and I don't see any obvious explanation as to what I'm missing. Please help!
-
@thalin VLAN200 will leave the 2100 tagged on all ports and now on the other end you gotta have either a switch that can handle VLANs or a client that is configured to handled VLAN200 tagged traffic.
How is the network looking after the 2100? Can you draw a simple diagram, like "internet - 2100 - VLAN-awar-switch - clients"?
And can you post a picture of the switch port configuration?
-
Yup what do you have attached to the 2100 ports? It needs to be something that can handle the tagged traffic.
If you have left the PVID as 1 on all ports though it must be arriving tagged as 200 though since the dhcp discover traffic has made it through.
-
Hey folks, thanks for the response! I appreciate your willingness to respond and maybe help!
I apologize for not being a bit more detailed here. I thought it was clear that since the 2100 is getting the DHCP request on the management VLAN interface (mvneta1.200), the client device was indeed requesting an address using that VLAN tag.
For context this is a unifi switch (US-8-60W) connected port 1 on the switch to LAN port 1 on the 2100, with the "Network Override" option on the US-8-60W set to the correct VLAN. This is the setting which tells the Unifi device which VLAN tag to request its management address on. Thus, the DHCP request to the 2100 is tagged on the correct network (not untagged, which would be the default behavior for these devices).
This is how I do most of my Unifi gear in other places (this works great with a Netgate 6100, but it has native ports, not a switch, which I think is the complication that I'm not understanding and getting correct here) even though it's probably unnecessary to have a separate management network. In this case it's also standing in for a more necessary requirement to have some traffic split off because of actual business requirements. Once I get this working I'll be able to replicate it for the other VLANs which will be needed.
So to explicitly state the problem I'm having:
- the traffic is tagged on the way in from the client
- the 2100 gets the request on the tagged vlan
- but the replies never make it back to the client for some reason I don't understand.
Hope that helps clarify the situation!
-
Also here are the requested diagrams/screenshots:
Switch port config:
Network diagram (it really is this simple right now, I'm configuring it through a Wireguard link so there is literally nothing else plugged into the device, and nothing plugged into the US-8-60W - the switch itself is the only client):
-
Ah so the DHCP client here is the switch itself? Hmm.
As you say it appears the dhcp replies never reach the client. Hard to see how that could happen though.
Try running a pcap on mvneta1, including tagged packets, for dhcp traffic on udp ports 67 and 68. Make sure it is actually sending the replies.
-
Yep this is one of the first things I did, so I have a pcap from pretty early on, before I posted this thread. I can definitely see the offer going out from the 2100. I will see if I can get a pcap from the client perspective today. Anyway, here's a screenshot from the pcap I did in pfSense:
-
Are those redacted addresses public IPs?
Are the MAC addresses correct in the replies?
Is the VLAN tagging correct?
The client is not the switch itself then?
-
@stephenw10 said in 2100 DHCP VLAN configuration:
Are those redacted addresses public IPs?
Nah, just don't want to spew private ip blocks around on the internet (I know, paranoid and probably unnecessary).
@stephenw10 said in 2100 DHCP VLAN configuration:
Are the MAC addresses correct in the replies?
Yes the MAC addresses seem correct. On one of the DHCP Offer packets, the destination MAC is the MAC I see in the Unifi UI for the client device, and the source is the MAC for
mvneta1on the 2100.@stephenw10 said in 2100 DHCP VLAN configuration:
Is the VLAN tagging correct?
This capture was done on the VLAN interface. I will have to go do another capture on the LAN interface of the 2100 to see if the VLAN tagging is correct - though I assume it is at least for the traffic to be showing up there... I'll do another capture anyway to make sure that the replies are actually tagged.
EDIT: Yep, capture on the parent interface confirms that the offer packet is tagged on the correct VLAN:
@stephenw10 said in 2100 DHCP VLAN configuration:
The client is not the switch itself then?
Incorrect, the client is currently the US-8-60W Unifi switch. I was trying to say that I could swap out the switch as client and get another computer to do captures on the client side since afaik I can't do a client-side pcap from the switch.
-
Hmm, well I guess I would test a client that isn't the switch just in case it has some quirk that prevents it using a VLAN correctly for management. But if you used that same setup on a 6100 it should work here too.
Otherwise a pcap at the client will at least show if it reaches it.
