NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
LB1120 Bridge Mode - No Connectivity
Hello, Trying out an LB1120 before installing across three locations as failover devices. Using AT&T and testing behind a consumer Linksys E2500 with default settings. The LB1120 works fine using...
A new firmware has been posted on the update servers that fixes the LB bridge mode issue. To update LB1120, LB1121 or LB2120 to latest Firmware log into the LB web ui and go to Settings àGeneral à Software and Reset once there select check for update and wait then simply follow onscreen instructions to update the Firmware. See below for example of how the LB2120 Firmware Info screen looks like after update. For other device just need to make sure that you are using App Version: NTG9X07C_12.09.05.27
I also purchased the NETGEAR LB1120. I've had the same experience as everyone else: when using a laptop, DHCP in bridge mode works fine; when I connect the device to my pfSense router, it does not function. As many have suggested, it appears that the problem is with the DHCP passthrough such that the interface in pfSense gets a netmask of 255.255.255.255. The other values appear fine.
I struggled a bit trying to get pfSense to override the DHCP configuration and use 255.255.255.0 instead. There might be a way to do this, but I didn't find it. So, I changed the interface configuration to static IPv4 and created a standalone gateway object. I pasted the issued IP and gateway values, and it started working properly. I was able to switch from my existing WAN's gateway as default to the one using the LB1120. I got transfer speeds that are acceptable for a failover solution.
So, it seems that we're all waiting on a fix from NETGEAR for the DHCP bug. For what it's worth, mine shipped with firmware version M18Q2_v12.09.163431.
Here are some details that are unrelated to the problem that might be interesting nevertheless. I'm using a SIM provided by Ting and it uses the T-Mobile carrier in my area. On first powering up the LB1120, it did a scan of the mobile networks and (I assume) created a default APN for the T-Mobile network that it discovered as compatible. I had to delete that and create a new APN for Ting using the string "wholesale" as specified in Ting's documentation for non-phone devices. Until I deleted the automatically created (again, my assumption) APN, the LB1120 would get confused about which one to use. It seems to work fine now from a cold start every time.
Something else worth mentioning (in case somebody else has the expectation I did) is that on the T-Mobile network my LB1120 is assigned something like 21.228.0.149. That is not in an allocation of IPv4 given to T-Mobile, and it's not accessible from the public internet. I had hoped that my WAN failover solution using a 4G LTE modem would allow me to connect to my office network during a primary WAN failure using a VPN client. It doesn't look like that's an option. Inside T-Mobile's network, my traffic emerges onto the public internet using an address from 172.32.0.0/11 (which they are the allocation recipient). I assume they're doing big iron NATing for all their wireless customers.
Lastly, another tip. When troubleshooting what was going wrong, I found it helpful to put a dumb Ethernet hub between my pfSense router and the LB1120. Using that, I could tap into the frames with another host and see what was going on. Using an Ethernet switch with the port mirroring feature would also have worked, but I didn't have one on hand. When sniffing, it was apparent that packets weren't ever actually leaving the pfSense box.