This complaint is commonly heard when trying to set up a network or LAN connection from remote.it running on a compatible device (Raspberry Pi, Windows PC, etc.) to a router UI on the same LAN. The router's interface may fail completely or partially. Then underlying reason is that the router's HTML coding assumes that the client can resolve the address in question.
For example, suppose your router is at 192.168.1.1 and your Windows PC is at 192.168.1.12. If the router puts up a link such as http://192.168.1.1/login.html, then your PC is able to resolve that address because it's also on the 192.168.1.x network.
However, if you were to try to access this via port forwarding, it would fail, because in that case your PC tries to access your router's WAN port, which has been forwarded to the web server's listener port (e.g. 80) using your external public IP address, not its LAN address.
A similar problem occurs when using remote.it. Your client PC accesses the remote web server using either a remote.it proxy address, e.g. https://randomui.remot3.io, or a localhost address such as https://127.0.0.1:33000 if you are using peer to peer connection mode. In both of these cases, the client cannot resolve URLs which are relative to the router's absolute LAN IP address.
The problem is in how the web UI was coded and typically cannot be changed unless you wrote it yourself.
One workaround you can try is to use either:
- Raspberry Pi with graphical desktop support
- Windows PC
and install remote.it on that, configuring a target Service for one of:
- RDP (Windows 10 Pro only)
- VNC (you'll need to install a VNC server application such as tightvncserver)
- VNC (aka screen sharing)
These will give you the ability to connect to that device's graphical desktop. From there, launch a browser and navigate to the router's web UI. Now the client for the browser is on the same LAN as the router and it should be able to resolve any absolute IP addresses in links.