DHCP not working on OPT1
-
I'm attempting to setup a public WiFi using AP on OPT1 interface. My WAN and LAN are functioning normally. I assigned a 3rd NIC to OPT1. Properly setup Rules to allow traffic just like LAN. Outbound NAT is automatic and lists the OPT1 subnet like it should. DCHP server is enabled with a proper pool of address per the subnet.
I can connect to the AP but not get an IP from DHCP. If I manually assign IP and DNS I get access to the internet but DHCP will not issue an IP. Nothing in the DHCP log except the LAN IP's being issued.
I've now tried this both on location where I really want it to be setup as well as on my home box to test, same results. I've read post after post all with the same fixes, someone didnt have DHCP enabled, another used the wrong subnet, another didnt have rules correct etc. All this is right since I can get internet access if manually configured.
Thoughts?
-
You listed all the common reasons people end up in that circumstance with the exception of one - the DHCP requests never actually make it to the system. Packet capture on your OPT1 interface while you have a client trying to pull an IP via DHCP, and see if the requests are actually getting there.
-
How would I go about that please? And why wouldn't they get there? Same clients get DHCP off wireless connected to LAN. The original location I tried this before testing at home was a fresh setup, no packages. 1st thing I did was setup 3rd interface and attempt public WiFi.
My home setup I disabled pfblocker and uninstalled squid just to make sure. One thing the two setups have in common is the hardware is identical except for the SSD brand being used. OPT1 is on a realtek NIC but before adding in a dual port Intel NIC I was using both the onboard realtek and a discreet realtek card that worked fine.
Thanks for your time.
-
Sorry, should have looked first, packet capture is built in. Here are results on the opt1 interface while attempting to connect a client.
23:54:03.918068 90:b6:86:48:1b:17 > ff:ff:ff:ff:ff:ff Null Unnumbered, xid, Flags [Response], length 46: 01 00
23:54:05.063439 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 308
23:54:08.075834 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 308
23:54:16.549989 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 308
23:54:32.447639 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 308
23:54:36.455013 90:b6:86:48:1b:17 > ff:ff:ff:ff:ff:ff Null Unnumbered, xid, Flags [Response], length 46: 01 00
23:54:36.964441 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 308
23:54:41.100166 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 308
23:54:49.936890 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 308
23:55:06.272918 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 308I don't know how to interpret this. It looks like the client with no IP is requesting an IP broadcast to the whole network, but there is no repsonse.
-
That looks reasonable, seems like a normal DHCP request. Anything showing blocked in your firewall log? Enabling block bogons on OPT1 will block DHCP requests, and isn't something you want on an internal interface.
-
no nothing, I need to try again later and look at newest items in log but on the summary graph the only things that were blocked were from LAN and WAN. Not a single item recorded for OPT1. Bogon is not selected on either internal interface, only on the WAN.
-
Having nothing in the DHCP log suggests nothing is making it to the DHCP server. The packet capture shows it's making it to that box at least. Check Diag>States, filter for 255.255.255.255, and make sure you're seeing that UDP port 67 traffic there when there is a device making a DHCP request on OPT1. If it is, try restarting the DHCP Server service under Status>Services (though I can't think of any reason that'd be necessary), or reboot.