Forum / NoMachine Terminal Server Products / Web client in AWS
- This topic has 6 replies, 2 voices, and was last updated 5 years, 10 months ago by Britgirl.
-
AuthorPosts
-
January 22, 2019 at 09:43 #21108itguy92075Participant
Hello,
I’m trying the get the web client going in AWS. The issue is a web user can connect about 1/2 the time, and 1/2 the time the users gets an error message stating WebRTC needs to be configured. If the user tries again, often repeatedly, a connection eventually succeeds.
These are the changes to server.cfg:
AcceptedWebMethods classic,webrtc
Section “STUN”
Host stun1.l.google.com
Port 19302
EndSectionSection “STUN”
Host stun2.l.google.com
Port 19302
EndSectionSection “STUN”
Host stun3.l.google.com
Port 19302
EndSectionSection “STUN”
Host stun4.l.google.com
Port 19302
EndSectionDid I miss anything?
January 22, 2019 at 16:52 #21116BritgirlKeymasterIt looks like a firewall problem. You need to open all ports which could be required by the WebRTC connection. So open traffic for all ports for your specific IP from which you are connecting.
To configure it please edit Security Group rules in the AWS configuration (see section “Configuring the security group” in https://www.nomachine.com/accessing-your-remote-linux-desktop-on-amazon-elastic-compute-cloud-via-NoMachine).
January 23, 2019 at 09:16 #21128itguy92075ParticipantThanks 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/0January 23, 2019 at 13:53 #21133BritgirlKeymasterSomething to remember is that WebRTC uses 80 or 443 for signaling if using websockets or not. 3478 is the default port for communicating with STUN/TURN servers but some might be configured to listen to 19302-19307 (Google’s STUN), 5349 (TLS), 80 or 443. And a WebRTC P2P connection will use random port in range 0-65535 for sending data.
January 24, 2019 at 09:10 #21140itguy92075ParticipantHello,
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.
January 24, 2019 at 19:34 #21156itguy92075ParticipantHello,
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.
January 24, 2019 at 19:37 #21160BritgirlKeymasterYes, that’s right. I was about to reply but you beat me to it 🙂
You need a rule like this
All UDP UDP 0 – 65535 {Client_Public_IP}Attachments:
-
AuthorPosts
This topic was marked as solved, you can't post.