LAN, STUN, and Chrome Remote Desktop

1,112 views
Skip to first unread message

Jason12 C12

unread,
Nov 5, 2021, 2:28:43 PM11/5/21
to Chromium-dev
If my teams are are all behind the same internet router and connecting to each other via Chrome Remote Desktop,, I understand that after STUN has completed, the UDP packets do not traverse the internet, but I have a slightly different question.  

I'm trying to optimize our very much overloaded network.

If the local org network has several subnets (Subnet1, Subnet2...) each of which is connected to a single ParentSubnet via router (or switch) (Router1, Router2...).  And let's say that ParentSubnet is connected to the internet via "SuperRouter".  Let's assume the two ends of the remoting are in the same room using the same subnet (or just the same switch), once the remoting begins, will each of those UDP packets pass to/from that SuperRouter, or can a more direct connection only through RouterX be arranged?  Does this require configuration to select a more local STUN server than the default Google STUN server?   If so, how is that done?

Jamie Walch

unread,
Nov 5, 2021, 3:33:35 PM11/5/21
to jason.c...@merlyn.org, Chromium-dev
ICE is the protocol CRD (and any WebRTC-based application) uses to establish a connection. I haven't read it in detail, but https://anyconnect.com/stun-turn-ice/ seems to be a decent summary.

For CRD specifically, you can check the "Stats for Nerds" panel to see what sort of connection you have:
  • direct means that the endpoints can access one another's private IP addresses and are connected directly, much as you would via SSH.
  • stun means that the endpoints are connected via their public IP addresses, so packets are being routed through the local internet access point, but not through the wider internet.
  • relay means that all packets are traveling over the internet to a central point which then passes them to the other end of the connection.
These are approximately in order of latency. Just because a connection uses one of these modes doesn't guarantee that all subsequent connections between the same endpoints will do so, nor that it will use the same mode for the entire connection (although that's often the case). It depends a lot on your network setup.

It's worth noting that everything is end-to-end encrypted in all three cases.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/fb105938-6d29-4bfb-8da6-4faa40ca0835n%40chromium.org.

Jean-François Geyelin

unread,
Nov 12, 2021, 7:41:12 PM11/12/21
to Chromium-dev, Jamie Walch, Chromium-dev, jason.c...@merlyn.org
Disclaimer: I don't know anything about WebRTC's ICE

I believe that if Router1 or Router2 have hairpinning enabled ( https://en.wikipedia.org/wiki/Hairpinning ), the SuperRouter won't see the packets that are transferred between devices that are in the same subnet.

Jason12 C12

unread,
Nov 15, 2021, 7:53:49 PM11/15/21
to Chromium-dev, Jean-François Geyelin, Jamie Walch, Chromium-dev, Jason12 C12
Thanks Jena-François.   It looks like hair pinning (or loopback NAT) is the term for the situation we would hope to improve upon.   It's good to know there's a term for that.  
Reply all
Reply to author
Forward
0 new messages