Wrong Subnet being picked up by wireless devices

This is an addendum to an old ticket which can be seen here:


The problem described in the old ticket is still occurring. Random devices will pull a 192.168.0.X address. I put in a new Unifi network (With a new Sonicwall) but the exact same thing is happening. The DNS server changes as well. The DNS server on the firewall is listed as, which is exactly what devices that pick up the CORRECT 192.168.1.X subnet read. However, those that get the wrong 192.168.0.X subnet read the DNS server as, which is the old TW/Spectrum DNS. I have no idea how it's grabbing this.

This "wrong subnet" problem only appears to occur with the wireless devices, as no hardwired device has shown this error so far. That leads me to believe it's either a setting in the Unifi setup (For which I've kept all of the defaults) or the way the Unifi is talking to the Sonicwall. To combat this problem with laptops I've gone in and set static IP addresses from the PC side, which seems to have corrected the problem.  However, with the Nest devices, this isn't an option, as there is no way to manually enter network info.

Instead, I created a  static IP for the Nest devices on the firewall. If I reboot the devices they SOMETIMES pick up on the correct subnet, and when they do, it's the static IP I gave them in the firewall. However, after a few days of working properly they suddenly drop off and pick up the wrong subnet again.

There is clearly something going on here. Looking at the devices connected through the Unifi system I can see one Nest device currently picking up a Not only is this wrong, it's not even accurate, because if I run an Advanced IP scan I pick up about 6 or 7 more devices trying to work off of the 192.168.0.X subnet.

It's almost as if there is something else acting as a DHCP server. The DHCP server should be the firewall and nothing more. There is no Windows domain here. It's a Sonicwall, a Unifi Wireless network, and local computers.

Any suggestions would be greatly appreciated, as I am at a loss as to how these devices are getting this setup.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Fred MarshallPrincipalCommented:
A network diagram would help - with IP addresses.  Makes it easier to comprehend the situation and the question.
Blue Street TechLast KnightCommented:
Hi Tarkisal,

How are you assiging DHCP?

However, with the Nest devices, this isn't an option, as there is no way to manually enter network info. This can be done through the SonicWALL as a Static IP or through Windows Server via DHCP Reservations.

Nest devices default to the network.

What is the ipconfig /all | find "DHCP Server"of one of the laptops when it has the wrong address? That should show you the DHCP address/es the command found. It sounds like there is another DHCP server somewhere within your network. Make sure the ISP router is not a DHCP server. You need to try to hunt it down and disable it.

Let me know if you have any other questions!

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
TarkisalAuthor Commented:
Last Knights: I am assigning DHCP through the Sonicwall. I have provided a block of static IPs specifically for the Nest devices. Sometimes they pick up these addresses, other times they drop them and go back to a network. But the odd thing is it's not just the Nest devices - multiple laptops were picking up a address before I forced the static IP. In the case of the PCs I set the static IP on the PC side as setting the static IP from the firewall didn't seem to stick either, much like the Nest devices.

Fred - I am working on a Network map. I should have one for tomorrow.
SolarWinds® VoIP and Network Quality Manager(VNQM)

WAN and VoIP monitoring tools that can help with troubleshooting via an intuitive web interface. Review quality of service data, including jitter, latency, packet loss, and MOS. Troubleshoot call performance and correlate call issues with WAN performance for Cisco and Avaya calls

Blue Street TechLast KnightCommented:
Did you follow the Nest instructions on how to setup the device...your phone has to be on the same network they are communicating on.
Blue Street TechLast KnightCommented:
I have provided a block of static IPs specifically for the Nest devices.
You cannot do this from SonicWALL. You can provide a Static IP Address or a Dynamic "block" of IP Addresses but not both.

For laptops, are they Windows 10? If so, disable Random Hardware Addressing. If it is on it will make it impossible to statically assign because the MAC address continually changes.
TarkisalAuthor Commented:
Random Hardware Addressing is turned off. Perhaps "Block" wasn't the right word. What I meant was I had deemed a certain range of IP addresses I would use for the Nest devices. So, would be what I made the Nest addresses, just to keep things need.

My phone is on the same network as the Nest devices, but even it (Android phone) appears to be randomly losing the subnet and trying to join the subnet. I wonder if there is something on the firewall that I can force anything trying to pick up a address and force it to use a address instead? I still don't understand where it's pulling this address from even when I set it, by static IP using the MAC, on the Sonicwall.
Any Window clients should list the IP of the DHCP server they got their lease from by running ipconfig /all
So if you think machines could be picking up their IP from another DHCP, this is the way to check.
Blue Street TechLast KnightCommented:
This doesn't make sense. Let's start at the beginning.

