Intel Unite Enterprise solution work on UDP or TCP?

[idata]

Hello

I don't know where Unite used TCP or UDP for the connection and packages transport method? Unite have some rules?

Is it possible to set Unite communicating over UDP or TCP and ports?

Thank you.

Tomas

[idata]

Thank you very much for contacting the Intel Communities Team, Thomas77. I will be more than happy to assist you.

Allow me to share with you that the Intel Unite® app will use TCP on Mac OS* and, UDP on Windows* OS.Please refer to the Intel Unite® Deployment Guide: https://www.intel.com/content/www/us/en/support/articles/000008523/software/software-applications.html https://www.intel.com/content/www/us/en/support/articles/000008523/software/software-applications.htmlAntony S.

[idata]

Hello Antony,

Okay, Win used UDP and MAc OS TCP, and Why my Win10 1803 client connecting to HUB by TCP?

Is it possible to define ports? What is the range of ports?

I read Intel Unite deployment guide, but communication scheme is insufficient.

Thank you

Tomas

[idata]

Thank you for your reply, Thomas77.

Allow me to perform a deeper research into this to provide you with the information you are looking for. I will be back to you as soon as I have an update.Antony S.

[idata]

Thank you for your patience, Thomas77.

I would like to make a correction to my previous post: Intel Unite® app works using only TCP. It will work using this protocol with either, Mac OS or Windows*.I am aware that the Deployment Guide is not very specific, though, this is the protocol that is used in order to create the DNS Service Record. In addition, The app does not connect to auto-discovery mode as shown in the following:By default, the app will use DNS Auto-Discovery (e.g. DNS SRV records) to determine the proper Enterprise Server to connect to. The overall workflow is as follows:

*(Optional) Enterprise Server as defined in preferences

*Auto Discovery to the following domains:

> _uniteservice._tcp

> _uniteservice._tcp.yourSubDomain.yourDomain.yourTLD

i. Example: _uniteservice._tcp.http://corp.acme.com/ corp.test.com

>_uniteservice._tcp.yourDomain.yourTLD

i. Example: _uniteservice._tcp.test.com

>Attempt connection to HTTPS followed by HTTP if failurePlease refer to the pages 62 (11.2), 67 (12.4.2), 79, 82, 83 and 84 of the Intel Unite® Deployment Guide: https://www.intel.com/content/www/us/en/support/articles/000008523/software/software-applications.html https://www.intel.com/content/www/us/en/support/articles/000008523/software/software-applications.htmlAntony S.

[idata]

Hello, Thomas77.

I would like to know if you have any additional question. If so, please do not hesitate to reply to this thread.Antony S.

[idata]

Hello Antony,

Do you know what range of ports use? I track by WireShark, and i spooted range 50000 to 65656. I must know exactly, because my security department don't like it open wide ranges TCP ports.

Thank you.

Tomas P.

[idata]

Hello, Thomas77. Thank you for your response.

Allow me to investigate into this question you have. Once I have an update I will let you know.Antony S.

[idata]

Unite starts the handshake with UDP then all of the content is transported by TCP using random ports.

[BJame2]

Is there a solution to someone who does not want to open up a range of 20,000 or so ports on the network?

[BJame2]

Did you find a solution to this problem?

I am having the same issue where Infrastructure dept does not want to open up 20,000+ ports on the network...

Seems as though you should be able to specify this in a config file to only communicate across certain ports.

I see the same as you communication after handshake talks on ports ranging from upper 40,000 to lower 60,000 range

[PPric2]

bryanjames70

You can lock the TCP port used for the initial connection and commands by setting the service listen port in the device profile, but the A/V streaming (present desktop in Windows) does not use that port. If you disable A/V streaming support and set the service port, then Unite app appears to only use a single TCP port that you set - however it's a pretty ordinary experience.

Depending on your network firewall and infrastructure, there are a couple of options which may be possible - internally, A/V Streaming mode uses an encrypted WebRTC socket for transmission which is what handles setup and teardown of the connections (including protocol and port allocation - which is why it is not possible to lock down the ports used).

An interesting side effect of using WebRTC is that it was really designed for communication between web browsers, which may be behind restrictive firewalls and NAT. So part of the mechanism uses STUN to determine the lines of communication. A stateful, layer 7 firewall could theoretically witness the STUN handshake between client and server and temporarily open up lines of communication between client and hub for the duration of the session.

The other, simpler method would be to VLAN your hubs with a basic firewall. For example, set the service listen port to 30000 and allow (inbound to the Hub VLAN):

TCP port 30000

UDP ports 1025-65535 (i.e. all non-privileged ports)

Any ports required by plugins

You could theoretically restrict the UDP ports to the 20,000 mentioned earlier, but the operating system (in this case, Windows) is ultimately responsible for selecting the ports to use and may pick one outside that range.

Good luck