PfSense as DHCP server and DD-WRT as access points: DHCP not passing thru DD-WRT
-
BTW, I know (99%) its a DHCP issue because the IP gets set to 169.XX.XX.XX
I see Discover, Offer, Request, Ack.
Where in the network is that capture taken from?
-
No, no, no.
Get the wireless clients on the dd-wrt device on the same layer 2 network with the pfSense interface and turn off all DHCP in dd-wrt.
My dd-wrt router has a static ip on my lan with pfsense as the gateway. For some unknown reason, my wireless clients are unable to obtain an ip without dhcp forwarder.
-
You would not need a forwarder, the wifi is bridged to the lan in dd-wrt.. You clearly see the discover and offer from that sniff
Why would you do the sniff from your wired client? Just do it on pfsense interface under diag. You have a release highlighted But under that I see discover, offer and request.. Which have to assume is your wifi client.
-
No, no, no.
Get the wireless clients on the dd-wrt device on the same layer 2 network with the pfSense interface and turn off all DHCP in dd-wrt.
My dd-wrt router has a static ip on my lan with pfsense as the gateway. For some unknown reason, my wireless clients are unable to obtain an ip without dhcp forwarder.
There is no "for some unknown reason" about it. It's because your wireless clients and your pfSense interface are not on the same layer 2 network. Your ddwrt is still being a router, not a bridge.
-
Just to make sure this is the screen that is being talked about to sniff and this is the settings that have to be in place:
-
Doesnt really show anything different really. Opening the packet file in Wireshark shows this:
BTW, I did it from a wired client the first time around because I have port mirroring enabled on the switch and everything is mirrored to this wired client so it should be picking up anything that passes thru the LAN interface.
The switch is a Netgear GS108E
-
Look at the MAC address of the DHCP server in your capture. I'd bet it's not your pfSense LAN port.
I'll also bet you have pfSense on 192.168.1.1 and ddwrt WAN port getting an IP address from pfSense, then you have the ddwrt LAN also set on 192.168.1.1 with DHCP enabled and it's giving IP addresses to your wireless clients.
That just can't work.
Put your ddwrt in bridge mode (I think they stupidly call it "router" mode or something, which confuses everyone involved.)
-
Look at the MAC address of the DHCP server in your capture. I'd bet it's not your pfSense LAN port.
And no, I wouldnt spoof the mac address as a NIC from a VMWare vendor. The server is the pfSense LAN.
(On a side note, do I have to hide the mac address from my ESXi machine or can it still be identified?)
I'll also bet you have pfSense on 192.168.1.1 and ddwrt WAN port getting an IP address from pfSense, then you have the ddwrt LAN also set on 192.168.1.1 with DHCP enabled and it's giving IP addresses to your wireless clients.
That just can't work.
Put your ddwrt in bridge mode (I think they stupidly call it "router" mode or something, which confuses everyone involved.)
-
YOu don't have to hide a mac address from any machine.. Only thing you might want to hide mac from would be radio of AP wifi router that could be in some war driving database, etc. While mac are unique - unless we were going to track down by the maker of said device where that product got sold, then with them who they sold it to and such, etc.. While they might be able to do that on TV and the movies with a few clicks of the mouse - in real life its a bit harder ;)
Well there you go pfsense is seeing discover and sending offer.. What IP is being offered? Also since you see the request the client got the offer - so seems more like a client issue to me. So why don't you post up that sniff so we can take a look at the details. Or atleast email it to me - you know me from way back ;)
From that discover, offer, request, ack sure looks like a complete dhcp transaction to me. So you have multiple clients that can not get an IP from dhcp, or just 1 device? Or type of device like your ipads, or such.. Post up that actual sniff so can follow the details. Why don't you sniff on the wifi client now.. Maybe just the ack is not being seen? Lets see a longer sniff - does it just keep asking and asking.. It should ask a few times before it goes to APIPA if its not seeing the ack.
-
So why don't you post up that sniff so we can take a look at the details. Or atleast email it to me - you know me from way back ;)
I can attach it here. In theory, it shouldn't have any identifiable information as it just looks at DHCP information.
From that discover, offer, request, ack sure looks like a complete dhcp transaction to me. So you have multiple clients that can not get an IP from dhcp, or just 1 device? Or type of device like your ipads, or such.. Post up that actual sniff so can follow the details. Why don't you sniff on the wifi client now.. Maybe just the ack is not being seen? Lets see a longer sniff - does it just keep asking and asking.. It should ask a few times before it goes to APIPA if its not seeing the ack.
Ive done diagnostics more on my Windows 8.1 laptop than my Android smartphone but I do not have internet access on my Android smartphone either so I GUESS the issue is the same.
OK so Im gonna do the following:
1: Set my laptop as DHCP client again (im typing this to you from the laptop since it is static)
2: Start a packet sniff from pfSense
3: ipconfig /release
4: ipconfig /renew
5: Wait about a minute
6: Stop the packet sniff from pfSense
7: Post it hereDoes that sound good?
-
sure - but send up that other sniff as well from pfsense.
What exactly is release renew for - once you switch from static to dynamic it would request ip…
You already have the sniff be it at mirror port or pfsense -- do sniff on client as well. From the sniff you showed it looks to be a full dhcp transaction.. discover, offer, request, ack
dhcp servers dont send out offers unless they see a discover, and clients don't send out requests unless they see the offer. So clearly client and server are seeing each others traffic. Only question is did it not see the ack for some reason. So sniff on client tells you that side of the story.
And looking into the details of the offer and request and ack tells you what was offered what was requested, etc. If you don't see another discover or request then you got a client problem where thinks it has IP but is not actually setting it on the interface, etc. Because if for some reason it didn't like or see the ack it wold send out more requests or discovers.
-
Put your ddwrt in bridge mode (I think they stupidly call it "router" mode or something, which confuses everyone involved.)
My ddwrt is configured as Gateway mode, WAN disabled and DHCP Server disabled now. Wireless clients obtain ip from active DHCP server on lan.
-
sure - but send up that other sniff as well from pfsense.
What exactly is release renew for - once you switch from static to dynamic it would request ip…
Just to force it a "release" and "force" a renew.
You already have the sniff be it at mirror port or pfsense – do sniff on client as well. From the sniff you showed it looks to be a full dhcp transaction.. discover, offer, request, ack
Sorry for the stupid question but can I sniff in Wireshark with a 802.11n adapter under Windows correctly?
Im gonna see if I can do this now as Im a bit in a hurry…
-
Yeah this is really dead simple to turn any wireless router be it running dd-wrt or native firmware as AP. You connect it to your network with a lan port and disable its dhcp server = AP. You don't even really need an IP on your lan if you don't want - that just makes it easier to admin the wifi portion from your network is all.
Its actual lan ip has nothing to do with bridge the wifi to to the lan ports.
It seems clear to me from the sniffs, and that wired clients on the dd-wrt is getting dhcp fine that must be something wrong with the client to be honest. Once we see sniff on the wifi client we can be sure - but he has shown in sniffs a full transaction discover, offer, request, ack.. That the client doesn't get the ack but gets the offer and sends a request seems odd.
I would guess something wrong with client. Once we see the full sniff and details of offer and request and ack maybe we will know more, etc. But the mode of the router be it gateway/router/ap sholdn't really matter in pretty much every mode it bridges the wifi to the lan, and clearly there is discover going out on the wired lan for pfsense to see and send out a offer, etc.
edit: unless windows sniffing wifi ? What? Your not sniffing the wifi traffic off the air, your sniffing the traffic that the client sees once its authenticated to the wifi network.. You should have on problems sniffing that be it windows, linux, bsd, whatever.. Here I fired up wireshark, connected to wifi network - here is it seeing traffic. Notice the DELL, that is my built in wifi adapter – nothing fancy, etc. Where you can have problems is sniffing the raw wifi traffic without being authed to the wifi, etc.
-
Change to RAR and check your pm johnpoz
-
This is from your sniff on the client called client1.cap
It shows your client releasing 1.88, then requesting 1.88 and then the dhcp server giving it 1.88 with the ack,.
If your client is showing that it doesn't have an IP address, then that is on the client - because from this it clearly thinks it does. It even releases that IP back to the dhcp server before it asks for new one and gets back 1.88 again, etc..
But your client clearly shows ACK for the dhcp transaction when you sniff. So your issue is with client nothing to do with pfsense or dd-wrt.
I hid your mac because you had done that previous, and not my place to say what or what you don't want on public forum, etc. But it all the same mac, etc..
-
Everything is also in Status->System Logs->DHCP on pfSense.
-
This is from your sniff on the client called client1.cap
It shows your client releasing 1.88, then requesting 1.88 and then the dhcp server giving it 1.88 with the ack,.
If your client is showing that it doesn't have an IP address, then that is on the client - because from this it clearly thinks it does. It even releases that IP back to the dhcp server before it asks for new one and gets back 1.88 again, etc..
But your client clearly shows ACK for the dhcp transaction when you sniff. So your issue is with client nothing to do with pfsense or dd-wrt.
I hid your mac because you had done that previous, and not my place to say what or what you don't want on public forum, etc. But it all the same mac, etc..
So with this you are saying it is a Windows 8.1 problem?
Before making this post, I thought back about what you said that it was only this client so I ran a few tests.
With my Android smartphone, it does seem to get a IP from the pfSense and it can access the internet.
So you mentioned its a problem with the client…..so I want ahead and tested if the problem is the laptop or Windows 8.1
I loaded up a LiveUSB with Ubuntu on the same laptop and IT GETS A IP AND CAN ACCESS THE INTERNET.
I took ANOTHER step. Windows 8.1 Safe Mode with networking. Same thing so the problem is obviously Windows 8.1
So now what? >:( It is so frustrating that at the end of the day its the fault of a operating system that randomly decides not to work.
Obviously this is WAY out of the scope of pfSense so Im not sure what do to/ask anymore...
Everything is also in Status->System Logs->DHCP on pfSense.
Yup. It shows basically the same thing johnpoz posted in the pictures.
-
Wired works.
Oh fuck this…..now it suddenly works. I plugged the wire, unplugged the wire, tried to connect via wifi, and now it gets the IP, gateway, everything thru DHCP.....
-
Same thing is in the logs for this, but its best to see with your own eyes sometimes what is happening with these protocols vs just a log dhcp server saying it sent offer, etc..
For you 8.1 problem - try resetting the tcp/ip stack. In elevated prompt
netsh int ip reset
or netsh int ip reset c:\path\resetlog.txt
if you want a log. Also check firewall settings and or antivirus/security software.. What is odd is it releases the address, so it knows it has it - just not showing/using it. Try the reset of the stack.