What is the make/model of the SonicWALL?
Are there any device between the SonicWALL and your clients, e.g. routers, switches, etc.?

Please list how many networks you have in the SonicWALL and their configs? e.g.
Subnet Mask:

Subnet Mask:

And what are the DHCP settings within the SonicWALL as well?

Let me know. Thanks!
TarkisalAuthor Commented:
The Sonicwall only has two interfaces:

X0 - Lan:
Subnet Mask:

X1: Wan
IP: (External Gateway - Hidden for security)
Default Gateway (Hidden for security)
DNS Servers:

The wireless Unifi network is running directly through the Lan and not using a separate interface on the firewall.

Unifi  Network Subnet:
Default Gateway:

Should be pulling DHCP from the Server

DHCP on the Firewall: Dynamic Range The rest have been reserved for Static IPs.

Also, I'm noticing the wifi is VERY slow - speedtest shows a download speed of about .04 mbps to .80 mbps. Hardwired connections fair better. Upload speeds seem solid for both wifi and hardwired.

I'm sure you are looking for more information but the office is closing and that's all I can get for now. I can get back in tonight or tomorrow morning.
Blue Street TechLast KnightCommented:
Thanks...what is the SonicWALL make/model.

Make sure the SonicOS is updated to the latest General Release.

Is the Gateway correct on the DHCP server? and what is the DHCP server's DNS set to?

Also, have you enabled Enable Conflict Detection & Enable DHCP Server Persistence on the SonicWALL?
The DHCP Server Persistence Monitoring Interval: should be set to 5 minutes.
I think footech has asked an excellent question: what is the IP address of the DHCP server being used when you get a 192.168.0.x address?  You indicated "It's almost as if there is something else acting as a DHCP server"; I think that's exactly what is happening.  You have another DHCP server which is on the 192.168.0.x subnet and devices occasionally get issues IP addresses by it.

" when I set it, by static IP using the MAC": that isn't really a static IP address.  I call it "quasi-static".  It's configuring the DHCP server in the firewall to give out the same IP address to devices with that MAC address, but this assumes that the firewall is the DHCP server giving out the address.  As mentioned, I suspect you have a second DHCP server.

I'm not familiar with the NEST devices, but is there a chance that one is acting as a DHCP server on 192.168.0.x?  That would explain a lot.

I'd disconnect ALL Nest devices from power and then reboot (or do ipconfig /release && ipconfig /renew) on laptops and see if they ever get a 192.168.0.x address.  Alternatively, wait until you have one of the laptops on 192.168.0.x and note the default gateway (use ipconfig /all).  Ping the default gateway continuously (e.g. ping -t and confirm that you are getting responses.  One-by-one disconnect the Nest devices.  If one is at that address, you'll know as the ping responses will be error messages.  That device is your rogue DHCP server.
Blue Street TechLast KnightCommented:
You never addressed the ipconfig /all | find "DHCP Server" and searching for another DHCP server in my previous comment: https:#a42459948.

I'm not familiar with the NEST devices, but is there a chance that one is acting as a DHCP server on 192.168.0.x?  That would explain a lot.
Nest are simple IoT nework devices - they do not have capabilities for anything except receiving an IP address via DHCP or DHCP Reservations (MAC based assignment).

We have 16 Nest devices in our network - I know them well and they don't cause this type of behavior whatsoever.
This expert suggested creating a Gigs project.
@Blue Street Tech:

I missed your comment about ipconfig /all that preceded footech's.  I think we're pushing for the same thing here: identify the IP address of the rogue DHCP server and then physically identify it.  I don't think this is nearly as complicated or confusing as it may appear.

Thanks for the input on the Nest devices.  With what you've described, they shouldn't be an issue here.

I'm most suspicious of an otherwise unknown WiFi access point/router having been connected.
I also missed Blue Street Tech's mention of previous suggestion of checking for the DHCP server (I'll blame it on reading the question on my phone).  Sorry for the duplicate.
Blue Street TechLast KnightCommented:
Double check that your Modem/Router is in Bridge Mode aka Transparent Mode or otherwise disable its DHCP server. If it is not disabled it is most likely the source of your additional DHCP server and you can put it into Bridge Mode remedy as well as remove the double NAT going on as well. Nothing else should be plugged into the modem/router either...only the SonicWALL. Don't ever use a modem/bridge to disseminate traffic...its job is to only translate/hand-off. Use Core and Access layer switches to disseminate traffic. In small networks simple Access layer switches will suffice.

