Wrong Subnet being picked up by wireless devices

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ASKER

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 192.168.0.0 network. But the odd thing is it's not just the Nest devices - multiple laptops were picking up a 192.168.0.0 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.

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.

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.

ASKER

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, 192.168.1.50-192.168.1.60 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 192.168.1.0 subnet and trying to join the 192.168.0.0 subnet. I wonder if there is something on the firewall that I can force anything trying to pick up a 192.168.0.0 address and force it to use a 192.168.1.0 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.

footech

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.

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.

LAN
IP: 192.168.50.1
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0

WLAN
IP: 172.16.32.1
Subnet Mask: 255.255.255.0

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

Let me know. Thanks!

ASKER

The Sonicwall only has two interfaces:

X0 - Lan:
IP: 192.168.1.10
Subnet Mask: 255.255.255.0
Gateway: 0.0.0.0

X1: Wan
IP: (External Gateway - Hidden for security)
Subnet: 255.255.255.0
Default Gateway (Hidden for security)
DNS Servers: 8.8.8.8/8.8.4.4

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

Unifi Network Subnet: 192.168.1.1
Default Gateway: 192.168.1.10

Should be pulling DHCP from the Server

DHCP on the Firewall: Dynamic Range 192.168.1.150-192.168.1.249. 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.

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 192.168.0.1) 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.

You never addressed the ipconfig /all | find "DHCP Server" and searching for another DHCP server in my previous comment: https:#a42459948.

@CompProbSolv,

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.

@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.

footech

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.

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 24.92.226.11, 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.

ASKER

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

ASKER

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?

ASKER

All,

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!

ASKER

Masnrock - the network is currently four Unifi AP-AC-Pro running on version 3.9.19.8123 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.

ASKER

All,

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 192.168.0.0 subnet has disappeared. My X0 Lan interface is configured as a static IP at 192.168.1.10. 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 8.8.8.8.

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 192.168.0.0 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?

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 4.2.2.2 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 McCarn

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.

ASKER

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.