Clients unable to acquire IP Address via DHCP on VLANS
T-10
Fireware 12.4.B592447
No Log Server or Dimensions running at this site.
Clients unable to acquire IP Address via DHCP on VLANS
I have a small office where everyone connects wirelessly.
There are three networks:
VLAN-1 (default) is the secure network running DHCP 10.0.1.0/24
VLAN-10 RING security cameras running DHCP 192.168.1.1/24 (All RING devices have DCHP Reservations and are able to connect)
VLAN-20 Guest WiFi access running DHCP 172.16.10.1/24
Users connecting to the secure network aquire an IP address fine and are able to access the network.
Users connecting to the RING or Guest networks are unable to obtain an IP address from that VLAN network and end up with an IP address from the secure network. 10.0.1.0/24, but since they are on a separate VLAN from the secure network they have no Internet or network access.
I have set up many offices with this type of configuration using the same brands of equipment (Aruba & Watchguard), with never an issue.
For testing I have created other Wireless networks on other VLAN’s, configured the switch to tag and pass the VLAN, configured the Firebox for the VLAN w/DHCP, IP Address, Policies etc…… and still the same issue.
Traffic Log for DHCP handshake
2019-08-23 07:46:47 dhcpd DHCPDISCOVER from c8:bc:c8:e1:57:f7 (Da-Macs-MBP) via vlan10 msg_id="1600-0066" Event
2019-08-23 07:46:47 dhcpd DHCPOFFER on 192.168.1.13 to c8:bc:c8:e1:57:f7 (Da-Macs-MBP) via vlan10 msg_id="1600-0065" Event
2019-08-23 07:46:47 dhcpd DHCPREQUEST for 10.0.1.10 (10.0.1.1) from c8:bc:c8:e1:57:f7 via eth1 msg_id="1600-0066" Event
2019-08-23 07:46:47 dhcpd DHCPACK on 10.0.1.10 to c8:bc:c8:e1:57:f7 (Da-Macs-MBP) via eth1 msg_id="1600-0065" Event
2019-08-23 07:46:47 dhcpd DHCPREQUEST for 10.0.1.10 (10.0.1.1) from c8:bc:c8:e1:57:f7 (Da-Macs-MBP) via vlan10: wrong network. msg_id="1600-0066" Event
One other event that may play a part is this:
2019-08-23 07:54:49 resourced RAM alert level red msg_id="0000-005C" Event
2019-08-23 07:55:49 resourced RAM alert level yellow msg_id="0000-005C" Event
Could I be out of RAM and consequently not be able to serve the DHCP requests?
Things that make me go Hmmmm…..
- Doug
It's usually something simple.
Comments
c8:bc:c8:e1:57:f7 is asking for 10.0.1.10 via the DHCPREQUEST.
You need to find out why.
It looks like a client thing to me.
Was the ring camera initially set up on VLAN1 ?
Or is it getting info from some other Ring device/manager ?
Consider contacting Ring support.
Also, post similar DHCP logs for the guest or test VLAN showing an issue.
Yeah Bruce, I saw that and thought it a bit odd. Like the client isn't letting go of the IP, but this happens with all clients, PC's, tablets, phones, Apple computers.....
Also it happens on both VLAN's 10 & 20. I just posted from vlan 10 as they all show the same thing.
This is how it should look. Capture from a different office.
2019-08-23 13:46:42 dhcpd DHCPREQUEST for 192.168.75.121 from 00:56:cd:06:ab:ee (iPhone) via vlan20 msg_id="1600-0066" Event
2019-08-23 13:46:42 dhcpd DHCPACK on 192.168.75.121 to 00:56:cd:06:ab:ee (iPhone) via vlan20 msg_id="1600-0065" Event
2019-08-23 13:46:44 dhcpd DHCPREQUEST for 192.168.75.196 from 40:cb:c0:02:98:fa (iPhone) via vlan20 msg_id="1600-0066" Event
2019-08-23 13:46:44 dhcpd DHCPACK on 192.168.75.196 to 40:cb:c0:02:98:fa (iPhone) via vlan20 msg_id="1600-0065" Event
It's usually something simple.
The only other thing that I can think of is that the DHCP reply packets are not making it back to the clients on those VLANs and/or that there is a DHCP server someplace for the VLAN1 range which serves 10.0.1.0/24 IP addrs to those other VLANs.
Sorry for the delayed posting.
Made a trip to the remote office and ran a TCP Dump on the FW while trying to connect to either network on the VLANs.
Running the pcap through WireShark I found that the client is sending out the Discover broadcast, but both the default Secure VLAN, and the Ring or Guest VLANs (depending on which SSID I'm connecting to) are responding back with an Offer from the FW. When the client broadcasts the Request back for an IP, it is the default Secure VLAN that comes back with an IP.
Consequently, since the client now has an IP from the wrong network, the FW responds with a NAK telling the client to pound sand since they are on the wrong network.
Normally after receivng a NAK, the DHCP handshake process would start over, but since the client has an IP address it doesn't initiate the process.
Now that I know what is happening, why does the default secure VLAN always respond to the DHCP Discover & Request broadcasts on both the other VLANs?
If I try the Ring network, the Guest WifFi doesn't respond, and vice versa. But the secure network always responds to both.
I've gone over the settings, compared them to other offices that work and I can't see what I've done wrong.
Ideas?
It's usually something simple.
Almost seems like the DHCP broadcasts can get to VLAN1.
Any settings on your VLAN switch that could cause this ?
Otherwise, time for a support incident.
And it is always helpful to have some sort of remote access ability to manage the other site.
Many ways to do this - the best IMHO
1) client VPN with permissions for WebUI and/or WSM access, and switch & access points
2) authenticate to the firewall with permissions for WebUI and/or WSM access, and switch & access points
Finally resolved the issue. Onsite I have a Synology NAS running as a file server, and I just used the DHCP Server module of the NAS software to assign IP's to the different VLANs on the network. The Secure, Guest, and RING networks all connect with no issues now.
This is of course after removing the DHCP Sever Service from the Interfaces and VLAN's on the Firebox.
One odd thing I noticed whenever a client tried to connect to any network other than Secure was they ALWAYS received the IP address of 10.0.1.73 from the Secure network DHCP Scope. Didn't matter which client or optional network was being used, that IP always came up.
Go Figure.
It's usually something simple.