Let me know if you have any other questions!
I'm wondering exactly how the entire network is set up. It sounds like all sorts of things are configured in a strange manner. Could you please show us the configurations for the Sonicwall LAN interface involved, the DHCP settings, and the UniFi device? Show a diagram as well please showing exactly how things are set up now, and explaining the cables. One of the first things to confirm is that the cable coming from the Spectrum modem is going to the WAN port (X1) on the Sonicwall. I am also assuming that both wireless and DHCP on the Spectrum device are turned off. This should be the only cable coming from the Arris.

However, those that get the wrong 192.168.0.X subnet read the DNS server as, which is the old TW/Spectrum DNS.
I would guess 2 things: 1) Check the DNS settings on your WAN interface on the Sonicwall. 2) Check the DHCP for the 192.168.0.X subnet (assuming that you have such a subnet on your network), and see what servers are set for DNS on it.
@mansrock: unless I'm misreading this (quite possible with the lack of detail provided) there isn't supposed to be a 192.168.0.x subnet at all.  That some devices are getting those addresses is the core of the problem.  The DNS issue is secondary.
@CompProbSolv - I looked at Tarkisal's other question (the one that this was an addendum to). Drawing from that, the 192.168.0.x subnet comes from the Spectrum device. But you are correct from the standpoint that it isn't supposed to exist behind the Sonicwall.
@mansrock: you are correct; I hadn't looked at the old thread.

It appears that good answers were given there as here: find the 192.168.0.x DHCP server and disable it (or put the device in bridge mode).

It's odd that the Spectrum would issue DHCP addresses that bridge through the Sonicwall, but that could easily be explained if we know how the devices are physically connected and how the Sonicwall does routing.

Putting the Spectrum in bridge mode could make this SO much easier!
Given that the Sonicwall does NAT to begin with, I would certainly bet that things are wired incorrectly to begin with. If everything the wireless devices connect to is behind the Sonicwall, there's no way that things 192.168.0.x DHCP requests should pass through.
TarkisalAuthor Commented:
I want to thank everyone with their continued support with this topic. I had to cut my day short yesterday due to nasty weather, and I don't plan on going to the site until tomorrow. However, I was planning on calling Spectrum this morning to see if there is anything that needs to be changed from the cable modem. The cable modem feeds directly to the firewall and then the wireless router (Mesh Unifi access points) work directly off the X0 Lan interface.

I will work on a Network map today to aid in visualizing the setup. I'm also wondering why it only appears to happen with wireless devices. That makes me think it's a setting in the Unifi control page. DHCP is listed as "Auto" here, so I'm guessing the Unifi is seeing both networks (Somehow the Firewall is allowing that other network through?) and if there is something on the Spectrum equipment that can be turned off I would think the Unifi devices would automatically find the other, correct, DHCP server. I will update everyone with my findings.

Thanks again
TarkisalAuthor Commented:
One more thing people keep asking and I keep forgetting to add - the firewall is a SonicWALL NSA 2650. Brand new.
Exactly which UniFi device(s) do you have?
TarkisalAuthor Commented:

I am beyond pleased to announce that the problem did appear to be a configuration error on Spectrum's equipment. After speaking with the tech support they found the device was setup for DHCP. He wasn't sure why it was doing this but he was able to turn it off. As soon as this was done the wrong 192.168.0 network disappeared and all of my devices switched to the correct network. I believe it was as someone said several days ago - the other DHCP server was fighting with the firewall to provide addresses.

I think everything should be on the up and up. Without protest, however, I am going to leave this ticket up until tomorrow, when I can investigate the site in person. Assuming all is well I will then close the ticket.

Again, thank you for the excellent support from everyone here on Experts Exchange!
TarkisalAuthor Commented:
Masnrock - the network is currently four Unifi AP-AC-Pro running on version and controlled through the Unifi dashboard.
And I saw that you have it connected to port X0. How is that interface on the Sonicwall configured? I especially would like to see the DHCP server's DNS settings for that interface. Also, how do you have the UniFi configured? I'm assuming you have DHCP and those other things turned off.

Do you have VLANs, and are you using an injector or a POE switch to power the access point?
You've identified the 192.168.0.x DHCP server as being on the Spectrum device, but not how DHCP requests passed through the Sonicwall.  As others have suggested, the Sonicwall should be configured to not allow such requests to go through.

Secondly, what is the outside (WAN) interface IP address on the Sonicwall? If it is on the 192.168.0.x subnet as it appears to be, then this reinforces previous comments about changing the Spectrum device to bridge mode.  While it is workable, having two NAT routers in line (as you may have here) can be a nuisance to administer.
TarkisalAuthor Commented:

I am currently on site, and I will try to respond to remaining questions.

Turning off the DHCP server on the Spectrum device immediately fixed my problem. The subnet has disappeared. My X0 Lan interface is configured as a static IP at My WAN interface on X1 is also Static, picking up the first of 5 "usable" addresses provided by Spectrum (Not an internal address) and the gateway is the gateway provided by Spectrum. The DNS server, however, is

