Forum Replies Created
-
Posts
-
I just tried out the new server.cfg and version you sent, and it works! Thank you for helping me work through this.
(I don’t know how those settings in server.cfg were changed, especially since they were obviously wrong. It seemed like some of the STUN/TURN settings I set up got mixed into the main server settings. I’m fairly certain I didn’t make those changes myself!)
I just tried and I’m afraid it didn’t make a difference. I also tried loading the page in multiple web browsers (Chrome, Firefox and Safari) in a private window with all extensions turned off, and am still getting a blank screen.
Hello all,
Sorry for all of the back and forth and confusion this thread has caused. I just tried the test where I connect to my mac (i.e. system 1) from out of my local network while the VPN is connected, and that doesn’t work either. I could’ve sworn there was a point in time where it did work, but apparently no longer.
That at least gives me another avenue to pursue. If I can get that working then I will try to implement the same solution with NoMachine, and then report back as to how it works. Hopefully I’ll have a happy end to the story to tell!
Sorry for the delay in reporting back. I just tried the test version you sent, and when I connect using HTTPS, I just get a blank screen. 🙁
I also tried updating to the current latest version 8.3.1, and have the same issue. The only error I can report is that the following gets printed to the web browser console:
Uncaught TypeError: Cannot read properties of undefined (reading ‘toLowerCase’)
at Object.z0182af5a83 [as SETTINGS] (desktop.js:1483:22223)
at Object.zfbae673a6e [as success] (desktop.js:1483:4361)
at c (desktop.js:10:28327)
at Object.fireWith [as resolveWith] (desktop.js:10:29072)
at l (desktop.js:10:79901)
at XMLHttpRequest.<anonymous> (desktop.js:10:82355)
Tom, thanks for taking the time to look into this and duplicate this situation in your lab.
If it’s an issue with the VPN configuration, then I need advice on how to fix it.
Remember, NoMachine is the only service that I cannot access on computer 1 when it is connected to the VPN. All other services on computer 1 are fully accessible from the internet with proper port forwarding, even when it’s connected to the VPN. This may not necessarily be a bug in NoMachine, but at the very least NoMachine is doing something differently from other services that prevents it from working when my system is connected to the VPN. It may also require a change to NoMachine’s configuration.
The issue must have something to do with how traffic is being routed.
Is there any way to force NoMachine to use a specific network interface for all of its network traffic? If I can configure it to always use the ethernet interface, then I think everything should start working.
Another possible issue: Does NoMachine make any outgoing connections to clients using the NX protocol on top of receiving an incoming connection? All incoming connections should happen over the local ethernet interface and not the VPN, as my router forwards to my system’s local IP address. However, if NoMachine also made a separate outgoing connection to the client as part of the NX protocol, then that would go through the VPN, and that could explain why the connection fails to work.
Ah, I missed that computer 3 in the diagram is labeled as being connected to the VPN. It is not. The only computer that connects to the VPN is computer 1.
Yes, computer 1 and 2 are on the same LAN, and I can connect from computer 2 to computer 1 using both SSH and NoMachine’s NX protocol, even when computer 1 is connected to the VPN.
I think this issue must have something to do with NoMachine specifically, perhaps the way NoMachine hosts its service on computer 1. This is because NoMachine is the only service that I cannot connect to from the internet (i.e. from computer 3) when computer 1 is connected to the VPN. All other services work properly, provided I have set up port forwarding correctly.
It doesn’t make sense to me, though, because presumably NoMachine is binding to address 0.0.0.0 so that clients can connect to it from any network interface. And I even used the “NXdListenAddress” setting to force it to bind to the local 192.168 LAN address. Furthermore, my router will forward outside connection attempts on port 4000 to computer 1’s LAN address specifically, meaning the VPN’s virtual network interface and its assigned IP on the VPN’s subnet should never be used. And yet for some reason I cannot connect when the VPN is connected.
Could there be something I need to change about my router configuration so that it forwards packets correctly? I have it set to forward both TCP and UDP packets. Perhaps there’s another port that needs to be opened up?
Or, could it be that there’s a handshake that happens at connection time, something like TUN/TAP, that is not binding to the same network interface as NoMachine’s NX service, and therefore the handshake fails when the VPN’s network interface and gateway is the system’s default?
Or, do I need to add a specific static route to computer 1’s routing table in order for NoMachine to work properly over a non-default network interface?
Can you try connect using NoMachine to the server (with VPN enabled) using Public IP not whatever.xxx.net domain?
I’ve tried, and it doesn’t work. I can confirm that my hostname is correctly resolving to my network’s public IP address, though.
Can you, with VPN enabled, ping whatever.xxx.net?
Yes.
Are you connecting to the server via SSH using the domain with the VPN enabled? For example, ssh user@whatever.xxx.net?
No, this system is not set up to be accessible via SSH from the internet, though I can connect to it via SSH from another system on my local network while the VPN is enabled.
Thanks for the drawing, as it does allow me to clarify:
The green arrow represents how I am trying to connect.
The VPN service is meant for privacy, and only intended for helping to anonymize computer 1’s outgoing internet traffic. It’s not intended for connecting to other systems on the VPN, and in fact the VPN service is specifically set up to forbid this.
My home office’s router forwards all traffic on port 4000 to computer 1’s LAN IP, so that should bypass the VPN and connect to an open port on computer 1’s ethernet interface. And this is what happens for all services other than NoMachine.
Tom,
The hostname I am connecting to resolves to my home office’s public IP address. I have port forwarding set up so that port 4000 is forwarded to the Mac running NoMachine.
I’ve confirmed this works because if my Mac is not connected to my VPN service, then I am able to connect just as I attempted to in the log file that I posted. It’s when the Mac is connected to the VPN that I am unable to connect from outside my local network.
Brief update: I’ve found that when my mac is connected to my VPN, I can in fact connect to it from systems on my local network. I’m not sure why it wasn’t working previously.
As for clients out in the internet, I’ll have to test that separately, but won’t be able to do so until I’m at a separate office later this week. I’ll report back when I have the logs as requested.
To answer your questions:
1. Yes, Viscosity is an OpenVPN client app, and I use it to connect to my VPN using the OpenVPN protocol. The OpenVPN server is out in the internet somewhere.
2. If I understand your question correctly, the NoMachine Server’s IP address on the VPN’s network is not the same as its IP address on my local network. Both networks are a different subnet with different IPs and IP ranges.
3. Yes, when the VPN client is disabled / disconnected, I can connect to the NoMachine server using any NoMachine client. Both NoMachine clients on my local network and NoMachine clients connecting over the internet are able to connect.
Tom, you are correct, I do need to clarify! And I need to correct a few things I got wrong in my first post.
My mac is connecting to a privacy VPN service, so the VPN server is not running on my local network. This means that my mac is the only one connected to the VPN. The VPN configuration sets its gateway as the default gateway, with a few exceptions that I’ve set up, so all outgoing traffic is routed through the VPN. (Specifically, I have it create static routes for certain IP addresses that go through the local gateway rather than the VPN gateway.)
Further, I had said that other systems on my local network could connect to my mac using NoMachine and the NX protocol. This is not actually correct. When my mac is connected to the VPN, no connections can be made with NoMachine at all, including from other systems on the local network!
However, I can still ping the mac using its local IP address from other systems on the network, and I can connect to my mac using any other service. (This includes ssh, ftp, smb, http or https, and so on.) So NoMachine is the only service that I can’t connect to while my mac is connected to its VPN.
Mizamook, I can offer you a sort of “band-aid” solution to this issue that I figured out.
It’s possible to remap keys on your macOS system using an app called Karabiner Elements, and only have the remapping apply while NoMachine is the foreground application. I used this to swap around the Command and Option keys so that when I remote control my Windows system, the Win and Alt keys will be in the expected places as though my keyboard had a Windows keyboard layout.
It’s not the simplest thing to set up, because Karabiner Elements requires writing a json file to specify advanced keyboard mappings that involve more than one key, or involve certain conditions like which application is in the foreground. But I can at least share with you the remapping file I created: https://pastebin.com/UHmncMMM
Perhaps with a combination of that and Karabiner Element’s documentation you could figure out how to make your own custom remapping to get keys working the way you want when controlling your Windows system.
Also, I do hope that NoMachine has a keyboard mapping feature soon. That would be extraordinarily useful for a lot of use cases, most of all those of us connecting to Windows systems via macs or vise versa.