I have a segregated network with pfSense at the head-end; and 3x AP6’s spread through the house (with a 4th one to service the back yard if I ever get my head out and run the cable). I just recently (like, within the last week) got my network hardware up to snuff enough to actually carry VLAN tags all the way to the clients, so I now have 5 networks based on the 192.168.2.0/23 “root” network. They are as follows:
Resident (2.4G + 5G) - 192.168.2.0/23; Unhindered
Guest (2.4G + 5G) - 192.168.10.0/24; Isolated: Internet and services on Resident net only
IoT (2.4G) - 192.168.50.0/24; Isolated: Internet only
Streaming (5G) - 192.168.12.0/24; Isolated: Internet only
Surveillance (2.4G) - 192.168.88.0/24; Isolated: Surveillance net only
FWIW, the IoT and Streaming networks have the same firewall rules; I just had to separate 2.4G and 5G because my smart plugs, etc. don’t like the 5G band but are stupid enough to try connecting to it anyway.
All the devices connected to each VLAN network are connecting to what they should, so no problem there. Here’s where it gets weird. A few devices on my “Streaming” network (Echo Dot, Fire Stick, etc.) are getting an IP address of 10.188.x.x instead of 192.168.12.x; and some of the IoT devices are getting 172.x.x.x instead of 192.168.50.x. If I browse to that IP’s logical gateway (eg: 10.188.0.1 for the streaming devices), I get a page like this and the host header identifies as Alta.
I thought maybe there was something wrong with my network, so I went in and made sure that the APs were not setup to hand out DHCP addresses. No avail. I thought “Well, it will connect to whateverflix, so I’m not gonna stress too much.”
Then I got to work and ran into the same exact issue with completely different VLAN tags on a completely different ISP.
SHENANIGANS!!!
Anyone else run into anything similar? Did you resolve it?
Sounds like the devices might be having an issue getting a DHCP address. What I have learned from the Alta team is the following:
The AP assigns 10.188.x. addresses to client devices if that client attempts to contact the DHCP server 3 times and doesn’t receive a response from the DHCP server in time. So the AP assigns one, and does a special internal NAT within the AP.
@nepeterson Yes, the 10.188.x subnet is the AP’s local subnet in case it detects that a DHCP server is not responding, and the AP steps in. You can grab tcpdumps to confirm that the DHCP server is not responding. We will be adding an option soon to disable this, but in most cases, it is better to provide connectivity rather than wait for a slow/non-responsive DHCP server. We’ll also have some fixes for VLANs coming in an updating firmware very soon, so please stay tuned.
I just had this same experience this afternoon messing around setting up a new pfsense box. I had forgotten to turn on the interface so dhcp wasn’t responding and my laptop kept getting a 10.188 address and for the life of me I could not figure out why. Nice feature but when you’re not expecting that behavior it can send you down some rabbit holes!
We might add some warnings that this feature has been applied to make it more intuitive to the user what happened with the “random” IP address. And we’ll document this feature better in the knowledge base
Update: Turns out I’m a doofus and completely missed a switching device (admittedly; a SOHO router in AP-only mode with the radios turned off) which is incapable of VLAN tagging.
So, the devices were not, in fact, getting the DHCP assignments they were asking for.
Feature request? Maybe a toggle switch that says something along the lines of: I'm an installer (read: "Professional Hobbyist") and I'm trying to troubleshoot VLAN deployments; especially in Frankenstein, hacked-together networks. Please disable the internal 10.188.X.X DHCP server, because it's really cramping my style!