The Unifi DHCP has been turned off. No Vlans are enabled. There are currently four Unifi access points and some are connected directly through POE and some require an injector, depending on their location and the wiring.

I don't think the Sonicwall is allowing any unnecessary traffic through in regards to DHCP, except for the direct connection through the Spectrum box. Now that DHCP has been set to off on the Spectrum device, all seems well.

If there is any other concern regarding this setup, or any questions I have answered please let me know. If not, I think we can close this ticket with my thanks.
Turning off the DHCP server on the Spectrum device immediately fixed my problem. The subnet has disappeared.
But this doesn't explain how the the DHCP requests are getting past the Sonicwall.

I don't think the Sonicwall is allowing any unnecessary traffic through in regards to DHCP, except for the direct connection through the Spectrum box. Now that DHCP has been set to off on the Spectrum device, all seems well.
The Sonicwall has to be allowing some requests through, or something just isn't wired correctly.

The Unifi DHCP has been turned off. No Vlans are enabled. There are currently four Unifi access points and some are connected directly through POE and some require an injector, depending on their location and the wiring.
How is the POE switch wired? Obviously, there are the cables going to the APs, but what about any other cables?
Blue Street TechLast KnightCommented:
I didn't read that you have put the Spectrum device into Bridge Mode. The security functions, firewall and NAT should be disabled in your Spectrum device as well...Bridge Mode should do all of this for you.

Can you confirm that no other cables are plugged into the Spectrum device's swithports other than one (1) which is plugged into the X1 Interface of the SonicWALL?

Also, verify the IP Assignment of the WAN (X1) and LAN (X0) in the SonicWALL under Network > Interfaces. As @masnrock has pointed out there has to be something allowing DHCP to take place.
What make/model is the device you got from Spectrum? If I recall properly, there's at least a subset that cannot be thrown into bridge mode, much less have NAT turned off. The ideal solution to that would be if they provide you with a modem, not a router.

Still would also like to see the diagram.

I'm really strongly betting on something being wired incorrectly, because from what I read in your other post, it sounds like you were having the same issue before getting the Sonicwall. So one thought I have is that you might have a cable going from the Spectrum router to the POE switch. And if that is the case, get rid of that cable right away.
You are getting very good advice here and are generally going in the right direction.

The statement about the X1 port using a public address from Spectrum indicates that the Spectrum may not have to be in bridge mode (though that would simplify matters) to make this work properly.  I would try to confirm that the default gateway really does reside at Spectrum and not at your location.  I'd confirm as follows:

Go to some other location than yours.
Ping your default gateway and confirm that you get responses.
Disconnect your Spectrum box from the external connection.
Ping the default gateway (from a remote location) again.  You shouldn't get responses.

A less direct approach (though much more convenient) is to do a tracert command.  If you see very short (typically <1 ms) times for all hops until you get to the default gateway and the hop to the gateway is longer (5-20ms) then you've got a good indication that the gateway is external to your location.

This doesn't address the question about why the SonicWall is allowing DHCP requests through.  As others have mentioned, this is either a situation where the cabling is different than described or the SonicWall rules are not as expected.
Davis McCarnOwnerCommented:
Hey guys; for several years, Time Warner/Spectrum installed modem/router devices that included WiFi and I'll bet that numerous PCs and the Nest devices are connecting to it rather than the Sonicwall which explains everything.  Check the NAME of the WiFi that the 192.168.0.xxx devices are connecting to and I'll bet you'll find the root of the problem.
If I'm right, just go to the WiFi section of the PCs and/or devices and have them forget that WiFi.
TarkisalAuthor Commented:
I am giving this comment the points as it ultimately lead me down the right path to solving the problem. The issue was 100% due to the cable modem having DHCP turned on. The Spectrum rep said sometimes they turn it on assuming the customer will also have wifi, which this person did not. They just had an Arris cable mode that connected directly to my firewall. The Firewall was receiving the DHCP settings from itself and from the modem. To clear - it was just a modem from Spectrum, not a router. All of my wifi routers are underneath the firewall. As to why the wireless was picking up DHCP settings from the modem instead of the wifi - I believe it was because the firewall was allowing the settings from the modem as it was directly connected. This should no longer be an issue. I want to thank everyone for their long hours of help and dedication in solving this problem.
If the Spectrum had the ability to do DHCP, it was more than just a modem.  It's still not clear how DHCP worked through the firewall to the Spectrum, but disabling DHCP in the Spectrum should be a reasonable solution.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Wireless Networking

From novice to tech pro — start learning today.