Unicast DHCP offer from DHCP server not making through pfSense
-
Hi there,
let me explain my setup as quickly as possible first.pfsense has 4 interfaces - dual WAN, DMZ and LAN.
I also have OpenVPN bridged to LAN.There are Wi-Fi guests which are getting their IP addresses from DHCP server running on DMZ interface, 192.168.100.x/24 range.
Guest LAN runs on separate VLAN, but uses the same physical infrastructure.
In other words, pfSense DMZ interface is plugged into a different VLAN.LAN DHCP clients get IP addresses from internal DHCP servers (there are two, redundant), 10.67.20.x/24 range.
OpenVPN road warriors are also supposed to get IP addresses from the same servers. This is where the problem begins.
Windows VPN clients get IP address just fine, but OS X clients do not.
I have wiresharked issue down to fact that Windows clients do broadcast DHCP requests, OS clients do unicast DHCP requests.
As designed, DHCP server replies broadcast DHCP offer for Windows client, unicast for OS X.
OS X client never receives that unicast DHCP offer, even though I can capture these packets on pfSense bridge interface. No idea why.Now, if I disable DHCP server on pfSense DMZ interface for a moment and turn on DHCP relay on LAN interface, OS X clients get happy as well.
How could I possibly work around this and keep DHCP server on pfSense DMZ interface to serve Wi-Fi guests, but also be able to serve OS X VPN clients from LAN DHCP server?Sorry for lengthy explanation.
Cheers,
shpokas -
unicast packets to where? How would they send a unicast to something don't know? You mean they send a directed broadcast vs full broadcast? How does the dhcp client know where to send dhcp packets if it has not had a lease before? How would it even know what what network to send direct broadcast too.. I don't know how a unicast packet is going to find dhcp server without already knowing the dhcp server IP?
Can you post up these packets your capturing..
Macs do rapid dhcp.. They remember last networks and send arps to see if any of those networks are there and then send a dhcp request vs a discover? Is that what your seeing?
-
Here you are. Packet capture logs from pfSense bridged interface (LAN bridged to OpenVPN tap).
Note, pcap extension renamed to jpg.
win.pcap - windows client gets IP 10.67.20.140, bootp flag set to 0x8000 (broadcast). All good.
osx.pcap - OS X client never gets IP, DHCP servers 10.67.20.31 and 10.67.20.34 each are issuing DHCP offer packets. Bootp flag set to 0x0000 (unicast). -
Hmmm to me that would be a problem on the client, normally if that flag is set he is telling the server he wants a unicast response..
http://www.ietf.org/rfc/rfc2131.txt
A client that can receive unicast IP datagrams before its protocol software has been configured SHOULD clear the BROADCAST bit to 0.But your not going to be able to send unicast to that mac address..
-
The point is that I have another site with the same configuration, but allegedly simpler a bit, where this problem does not happen.
I mean, that site does not have dual WAN, DMZ and DHCP server on DMZ interface. But there also DHCP server is in LAN and OpenVPN is bridged.
Yet OS X clients do not have problem getting IP address. Crazy.Apparently something had gone wrong here, but I am unable to trace that.
Now that I have workaround - enable DHCP relay and disable DHCP on DMZ, I am able to move forward, but still this is just a workaround. I don't want to put DHCP on another server in DMZ, but what to do? -
I'd just point out that enabling the relay does not create the required firewall rules.
https://redmine.pfsense.org/issues/4558
-
Which gets me even more confused ???
-
yeah I just found that dhcp relay does not auto add firewall rules awhile back.. Dok is quick on knowing the issues list, I need to follow that more ;)
If you do a relay you have to make sure you have the right firewall rules in to allow it, when you enable dhcp the rules are auto created for you and hidden..
