Internal Server Error when hostname used

Exceptional effort.  Wow.  Seems you have reproduced the problem just as I described it.

Okay, following your clever suggestion, with the OpenWRT router firmware, I found I can assign any IP address to any legal internet name, and the DNS server in the router will honor it.

So I tried it.   Well I'll be damned.

The Orbi, in AP mode appears to accept any nodename that is a prefix of either:

     orbilogin.net

     orbilogin.com

For example it accepts:

      o

      orbi

      orbilogi

      orbinlogin

      orbilogin.n

      orbilogin.c

But gets a 500 error with:

      orbit

      orbilogin.nett

      orbilogin.comm

      orbilogin.org

So thanks to your creative idea, we have characterized the behavior of the Orbi firmware.  Question is:  "Is this a bug or a feature"

Whilst we ponder this question, I am going to rename my Orbi AP and its satellites:

     orbi, orbi1, orbi2

Thanks for conducting the experiment.  My guess is that Netgear engineers attempted to resolve an issue that affected Orbi routers when in Access Point (AP) mode.  To wit:

• When in router mode, users could reach the web interface with a browser using any of the special URLs (routerlogin.com, routerlogin.net, orbilogin.com, orbilogin.net, etc.), but
• When in AP mode, the router did not perform DNS analysis and thus would forward connection attempts to those URLs "up the line" to the primary router, which would not be able to resolve them into IPs (because they are not really URLs).

I seem to recall posts on the forum from users unhappy that they had to enter the router IP address rather than the cool URL when in AP mode.  Netgear may have fixed that problem by having the AX series router examine URLs even when in AP mode.

What is not clear (to me) is whether the AX series:

• Examines http URLs (the "Host:" parameter) on every http connection attempt that passes through the router in AP mode, or
• Examines http URLs ("Host:" parameter) only when the http connection is directed at the IP address of the router in AP  mode.

I guess another experiment would be:

• Have no hosts entry for the Orbi router.
• Open a web browser to http://orbilogin.net from a device that is on the Orbi LAN (not on the WAN side of the Orbi)
• See if the router in AP mode pops up the web interface.

I'm still voting for "bug".

Just to put lipstick on this pig.....

• Reinstalled the RBR750 in AP mode.
• Opened a web browser on a laptop wired to the RBR750.
• The Windows host file does not contain any entry for orbilogin.net
• Connected to http://orbilogin.net 

It opened the web interface on the RBR750 - not the primary Orbi router.

This leads to the conclusion that Netgear traps every http connection that passes through the AX router when in AP mode to see if the "Host:" might be the Orbi itself.

Thus users who are accustomed to their Orbi being "orbilogin.net" (or equivalent) can reach the device even when it is in AP mode.

Here's a simplified explanation of what happens with a home router (including an Orbi router) when you enter a URL into your browser.

• The browser does a DNS request to the router.  The request effectively says:    "What is the IP address associated with this name?"
• The router gets the request, and checks if the name corresponds to a node on the local network, or is otherwise configured as a special case.  If either is true, it sends the corresponding IP address back to the requesting node.
• Oftherwise, the name is not local or special. The routers forwards the request to the internet DNS servers and waits for a response.  If the response is successful, the received IP is sent to the browser.  If there is an error, or the request times out, an error response is sent to the browser.

With an Orbi home router, running the factory firmware, the name "orbilogin.net" is recogtnized as a special name, and a special case.  When received, the router sends back its own IP address on the local network.  By default, this is 192.168.1.1, but you can change that.

When the browser gets the IP address, it sends an HTTP request to whatever IP address is received.  The HTTP request includes the originally requested name.  The name is used if there are multiple virtual web servers with the same IP address.  This is commonly done where a single computer handles multiple different customers.  For example "landscape-spcialities.com" might be handled by the same computer, at the same IP address as "bills-appliances.com".

