My Chrome extension cannot reach the AW Server because it’s looking for 127.0.0.1. My AW Server is configured for a local, private issue IP.
How can I configure the web extension to look at an IP different than 127.0.0.1?
Having aw-server running on a remote machine is not officially supported so we are probably not going to fix this, but if you really want to do this anyway you can edit the source code of the extension yourself and change the IP which the extension should report to. Shouldn’t be more than a few lines of code.
The machine is local. I have a virtual network card set up with a fixed IP my VMs can communicate with. The AW Server is bound to the IP assigned to the virtual card in the AW Server config.
AW Server responds to the IP assigned in the config file, but not 127.0.0.1.
Can AW Server support multiple host IPs?
By remote I meant non-localhost. While a VM is running on the local host it’s still isolated from the rest of the host so that makes it essentially the same thing as running a remote server. That’s usually the point of having a VM, to sandbox a system from the real host system.
aw-server does not support multiple host IPs, but even if it would it wouldn’t solve the issue as 127.0.0.1 would still be blocked from within your VM.
I’m not quite sure I understand your set up, but it sounds like you could work around this problem by using a SSH tunnel to route 127.0.0.1:5600 to IP you want to use. That’s currently the best way to connect to a remote aw-server instance.
Adding support for connecting to a non-local instance of aw-server is pretty far down our list of priorities right now (see the feature request category here on the forum).
1 Like
VM clients -> AW Server @ Private IP … All is well.
VM client web browser … Cannot reach host.
VM Host minus web browser … All is well.
VM Host web browser … Cannot reach host.
If AW Host could bind 2 IPs, I could assign 127.0.0.1 and my private IP it would almost solve all my problems. Like Johan said, the web extension glued to 127.0.0.1 in the VM client would still be a problem.
For me, I could live with VM client browser support because I don’t really use the browser in guest VMs for browsing. That happens in the host.
This is false, if you bind it to 127.0.0.1 as well your VM clients still wouldn’t be able to access because that IP would redirect it to the VM itself rather than the AW Server at your private IP. 127.0.0.1 always means localhost (in this case the VM) no matter what.
You need to either port 127.0.0.1:5600 for example with a SSH tunnel like @ErikBjare suggested or modify the source code for the extension.
This is false.
Um. I said the same thing, which is why I said “almost.” The VM web clients would still not be able to access the AW Server on the host.
And…
Like Johan said, the web extension glued to 127.0.0.1 in the VM client would still be a problem.
For me, I could live with VM client browser support because I don’t really use the browser in guest VMs for browsing.
Sorry for not reading your comment properly.
You could still solve the issue of binding to two addresses and ports by using a SSH tunnel though.