cancel
Showing results for 
Search instead for 
Did you mean: 
Replies are disabled for this topic. Start a new one or visit our Help Center.

No support for AP mode with mesh

Polarjoe42
Community Member

I realized it when setting up a firewall on my network that Google Wifi does not support AP mode with mesh/satellites. Why is this and is there plans to fix this? Most major mesh network systems will support this feature.

1 Recommended Answer

MichaelP
Diamond Product Expert
Diamond Product Expert

Oof. Ok, I took a quick look at that "workaround" and I'm not a fan, to be honest. First, using a managed switch outside the Google/Nest WiFi network may be ok, but using one on the inside of the Google/Nest WiFi network (i.e., connected in the Google/Nest WiFi LAN Ethernet port) is very likely to cause problems with spanning tree / loop detection. You may be able to avoid that by disabling loop detection on the managed switch, but I prefer using simple, inexpensive, unmanaged switches on the inner network. It looks like they're trying to avoid deploying a managed switch externally as well as an unmanaged switch internally, but the result is just a lot more complexity in the configuration. I would try to keep things as simple as possible and decide what your goals are for having two firewalls in your network. I can try to advise on how achievable those goals may or may not be.

I will say this, having your WiFi devices behind the Google/Nest WiFi firewall while your wired devices are on an outer network will have implications you may not be willing to accept. It puts significant constraints on how those devices can talk to each other (e.g., a wired streaming TV won't be discoverable by a WiFi phone or tablet). Also, since the Google/Nest WiFi firewall is doing NAT, all of the WiFi devices will appear to the outer firewall as a single device.

I hope some of this helps!

View Recommended Answer in original post

7 REPLIES 7

MichaelP
Diamond Product Expert
Diamond Product Expert

Hello @Polarjoe42 

I can't give an authoritative answer, but based on thirty+ years as a computer engineer, I can provide relatively informed speculation. When the system is supporting mesh secondaries, it runs the spanning tree protocol with the primary node (which is also the firewall / router) configured to be the highest priority bridge in the spanning tree. This is important in order to support wired backhaul (where one or more mesh / secondary units are also connected back to the primary via an Ethernet network). Having the primary be the highest priority bridge means it can keep both the mesh and Ethernet interfaces enabled, whereas any of the wired secondaries will disable forwarding through their mesh interfaces to avoid the traffic loop that would otherwise occur. STP takes care of making that happen on the secondaries by having the mesh interfaces configured with a lower priority than the Ethernet interfaces.

Now, imagine we put the primary in bridge mode. Now, it's bridging both of its Ethernet interfaces along with the mesh and client-facing WiFi interfaces. So, STP is now managing that WAN Ethernet interface as well. This could all work ok, as long as the outer network it's connected to does not also run STP with any bridges configured with a higher or equal priority. But, that's not something Google WiFi can control for, and if it ends up not being the case, then things will break – badly (this already happens sometimes when someone uses wired backhaul on a Google WiFi system with a managed Ethernet switch that has STP / loop detection enabled).

Imagine this scenario: you want to deploy two Google WiFi primary units in bridge mode, each managing their own mesh secondaries. They both want to be the highest priority bridge in the spanning tree. Only one of them "wins", and you end up with a lot of extra traffic between the two.

I don't know how other systems have solved this. I just know a bit about how Google/Nest WiFi work, and this is the biggest issue I see with making this change. There may be others I am not aware of, though.

I have been a developer for 20+ years and thnk that I am pretty tech savvy but I am not savvy when it comes to infrastructure/firewalls... however I am learning fast. This is VERY helpful and thanks for taking the time to respond. This is the workaround the company suggests. https://help.firewalla.com/hc/en-us/articles/4416280723859-Google-Wifi-or-Nest-Wifi-Mesh-network-wit...

With your experience, is this a viable option or just a workaround? 

MichaelP
Diamond Product Expert
Diamond Product Expert

Oof. Ok, I took a quick look at that "workaround" and I'm not a fan, to be honest. First, using a managed switch outside the Google/Nest WiFi network may be ok, but using one on the inside of the Google/Nest WiFi network (i.e., connected in the Google/Nest WiFi LAN Ethernet port) is very likely to cause problems with spanning tree / loop detection. You may be able to avoid that by disabling loop detection on the managed switch, but I prefer using simple, inexpensive, unmanaged switches on the inner network. It looks like they're trying to avoid deploying a managed switch externally as well as an unmanaged switch internally, but the result is just a lot more complexity in the configuration. I would try to keep things as simple as possible and decide what your goals are for having two firewalls in your network. I can try to advise on how achievable those goals may or may not be.

I will say this, having your WiFi devices behind the Google/Nest WiFi firewall while your wired devices are on an outer network will have implications you may not be willing to accept. It puts significant constraints on how those devices can talk to each other (e.g., a wired streaming TV won't be discoverable by a WiFi phone or tablet). Also, since the Google/Nest WiFi firewall is doing NAT, all of the WiFi devices will appear to the outer firewall as a single device.

I hope some of this helps!

Jeff
Community Specialist
Community Specialist

Hi, Polarjoe42.

I just wanted to check in and see if MichaelP's last reply was what you were looking for or if you needed more info and help here. If you're still looking for some input, just let us know.

Thanks.

Jeff
Community Specialist
Community Specialist

Hi again, Polarjoe42.

I'm checking in once more to see if you were still needing some help on this. If so, just let us know.

Thanks.

Polarjoe42
Community Member

Sorry, been on vacation. Nope, I am all set and thank you for all the export advice.

Jeff
Community Specialist
Community Specialist

Thanks, Polarjoe42.

I'll go ahead and close up the thread, but if you need anything else going forward, please feel free to open up a new discussion.

Thanks.