PfSense as DHCP server and DD-WRT as access points: DHCP not passing thru DD-WRT
-
To troubleshoot I would do a sniff on pfsense to see if dhcp discover is even getting there. And if is what mac its coming from.
Ill try that when I get a chance.
But what seems odd is you can not open the pfsense gui when you set static? Do you have rules on the interface that would block that? But normal internet access works if set static on wireless device?
Yes. Normal internet access works once I set static and if set static I can also access the pfSense GUI so it should not be a firewall issue.
BTW, I know (99%) its a DHCP issue because the IP gets set to 169.XX.XX.XX
-
Woah, now this is weird: Wireshark does indeed show that there is a request from my wifi card's mac address….but it seems it doesnt give it a IP address.....
There is the conversation. That .13 is my wired PC that Im doing the sniff from.
-
In DD-WRT Setup - Basic Setup
Network Setup - Network Address Server Settings (DHCP)
In the drop-down select DHCP Forwarder
Enter the pfsense DHCP Server IP
Click Apply SettingsNo, 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.
-
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.