In the case where the IP address is the address of the router on the local network, it goes to a web server in the router.  The multiple customer case does not apply.  Everything received by the Orbi goes to the same UI, or should, no matter whether the name is "orbirouter.com" or "hows.your.sister" or just an IP address.

You can make an argument that an orbi router might check for "routerlogin.com" to detect some sort of error.  It's dubious why you would want that.  For example my internet router has been called "gw" (gateway) for 20+ years, although many different routers from different manufactuers have served that function.  Checking for "routerlogin.com" is just an inconvenient pain-in-the-butt, as far as I am concerned.  My chosen name "gw" would always be rejected.

Now checking for "orbirouter.com" on an AP is even worse.  Suppose I use an orbi AP and a seconds Netgear router to get to the internet.  I actually did that for awhile.  The second Netgear router was positioned where the internet came into the house, which was in a far corner in the basement.  A lousy place for a WiFi server.  So I ran an ethernet cable from there to my Orbi AP in the center of the house.  The perfect place place for a WiFi server.

What possible good could it have done to have both of these devices named "orbirouter.com".  Why would you want that?   How could that ever work?

So this convention in the firmware is not sensible.  It's irritating in the router, and downright stupid in the AP.  It it is deliberate, it indicates that Netgear doesn't understand home network configuration.  If it is a bug, well then all software has bugs, so I can understand that.

This is the kind of thing that comes out of Marketing requirments.  Some idiot in the Marketing department (having never configured a network) thinks it is a cool idea, and insists on it in a bug fix meeting.  The software mainteance engineer gets tired of arguing with Marketing, and puts it in.   He forgets to turn it off in AP mode, and that results in this discussion.  Maybe the Marketing guy is smarter this time, and tells the software engineeto take it out everwhere.  Like it was in the first place.  Like it should be.  Or maybe the Marketing guy is just a stupid **bleep**.

This sort of thing allowed Scott Adams to make his fortune with Dilbert.

Using "routerlogin.com" to get to the router is a bad idea in the first place.  It is too easy to misspell.  Common misspellings include "ruterlogin.com", "routerlogon.com" and so forth.

Suppose a hacker wants to break into your system.  He registers a few common misspellings of "routerlogin.com".  On each he runs a web page that looks *exactly* like the Netgear login page.

You aren't paying attention one day, and you misspell routerlogin.com.  You go to the hacker web page.  You see exactly what you expect to see, so you type in your username and password.  The web server records them, together with your IP address.  Then it redirects you to the correct spelling of "routerlogin.com", which sends you to your router web page.  You figure you misspelled the password, so you enter the information again.  This time it works.  You don't suspect a thing.

However now the hacker has everything he needs to break into your router.  From there he can run barefoot through your home network.

I never used "routerlogin.com".  I was afraid I would misspell it when I wasn't paying attention.  I used the IP address, or my own simple name for the router.

This is a variation on an old trick that dates back at least to 1970s time sharing systems.   It worked them.   It still works.

I fear that the AX series Orbi does not follow the typical procedure when in AP mode. (God knows what it does in router mode, and she's not telling us!)

In my test:

• The RBR750 is AP mode
• A laptop is connected (Ethernet) to the RBR750.
• The laptop web browser attempted to connect to http://orbilogin.net 
• The laptop hosts file did not have an entry for http://orbilogin.net 
• If a DNS request had been sent through the RBR750 to the primary Orbi router (RBR50), it would have responded with the primary router IP address (192.168.1.1)
• This would cause the web browser to attempt to connect to the primary Orbi router web site.
• However, the web connection was made to the RBR750 web server (in AP mode).

Thus, it appears that in AP mode, the AX router series (not the original Orbi products) intercepts and redirects web connections to http://orbilogin.net 

p.s. I am SO DISAPPOINTED that Scott Adams lost his cool and Dilbert is no longer available in my daily paper.

Joining this thread after having been directed here from https://community.netgear.com/t5/Orbi-WIFI-6-AX-AND-Wi-Fi-6E-AXE/New-RBR850-RBS850-Firmware-Version-7-2-6-21-Released/m-p/2337089/highlight/true#M49721 by CrimpOn .

I also have this same issue, my original description is posted at https://community.netgear.com/t5/Orbi-WIFI-6-AX-AND-Wi-Fi-6E-AXE/New-RBR850-RBS850-Firmware-Version-4-6-14-3-Released/m-p/2284753/highlight/true#M41761.

Today I did some packet captures to try and better understand this issue. For context, here's the key parts of my setup:

• I have a RBR850 and 3 RBS850s. I run the RBR850 in AP mode and it has a single ethernet connection to my network switch. There are no other ethernet cables connected to the RBR850.
• My RBR850 had an IP address of 192.168.13.11, and a mac address that ends in c7:02
• My internal network is 192.168.13.0/24.
• I have a pair of firewall/router machines that run OpenBSD (which is not relevant for this discussion)
• I run my own DNS servers (i.e. not running on the RBR850): they have an authoritative zone for internal hosts, and resolve all other requests via the root name servers.
• My internal DNS server resolves ap1.kotfu.net to 192.168.13.11.
• I know this works because I can ping ap1.kotfu.net and I get responses from 192.168.13.11
• For this experiment, I accessed the web admin from a computer with an IP address of 192.168.13.25
• For this experiment, 192.168.13.25 was connected via ethernet only, so there were no relevant packets in this capture transmitted via WiFi, they were all over hardline.

Here's the capture of me typing "http://ap1.kotfu.net" into my browser address bar and hitting return:

Here's the capture of me typing "http://192.168.13.11" into my browser address bar and hitting return:

Now a couple of observations and a theory.

1. Note that there are no DNS requests made by 192.168.13.11 in any of these packet captures. That's not surprising to me. It means that the RBR either doesn't care about the hostname for the IP address, or it already has it cached. In Access Point mode, the only reason for the RBR to want/need the hostname for an IP address would be to log the hostname in a log file. In the logs available to us, entries include the IP address, not the hostname (i.e. the log entry when you log in to the web console).

2. The only material difference initial packets in the two different captures, is the "Host" header in the HTTP request. When the "Host" header contains an IP address, the web admin pages are served to the client. When the "Host" header contains my hostname "ap1.kotfu.net", the HTTP error 500 is generated.

Here's my theory. I don't think it's a DNS issue. My RBR850 can resolve hostnames on my local network, because I have it using an internal time server, and that works fine. Also, the "Host" header is not a DNS thing, it's a HTTP protocol thing. When the RBR850 is in Router mode, two things must happen in order for "orbilogin.net" and "routerlogin.net" to work properly: 1) DNS queries for those domains must resolve to the IP address of the RBR850, and 2) the web server running on that IP address must properly respond based on the contents of the "Host" header. In this case, the RBR850 should serve the same web content regardless of what's in the "Host" header. In my setup, where the RBR850 is in AP mode and I run my own DNS servers, I can already assure that DNS queries for "ap1.kotfu.net" resolve to "192.168.13.11", the IP address of my RBR850. The packet captures above confirm this is true.

That means there must be a problem with the second condition. My guess is that when you switch to AP mode, the RBR850 puts a different web server configuration file in place (or applies some edits in place to the config file already there). The web server configuration in AP mode seems to have an error in how it handles the "default server". This configuration error causes the web server to return HTTP code 500.

EDIT: further experimentation reinforces this theory. By tinkering with the hosts file on the machine running your web browser, you can make several entries which point to the IP address of the RBR850. I added:

192.168.13.11	someserver.com
192.168.13.11	routerlogin.net
192.168.13.11 	orbilogin.net

When I use the hostnames that we know are configured in the web server on the RBR850, ie "routerlogin.net" and "orbilogin.net", the web page loads fine. When I use "someserver.com", I get the HTTP 500 error.