No DHCP offer accepted by clients
-
What switch are you using, and are you using tagging or physical port assignment for the vlans?
Have you validated that the offers are going out with the right vlan tag on them?
-
The switch is a TP-link layer2 switch (TP-SG3424P).
I know that the request is coming from client on VLAN11 and DHCP is listening on VLAN 11. Fairly sure the Offer is returned by PFSense also on VLAN 11 but will check.
Edit: Yes tagged traffic
-
so can we see the settings page on the switch - are you tagged on untagged on egress?
for the ports in question
Ah – looks like that switch supports dhcp snooping.. That could be causing you some grief.. check out section 12.1.4 of the manual
-
I avoided the DHCP snooping, so that has remained off from the very beginning!
I have two trunk ports, one for PFSense (port 9) and the other for Watchguard (Port 11). Access points are currently on ports 17-20 as 'General' (tagged). We will have a go at changing ports 17-20 to Trunk today, although all traffic should be tagged anyway.
Started to think it's the 'General' config on ports 17-20, the only thing that makes me consider something on the PFSense box is that the Watchguard is working under the same configuration. :o
(For clarity: I am trying to remove the watchguard, but can't until the PFSense box is running. When I run my test I switch off the DHCP on the Watchguard and use the PFSense box)
-
so the clients ae connected to AP, and your vlans 2 and 11, wy aer 17-19 pvid 1?? And those should be trunk, if your wanting clients off those access point to be either 2 or 11? If you just want them 11 then they would be access in 11
I would have to read the details of the manual again for how they are using general ports, but I would read that they are in vlan 1, and 20 is in vlan 2
what do you want? Do you want clients off your AP to be in specific vlans or based upon SSID?
-
Hi JohnPoz
All traffic should be Tagged, PVID 1 is not actually used as we use PVID 2 as the management layer. All hardware is operating at VLAN 2 and clients connecting via access point are on a WAN with VLAN11
There devices should poll across VLAN11 for an IP, which they can do with the Watchguard (VLAN11) but not PFSense (VLAN 11)
there should not be any untagged traffic. The General was a hang up from originally getting the units to move from VLAN 1 to VLAN 2.
I was on site yesterday and moved some of the access points to Trunk, however this did not make a difference.
-
Hmm,
A though. Wondering I should be configuring routes in the Switches for DHCP for each VLAN?
-
routes in your switches? Are they layer 3? You wouldn't be doing routes on a L2 switch, and if you were routing on it there would be a SVI on the switch I would assume.
What AP do you have? There are many AP that do not allow you to tag the managment interface, you can only tag the SSIDs
From what you posted those AP were in PVID 1, not 11 and set to general so they would of been tagged with 1 not 11 from my quick read of the manual of that switch. If you AP has managment interface is suppose to be in VLAN 2, but does not support tagging on the interface on the AP. Then you would need vlan 2 to be the native vlan on your trunk port to the AP.
-
Hi,
the AP's allow to set the management VLAN. This is set to VLAN 2 and Wireless traffic from SSID is route over VLAN 11.
All 'management' traffic is tagged as VLAN 2
-
Swapped the VLAN2 to the PFSense, all the AP's got their IP's OK from the DHCP.
All ports are now Trunk
It is odd that the clients connected to the AP's over VLAN 11 can push out a discover, but the offer never makes it to the client. I think PFSense makes a unicast OFFER, perhaps the Watchguard makes a multicast and that's why it works?
I might look at DHCP routing to see if that helps.
Roofus
-
No it would not be a unicast offer, and no it wouldn't be multicast either.. Offers can not be unicast, since the client does not have an IP yet ;)
An offer would be to 255.255.255.255 dest port 67.. Now if your working with relays then sure stuff can happen over unicast during the relay.
