Troubleshooting Tricks for Orbi Networks

I love a good troubleshooting challenge. But damn, this one had me stumped until I could pull back the covers of my Orbi system to discover the root cause.


I have a vmWare ESXi hypervisor in my home lab. The ESXi system is trunked up to a Ubiquiti router that is handling inter-vlan routing and has my Orbi base station set as the default gateway.

Home Network

I spun up a Cisco FTDv NGFW image, set the outside interface to and the default gateway to the address on the Ubiquiti router. Ok, we are all fired up, let’s test basic connectivity.

Ping Fail

Hmmm. I dug into some packet captures and debugs on the Ubiquiti, and as far as I could tell, the packet was being delivered on vlan 1 and being delivered to the Orbi, who should have responded with an echo reply. I could ping the Orbi from my workstation on the subnet, but not from the subnet. Of course, I have a static route in the Orbi to reach the subnet, so there was not a routing issue. AND, I could ping my workstation or any other IP address on the subnet EXCEPT the Orbi. 

Orbi Hidden Debug

I did a little google action and discovered that there are some backdoors in the Orbi for advanced troubleshooting. The trick is to go to: From this screen you can enable some debugging captures, which I tried first, and then you can download them and view them offline in Wireshark. It’s actually a pretty robust set of data that the debug tool returns. 

Sure enough, I saw my ICMP echo requests reaching the Orbi just fine, but still, no responses from the Orbi.

Wireshark Capture

Ok, so what is the Orbi doing with these packets? Enter the next nice little hidden feature of your Orbi: Console access. By enabling telnet from the debug.htm page, I was able to remote into the Orbi shell, which is just BusyBox embedded Linux.


It only took me about 30 seconds to discover the problem.

ifconfig tun0

Directly connected routes have a metric that is always preferred over static routes.

Bingo! Yup, there is a local interface on the Orbi that is already using the subnet. Which means that my ICMP requests were being returned over the tun0 interface and not back to my Ubiquity router, because directly connected routes have a metric that is always preferred over static routes.

Mystery solved.

TLDR; You can’t use the subnet

Once I changed my vlan interface to, full connectivity was achieved.

Working Ping

2 thoughts on “Troubleshooting Tricks for Orbi Networks

  • July 22, 2019 at 6:02 pm

    Nice Write up… Question: by chance was the tun0 network your isolated guest Wifi Network or the DMZ network? I’m looking at my Orbi right now and I don’t have any of those networks. Though I am having issues getting my 2nd 172.16.x.x subnet to the internet, which lead me to your post. I have a 74.x subnet the Orbi is on and a 75.x subnet for ESXi VM’s but the VM’s cannot get to the inet, not matter what I try. I’ve tried static routes and RIP, though I can ping everything internally the 75.x network cannot get to the inet.

  • July 23, 2019 at 9:31 am

    Hi, this was not with a guest network and YMMV. I would suggest telneting into the Busybox shell and then look at the routing table and the interface IP addresses.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: