Firewalla Gold Tutorial: Use your router with Firewalla Gold (in Router Mode)

Follow

Comments

3 comments

  • Avatar
    Chris 'Zeke' Greenwald

    Currently (August 2020) the Ubiquiti USG 3P has no 'bridge mode' functionality exposed through the Unifi UI (I own one and could not find any such UI element). The Amplifi Alien does support this (based on link in the article) but the Dream Machine & Dream Machine Pro seem not to support this mode from the UI either. I do not own the Alien, DM, or DM Pro.

    https://community.ui.com/questions/Ubiquiti-Dream-Machine-Pro-bridge-mode/5dc395d5-6d61-463c-9591-42242ef3dbef

    0
    Comment actions Permalink
  • Avatar
    Rolando Nispiros

    In addition, these are the steps that worked for me from Firewalla Support.

    Here is the recommended sequence:

    1. Switch Gold from Experimental simple mode to Router mode
    2. Reboot the Modem (I have an Xfinity modem)
    3. Connect Gold's Port 4 to the Modem's LAN Port. 
    4. Connect your Router's WAN Port to the Gold's any other port (1, 2, or 3). (I have a Linksys MR9600  WiFi router)
    5. Switch Router to Bridge mode and Save. 

    At first I could not get an internet connection.  After trial and error I went to the Network setting in the Firewalla app, clicked on Edit, chose the WAN configuration, and changed the Connection Type from Static to DHCP. As soon as I did this, then devices in my network started to pick up new IP address that are preconfigured in the LAN network configuration.

    0
    Comment actions Permalink
  • Avatar
    Hans Tobeason

    If anyone's interested in the long explanation for why eeros need to be configured as indicated above, here it is, from the horse's mouth:

    I designed it. It's not supposed to be used that way, and the results will be unpredictable.

    eero is a software-defined network based on a heterogeneous backplane constructed from 802.11 and 802.3 links. Given this, we are trying to build a switch with every ethernet port and every wireless access point vdev as member ports.

    The problem with this is that in any given network where two eeros are connected by a piece of ethernet cable, they're also connected by the mesh. As I say, each radio on each eero has a virtual device which we call an AP- it's the thing a wireless client connects to. we call those "ports", just like the ethernet ports on an eero.

    The problem is that frames coming into those ports have to be delivered to their destinations in a locally consistent way, or non-mesh devices will become very confused.

    Frames have to arrive in the same order they were sent, they all have to transit any piece of ethernet in the topology in the same direction every time, and if there is an ethernet path, even if for only part of the topology, we want to use it, because ethernet doesn't consume airtime. The mesh does not guarantee deterministic delivery of frames, but ethernet absolutely requires it.

    This is extra specially complicated because while our mesh frames have six addresses and a time-to-live counter and can be trusted not to go in circles, ethernet frames only have two addresses- a source and a destination. Wireless AP frames from non-mesh clients only have three, one of which is just the network address and isn't useful.

    So if an eero sees an ethernet frame, it needs to know whether it should inject it into the mesh or not, but the information it needs isn't present in the frame. Each ethernet segment needs to see each frame once and only once, and it needs to approach that segment from the same port onto that segment, or switches will mislearn the location of those clients.

    We have an algorithm we invented called STAMP which solves this problem by building a table of segments and their intersections, and modifying the forwarding rules at each intersection to give every client a locally consistent view of the network that looks just like ethernet.

    Unfortunately, if two eeros are both connected to an upstream router of some kind... STAMP can't work properly. The two eeros might both be responsible for injecting frames into their segments, or neither of them might be. The upstream device might choose to deliver the frame on one port, or neither. It doesn't support STAMP, so it can't participate in the STAMP algorithm, and delivery vectors will be formally unpredictable.

    They have no way to figure this out unless there's an eero at the root of the topology.

    So yes, you shouldn't do this. It might work, it might stop working. It'll be random and flakey. When you reboot some part of your network, it may stop working, or some clients may randomly stop being able to see other clients. It'll depend entirely on the arrival order of frames when the switch inside your router learns things. Oh, and if your router supports STP, it'll probably eventually disable one of the ports.

    0
    Comment actions Permalink

Please sign in to leave a comment.