itguy92075

[itguy92075]

Looks like I need some help with webplayer floating windows.  I have these options in my test .nxs file:

<option key="Command line" value="/usr/bin/startwm.sh" />

<option key="Custom Unix Desktop" value="application" />

<option key="Desktop" value="console" />

<option key="Enable session auto-resize" value="true" />

<option key="Resize the remote screen to the local geometry" value="false" />

<option key="Session resize mode" value="viewport" />

<option key="Session" value="unix" />

<option key="Virtual desktop" value="false" />

The page comes up correctly with all the settings I want, but in a browser tab versus in a detached window.  What did I miss?

Thanks.

[itguy92075]

Hi Shoti,

So far I have had great results with 6.7.6 and found no issues at all.

Thanks for all your support!

[itguy92075]

Hi Shoti,

I got the local STUN server working while testing the 6.7.6 release.  In this section:

Section “STUN”

Host      127.0.0.1

Port      3478

EndSection

 

I changed 127.0.0.1 to the instance’s public address.

[itguy92075]

Sorry, I’m afraid this doesn’t work either.  The STUN/TURN config is commented out of server.cfg, and I get:

The WebRTC peer-to-peer communication cannot be established. If the remote machine doesn't have a public IP, 
please consider to configure your server to use STUN/TURN servers for NAT traversal.

I’m working in AWS which is of course NAT all the way.

To recap, these are my observations:

6.5.6: local STUN server working, remote STUN server working, no STUN server failing

6.6.8: local STUN server failing, remote STUN server working, no STUN server failing

 

 

[itguy92075]

Hi Shoti,

I consider this issue unsolved.  6.5.6 works with a local or remote STUN server, 6.6.8 works only with a remote STUN server.  Why is that?

Thanks.

[itguy92075]

Hi Shoti,

I redeployed 6.6.8 and found the following:

With the STUN server’s host set to 127.0.0.1, neither Firefox nor Chrome work.  Changing the IP address to eth0’s address made no difference — neither browser worked.

Commenting out the local STUN server and opting to use Google’s STUN server works for both Firefox and Chrome.

 

[itguy92075]

Hi Shoti,

I will retest and post the results.

[itguy92075]

Hi Shoti,

I’ve done both of those; the terminal server is its own STUN server, and it works well when nxserver is version 6.5.6.  I upgraded to 6.6.8, changed nothing else, and now WebRTC fails.  Nothing in the logs hints at what might be going wrong.

[itguy92075]

That was the trouble.  I changed the configs on the nodes, not the main server.  Thanks!

[itguy92075]

Hello,

I followed the link to the instructions and saw this:

Step 1 – Point your browser to the webplayer application and run it in debug mode:
https://server:port/nxwebplayer?logging=start

This might be the disconnect. I’m not using nxwebplayer — I’m using Firefox. I’ll try nxwebplayer.

Thanks!

[itguy92075]

Hello,

I saw that link earlier and confirmed NoMachine processes can access the controls.

As far as other audio sources, I was able to hear sound during a webinar earlier in the day.

Thanks.

[itguy92075]

Hello,

I believe I found the issue, and it comes down to this rule:

UDP 49152-65535 0.0.0.0/0

When I removed this rule, no connection failures, so I ran this command to find the random UDP port associated with connections:

# netstat -nap | grep nxnode.bin | grep ^udp
udp        0      0 10.72.4.223:50187       0.0.0.0:*                           31680/nxnode.bin

again:

# netstat -nap | grep nxnode.bin | grep ^udp
udp        0      0 10.72.4.223:60889       0.0.0.0:*                           31680/nxnode.bin

The random port is often below the range specified in the UDP rule:

# netstat -nap | grep nxnode.bin | grep ^udp
udp        0      0 10.72.4.223:43287       0.0.0.0:*                           31680/nxnode.bin

again:

# netstat -nap | grep nxnode.bin | grep ^udp
udp        0      0 10.72.4.223:47949       0.0.0.0:*                           31680/nxnode.bin

The lowest port I saw chosen is 35095.  After changing the rule’s low-end port from 49152 to 35000 I have not had a connection error.

[itguy92075]

Hello,

The rules I posted are all inbound.  The security group gives unrestricted access outbound.  Still, with these rules in place, I get connection failures in about half the attempts.

[itguy92075]

Thanks for your reply.  It appears you’re right about the security_group.  When I allow everything in, connections seem to never fail.  When I apply the rules I found online, connections often fail.  Here’s what I have, derived from this page: https://www.nomachine.com/DT06O00143

Proto, Port, Source

TCP 80 0.0.0.0/0
TCP 443 0.0.0.0/0
TCP 3478 0.0.0.0/0
UDP 3478 0.0.0.0/0
TCP 4000 0.0.0.0/0
UDP 4011-4999 0.0.0.0/0
TCP 4080 0.0.0.0/0
TCP 4443 0.0.0.0/0
TCP 4840 0.0.0.0/0
TCP 5041-5051 0.0.0.0/0
TCP 5349 0.0.0.0/0
UDP 5349 0.0.0.0/0
TCP 5473 0.0.0.0/0
TCP 5483 0.0.0.0/0
TCP 7001-7011 0.0.0.0/0
TCP 20000-30000 0.0.0.0/0
UDP 49152-65535 0.0.0.0/0

[itguy92075]

Hello,

I followed your suggestion to put the key into to the .nx\cofig folder.  At that point, I still could not connect, the error was “Cannot accept key.”

Using the client interface, I reimported the key into my session file, this time using .nx\config\nx_client_rsa_key instead of Downloads\nx_client_rsa_key which I had done previously.  This is the working formula — I am able to connect with the keys, no password.

All is well, thanks for your help!

 

[Author]

Posts