Question

I'm trying to set up a RUTX09 and a Ubiquiti USG in a simple use case where the RUTX09 provides internet access over LTE, SIM 1 only, to the USG router (RUTX09 LAN1 port to USG WAN port). I'd like to have access to the RUTX09 gui, from the USG LAN, and also to allow the RUTX09 to make new connections to that LAN (for MQTT modem status purposes).

I have set up the "Mobile" "Protocol" and "Passthrough" "Mode" on the MOB1S1A1 interface, and set up the USG MAC address and with "Auto APN" set to "on".

In the RUTX09 LAN interface, I have set up a static IP address and mask (192.168.5.1/24), with gateway, broadcast and DNS servers left blank.

Currently, in the USG, I have set up a static route to send 192.168.5.0/24 to the WAN interface. (This doesn't feel like the right approach here as there's no return path). The USG WAN port is configured for DHCP.

So that's how I've currently set it up. It mostly works. Internet access is ok from the USG LAN. I can access the RUTX09 gui from the USG LAN using http://192.168.5.1, and the USG has picked up the WAN IP address (a 10.x.x.x private dynamic CGNAT address from giffgaff).

OK. So now for what doesn't work. I can't ping out from the RUTX09 to the USG LAN (so presumably MQTT isn't going to work). This is not surprising as the USG WAN port has no local IP address of the form 192.168.5.x, just the 10.x.x.x WAN address, and there is no route for the new connections within the RUTX09 (I'm actually surprised the gui interface works as ARP can't work as the USG interface has no valid subnet address!).

In addition, the USG logs are showing lots of "ubnt kernel: IPv4: martian source 10.x.x.x...." warnings. So I clearly do not have the interfaces setup correctly.

So my question is a very general one, is there a documented configuration for this simple use case for the RUTX09 and the USG? If not, can you give me a pointer as to how these interfaces, in general terms (or even specific terms) should be set up so that there is a valid route from the RUTX09 to the USG LAN?

(I'm using the latest firmware in all devices).

Regards

Francis

Answer 1

Hello, 

For this inquiry of yours, I have tested it on my side since I don't have any USG router I have replicated it using my RUTX11 and RUT955. 

The connection I made is like this: 




For the Mobile Config for RUTX11 on my side, I did it like this: (For clearer image you can visit this: https://prnt.sc/12kf39s)


I input the WAN MAC address of RUT955:


From that without any further changes I am able to make everything work perfectly I am able to reach the Web UI of the RUTX11 from the PC connected with RUT955. 

So, it would be best to check if you put the correct WAN MAC address of your USG router. 

Here is a short video to show you that it works perfectly :)  https://we.tl/t-YdAznXDKHO

I hope this helps.

Regards,
Mellow

Comments

Hi Mellow,

thanks for your response. As I mentioned in my question, I did get to the stage of accessing the Web UI (I called it gui) from the LAN side of the USG. So I believe I had got as far as you reported in your test (eg MAC address is good). The thing that is not working however, as there isn't any configuration in place to achieve it, is the reverse direction eg ssh into the RUTX09 (which works) and then trying to ping the USG or anything on it's LAN using an ip address (which doesn't work). My aim is to use MQTT in the RUTX09 to extract status, but if I can't ping from it, I'm sure it's not going to work. Hopefully, that makes the issue clearer. I'm after a technique to get this correctly configured so traffic can be originated from the RUTX09.

Regards

Francis

---

Hi Francis,

Okay noted thank you for the clarification I misunderstood it. I will check if there is a way to achieve the scenario you want to implement.

I will let you know once I have the solution.

Regards,
Mellow

---

Hello Francis, 

Kindly check the document found in this link: https://mega.nz/file/zp00BTTQ#eALC4e9dUC5ifX0r6dUj7os9HfDxeAEm7qfJ5Qnec3g  for reference. 

Also, you can check this link for route command reference: Linux route Add Command Examples - nixCraft (cyberciti.biz)

I hope it helps

Regards,
Mellow

---

Hi Mellow,

thanks once again for your response. I'm travelling at the moment so will check out the solution in a few weeks time.

Kind Regards

Francis

---

Hi Mellow,

I believe the main issue that I had resided in the USG and not within the RUTX09. (I had set up a virtual interface on the LAN port which resulted in martian source errors from the arp packets from the RUTX09, and this seemed, as far as I could tell, to periodic failures, about every 30s or so - this is still a mystery to me). I believe I now have a working system which I will summarise here for those that follow....

RUTX09 Configuration

1.1 Set the mobs1a1 interface to passthrough mode and enter the mac address of the USG.

1.2 Configure the LAN interface with a static IP address (In my case 192.168.5.1, mask 255.255.255.0, gateway 192.168.5.2, broadcast 192.168.5.255, DNS 192.168.2.5 (pi-hole on a pi).

1.3 Enable the LAN interface DHCP server.

1.4 Configure a static route for the lan interface to target 192.168.0.0 (because I have other subnets in this range beyond the USG), mask 255.255.0.0, gateway 192.168.5.2.

1.5 Setup a manual entry in the arp table using "ip neigh add 192.168.5.2 lladdr xx:xx:xx:xx:xx:xx dev br-lan" where the x's are the mac address of the USG, the same as in the bridge setup. (The reason for this is that in this scenario 192.168.5.2 doesn't actually exist in the USG and so it can't be arp'd).

USG Configuration

2.1 Setup the WAN port for DHCP (not ppoe as I had anticipated from having previously setup adsl modems). This picks up, in my case, the 10.x.x.x CGNAT dynamic ip address from the mobile operator.

2.2 Setup a static route for 192.168.5.0/24 to the USG WAN interface.

2.3 That's it in this scenario. I have NOT configured 192.168.5.2 using a virtual/pseudo-ethernet interface as it isn't necessary.

So in the RUTX09, the 192.168.5.2 gateway address is just used to get you to the manually entered mac address of the USG in the arp table. This seems to me to be a very unconventional way to configure this pair of interfaces, but it side-steps the martian source problem in the USG, which I was unable to find a solution to.

I believe that's it. Problem solved, sort of.

Many Thanks

Francis