Are LAN server connections supported for https://gibberish.local addresses?

This question is about setting up a new Windows 11 client machine to talk to the server (which is running fine on the local network). It also applies to a second Windows 11 machine that is running on the LAN.

Q. Is the StartOS server supposed to respond to ‘https://startos-gibberish.local’ addresses when Bonjour is running?

The About screen gives an .onion address for the server that works fine in a Tor window. I thought I could connect to the server using the startos-gibberish.local address equivalent on the LAN (Bonjour running), but apparently not. Using certificate-name.local window works fine in a normal browser window.

I might be trying to do something that is not supported. I could not see any explicit statement in the doc that connections using the startos-gibberish.local addresses were forbidden.

Here are the debugging details for the new Windows 11 machine

  • has Bonjour installed, rebooted, and running (I checked its status)

  • connects fine to startos nextcloud server in browser with ‘https://nextcloud-gibberish.local’ address

  • connects fine to startos admin login screen with ‘certificate-name.local’

  • Now try to connect to startos with ‘startos-gibberish.local/onion’ addresses copied from the StartOS About screen

  • Brave Tor Window:

  • connects fine to startos admin login screen with ‘https://startos-gibberish.onion

  • connects fine to Nextcloud login screen with ‘https://nextcloud-gibberish.onion
    This means the startos-gibberish.onion address is right from the StartOS About screen.

  • Brave browser normal window (replacing .onion suffix with .local)

  • connects fine to startos nextcloud server in browser with ‘https://nextcloud-gibberish.local’ address

  • fails to connect to startos admin login with ‘https://startos-gibberish.local’ (.onion replaced with .local)

I am at a loss to explain why the browser will connect fine using the nextcloud-gibberish.local address but not the startos-gibberish.local address. I’m using the exact same browser window and the startos-gibberish address that had the .onion suffix. I checked to make sure .local was replaced properly too. No typos there. Bonjour seems to be working okay, the server is working okay, nextcloud and the server both respond okay in Tor windows with .onion versions of the address.

Am I trying to do something that is not supported? (If so, I wonder why is it not supported? Aren’t .local and .onion addresses interchangeable on the LAN if Bonjour is running?)

Does anyone have any suggestions about what I might try?

Your report is a bit confusing. It is most helpful to us if you describe a single problem, with an exact error message or screenshot.

It is not clear to me that there is an issue here. It is not expected to be able to connect to .local addresses while using the tor network (as you are technically not on your LAN anymore), therefore when using a tor window or tor browser, .locals will not work. This should explain your first set of concerns.

Regarding .locals on ‘regular’ browser windows - you seem to first claim that they work, but then later claim that they do not. If you are attempting to use the tor hidden service address provided by the About page and replacing it with a .local suffix - that is not a real address. These public keys are only serving the dual LAN/Tor usecase for services. The reason is that the public key .local addresses are mDNS “aliases” of the main UI’s .local address. Only the adjective-noun.local is used for the main UI access on LAN.

Hopefully this clears things up. If not, please provide specific error messages with the steps to get to that error.

Hi Dave, there is no error message (other than the normal browser window saying that it cannot connect to the server.local address).

Yes, I am claiming that .local in a normal browser window works when connecting to the Nextcloud server on the StartOS machine. Yes, I am claiming that .local will NOT work when connecting to the StartOS login server on the same StartOS machine.

My takeaway from your post is that it is not possible to connect to the StartOS server from a normal browser window on the LAN using the onion->local suffix replacement technique. Instead, the certificate-name.local method must be used to reach the server over the LAN from a normal browser window.

I naively thought that I could take any .onion address, replace onion->local, and then use the resulting .local address in a normal browser window on the LAN (with Bonjour running, of course, to translate the .local URL into the local IP of the server). But I guess that is not true.

You can indeed use either/or.

Where maybe there is some confusion is that in your original message you seem to state that you expect to be able to access…

SERVICENAME-adjective-noun.local

No such .local or .onion will exist.

Perhaps what you should instead do, to clear up all confusion is to visit your StartOS interface at adjective-noun.local.

From there, click into each of your services that interest you then scroll down and click into Interfaces to see the interface addresses listed clearly. Those do and should work in the correct setting.

My apologies! My writing must be terrible if you thought I was talking about service-adjective-noun.local! (I was not.)

I was saying that on my LAN, I could reach the server:

  • using adj-noun.local
  • using key.onion in a Tor window (you call them keys, I think)
  • but NOT using key.local in a normal browser window

I have no issues connecting to the Nextcloud service:

  • using key.onion in a Tor window
  • using key.local in a normal window
  • using the NC local app, which uses key.local as a service address.

Thank you

