LB2120 - Bridge Mode Issues

[magellan2]

First some details about my setup and what I've learned so far about bridge mode on the LB2120. The next posts will describe some issues I'm having and ask for help.

I'm using an LB210 in bridge mode with the WAN port connected to my LAN and the LAN port connected to a single raspberry pi. I'm using bridge mode because it allows me to reach the raspberry pi from my local network without setting up port forwarding rules as long as the wireline broadband connection is active (eg LB2120 not failed-over to mobile).

Based on observation, the LB2120's bridge mode doesn't behave like bridge mode on other routers. It does allow the single device connected to the LB2120 LAN port to be reached from devices on its WAN port without port forwarding rules, which is nice, but traffic between the WAN and LAN ports isn't actually bridged in a manner consistent with the IEEE's 802.1D bridging standard.

To make my setup work, first I assigned a static IP to the LB2120 for management (say 192.168.1.200), put the device into bridge mode, connected the raspberry pi to the LAN port and my local network to the WAN port.   Next, I put a static DHCP entry into my main router with the mac address of the LB2120 and the IP address I want to assign to the raspberry pi (say 192.168.1.20).  I added a second static DHCP entry in my router to reserve 192.168.1.200, but this entry has a junk mac address.

With this setup, the network on the WAN side of the LB2120 never sees the mac address of the raspberry pi (eg the device connected to the LAN port of the LB2120), only the mac address of the LB2120. The LB2120 appears to replace the mac layer as it moves packets between the WAN port and the LAN port.

As best as I can tell, at some point the LB2120 sends a DHCP request out of the WAN side to get an IP address for the device on the LAN side.  I assume this request is made by the LB2120 in response to a DHCP request from the device on the LAN side.  But the key is that the DHCP request isn't just relayed from the LAN port to the WAN port.  Instead, the LB2120 seems to put its own mac address in the DHCP request before it sends it out on the WAN side.  (keep in mind that the management interface on the LB2120 already has a statically assigned IP).  When the LB2120 receives the DHCP response on the WAN side, it relays the IP it gets to the device on the LAN side. However, it doesn't just relay the DHCP reply it got from the WAN port. It seems to build a new DHCP reply to send out to the LAN port device. The DHCP info it sends to the LAN device has the netmask hardcoded to 255.255.255.0 regardless of the netmask in the original WAN side DHCP reply. Also, it seems that the DNS server IP is hardcoded to xxx.xxx.xxx.2 (eg 192.168.1.2 if the DHCP assigned WAN IP is 192.168.1.xx). So even in bridge mode, it looks like the LB2120 makes itself the DNS for the device connected on the LAN port. 

So as best as I can tell, this is how bridge mode works on the LB2120.  The path between the WAN port and the LAN port isn't strictly routed or firewalled, but the LB2120 replaces the layer 2 part of all packets as they move between the 2 bridged ports.

[magellan2]

Everything is working pretty well except that I can only access the raspberry pi's SMB shares by IP, not by name. Again, I understand that once the wireline broadband goes down and the LB2120 fails over, I won't be able to reach the raspberry pi at all from the local lan. Even though the LB210 is in bridge mode, when the failover occurs, it cuts off the WAN port completely and instead of passing through the IP from the ethernet WAN port it passes the newly received mobile IP to the raspberry pi. Still, it'd be great if I could get this to work.

It apepars that NetBios name registration broadcasts from the raspberry pi are getting blocked by the LB2120, even though it's in bridge mode.  

Anyone have any ideas about how to work around this?

Thanks.

[magellan2]

One other FYI about the LB2120's quirky bridge mode is that you can't manage the LB2120 from the WAN port, even in bridge mode.  As a workaround, I set up the raspberry pi that's connected to the LB2120's LAN port as a web proxy.

The kludgy way I did this was to create an SSH putty session to the raspberry pi that has tunnelling enabled.  Of course, for this to work the device connected on the LB2120's LAN port (eg my raspberry pi) must have SSH enabled. 

In the putty configuration window, set the IP to the device connected to the LAN port (192.168.1.20 in my case).  Next, still in putty, go to Connection->SSH->Tunnels and add a new forwarded port with Port set to 1234 and the "Dynamic" radio button pressed (leave destination blank). Click Add and then click the session category (on the left) and save the configuration.

Whenever you want to manage the LB2120, start an SSH session to the device connected to the LB2120's LAN port using the parameters you just saved and login to the device.  Next, go to your web browser and set up a manual proxy with the SOCKS host set to 127.0.0.1, the port set to 1234, and SOCKS version set to SOCKS v5.   

Now you can enter the IP address that you statically assigned to your LB2120 into your web browser to manage it (in my case, 192.168.1.200).  This only works while the SSH session is active and also remember to turn off the proxy once you're done managing the LB2120.

[bigdt93]

Your brief is excellent.  It was helpful to consult during my implementation.  I decided to leverage  the routed mode as a result. This allows for the dhcp function on the LB2120 to leveraged for my internal router during a failover scenario.

Additionally I configured my internal router as the dmz host on the LB2120, which allowed all PNAT & firewalls rules to work completely.

This allows the failover and failback functions to works without intervention.