Forum / NoMachine Terminal Server Products / WebRTC on Version 6.6.8
- This topic has 13 replies, 2 voices, and was last updated 4 years ago by itguy92075.
April 10, 2019 at 07:49 #21991
I’m trying NoMachine Enterprise Terminal Server Evaluation – Version 6.6.8 and getting an error message.
# /etc/NX/nxserver –version
NoMachine Enterprise Terminal Server Evaluation – Version 6.6.8
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.
The previous version works well:
# /etc/NX/nxserver –version
NoMachine Enterprise Terminal Server Evaluation – Version 6.5.6
I’m building instances in AWS with Ansible. The only thing different between the working instance and the broken instance is (literally) the version of Enterprise Terminal Server. What can I look at to find a resolution?
Thanks.April 10, 2019 at 13:58 #21998
First of all, can you confirm/re-check that you properly configured STUN/TURN servers in server configuration (server.cfg) file? These two articles may be useful :
How to configure NoMachine servers to use WebRTC – https://www.nomachine.com/AR07N00892
How to setup your own STUN/TURN server for NAT traversal: https://www.nomachine.com/AR07N00894April 10, 2019 at 17:47 #22004
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.April 11, 2019 at 12:12 #22009
Can you check that there are no special chars in a STUN/TURN section? If there aren’t, we would need the logs from the client. Please find the instructions here how to gather web session logs: https://www.nomachine.com/DT10O00163#2.6 You can send them to forum[at]nomachine[dot]com.April 23, 2019 at 13:56 #22108
itguy92075, we found some problems in the Firefox version you have in use (66.0) we are working on it, in meantime can you try Chrome browser and check if the behavior is the same?
Regarding CFG files you sent to us, the only uncommented server was: “Host 127.0.0.1”, this will not work for connections behind the NAT, please use the real STUN/TURN’s (the ones you commented in CFG file should be OK), also note, that you can use several servers, web player will try all servers until it finds the working one.April 25, 2019 at 19:22 #22132
I will retest and post the results.April 27, 2019 at 21:53 #22142
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.May 10, 2019 at 15:00 #22281
itguy92075, we are pleased that the issue has been solved.May 14, 2019 at 07:54 #22311
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.May 14, 2019 at 16:15 #22324
itguy92075, Within the release of 6.6.8, we fixed an issue related to this : “Cannot connect via web from an external network when WebRTC is enabled” (https://www.nomachine.com/TR05P08581). You are seeing a difference because of the fix.
The thing here is that in earlier versions of webplayer (e.g 6.5.6) the STUN/TURN servers were ignored by the browser even if they were correctly presented in the configuration file. In the config file you had the “Host 127.0.0.1” (which is wrong) but in reality the browser was ignoring it anyway. Then, in the new version you used the same config (“Host 127.0.0.1”) and encountered what you thought was a bug.
It happened because it’s not ignored anymore and the config was wrong. It looks like in your particular situation you don’t need any additional STUN/TURN to establish WebRTC connection, removing/commenting any kind of STUN/TURN section in server.cfg file should fix your issues with 6.6.8. Please, try this and share your results.May 21, 2019 at 08:48 #22384
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 failingMay 30, 2019 at 08:04 #22476
I got the local STUN server working while testing the 6.7.6 release. In this section:
I changed 127.0.0.1 to the instance’s public address.May 30, 2019 at 16:54 #22485
Thanks for testing the new version and sharing results here, we appreciate this. So, from what I see, in 6.7.6 all looks OK to you and you get the same results as was in 6.5.6?May 31, 2019 at 08:16 #22498
So far I have had great results with 6.7.6 and found no issues at all.
Thanks for all your support!
This topic was marked as solved, you can't post.