So the ONLY thing you can’t access is the Start9 UI itself. ALL individual services can be access with their .local?

He’s trying to access the main UI using his tor pubkey.local, which is not possible. He’s able to access with adj-noun.local, as expected. I don’t see any other issues here. Please correct me if I’m wrong Kevin, otherwise we can call this solved.

Yes, that is correct. I cannot reach the Start9 UI using pubkey.local, but I can reach it using pubkey.onion.

It’s a symmetry issue for me. I can reach Nextcloud on the box by using EITHER pubkey.local or pubkey.onion, so I expect to be able to do the same symmetric things with the Start9 UI.

It lives on the same box, on the same network, and runs through the same software on my client browser that Nextcloud uses. So why shouldn’t both pubkey.local and pubkey.onion work? Instead, I need to use adj-noun.local and pubkey.onion. Not symmetric. Not intuitive. Instead, confusing.

Is there a reason that someone, somewhere, decided to not support symmetry and not to support pubkey.local to reach the Start9 UI? A compelling reason would help to satisfy my curiosity because (in my ignorance, perhaps), I could never imagine doing such an asymmetric thing if I were writing the code… Thank you.

As I explained above, the service .locals are mDNS aliases of the adj-noun.local. This decision was made such that the dashboard would be a human-memorable name, from where all other service URLs can be visited. There is no mention anywhere in any guide or messaging from Start9 that the dashboard can be visited with the tor pubkey on LAN, and you are the first to attempt to do this in the over 3 years that this system has been in place. That said, everything will be accessible via IP and Port from StartOS v040, which should satisfy the desire for symmetry. Other networking options will also be available, such as hosting to a clearnet domain or subdomain, furthering human-friendly access options.

Great answer, thank you. I totally agree that my symmetry attempts were not discussed in any documentation. :slight_smile: I guess all the other people in 3 years either were careful to color inside the lines or had no problems or did not bother to report them in the forum.

Not that it matters, but I have had many decades of experience asking/reporting questions in forums (since the mid-1970s). It’s always a tradeoff for me - should I bother to take my precious time to ask/report unwanted questions and issues so that other people can waste their precious time on the issues? (I’ve heard the ‘you’re the first one …’ many times in my life, sometimes with the implication that something must be okay or right ‘because I’m the first one…’ and sometimes to implicitly chastise me for being so to post such a <minor, unrecommended, fill in your modifier> issue in the forums.

If it is possible for you to make/state a policy on my posting, just let me know, and I will abide by it. I surely don’t want to waste time posting things to make them visible if people don’t care/don’t want/etc to waste their time. I’ve written over 1,000 pages of software doc in my decades, and it’s always a drag to have people trip over the doc, spot missed places, go outside the exact steps in the doc, and so on. I don’t want (or enjoy) being a drag on your Start9 effort, believe me. It’s hard enough to be an entrepreneur without the public wasting your time by reporting their issues.

1 Like

Having someone go over the details of our system / documentation is highly valuable. There are edge-cases that only our community will find, as we simply don’t have the same bandwidth and creativity on our small team that our broader community can muster. Forum posts are definitely helpful, especially when feeling out a feature/issue or posting a guide for others. Going over minutia can be frustrating on our side, but we do want to understand all possible angles, and will do our best to investigate alongside you. In regard to messaging and docs, it is most helpful to post an issue, or even better, a PR, directly into the documentation repository.

Thank you for your helpful reply. You probably know this already, but I will state it explicitly for the thread. If a person has a specific, defensible claim that the doc is wrong or should be modified in a particular way, then opening an issue or asking for a pull request to pick up new doc is a good way to go. Keeping in mind, of course, that for someone like me who doesn’t know git, use git, and certainly doesn’t use the 5 (?) step chain of doc tools that Start9 uses to build their doc, it’s a big time commitment to fix/extend the doc and generate a pull request. (To say nothing of the possibility that the change will be rejected by the community, in which case all that work and time is lost.)

In my case, posting to the forum kind of walks a middle line where I report my lived experience based on (at least initially) trying to follow the doc to get my machine set up. My hope is that by posting my experience rather than my opinions, I might make it easier for the team to connect with the experience and do whatever they think is appropriate (if anything) to avoid/prevent my issue from surfacing.

As much as possible, I just try to find a bypass or workaround to get the job done on my end without asking for help from the forum. I’m sure everyone already has other things to do. :slight_smile: I only post to the forum for two reasons - 1) if I am REALLY stuck, totally, even after RTFM, or 2) to make the issue visible for others to do with as they want.

I want to believe that most of my posts here are in category 2), just reporting them for others. I have long since gotten my machine running. Hoping this helps… :slight_smile: