I have implemented WebRTC and things work well, but there is something I am not sure I understand. From my reading, I thought that when a peer is behind a symmetric NAT, a TURN server is mandatory.
I have tested this situation :
peerA is behind a normal NAT (confirmed via https://tomchen.github.io/symmetric-nat-test/)
peerB is behind a symmetric NAT. (confirmed via https://tomchen.github.io/symmetric-nat-test/)
The peer connection instance is only using a STUN server
WebRTC direct connection between peerA and peerB is working!
So, my question : Is it possible to have direct connection between a peer behind a normal NAT and other peer behind a symmetric NAT with STUN?
My test tells me yes but :
Can I trust the result of (https://tomchen.github.io/symmetric-nat-test/). Maybe the information is incorrect?
Thank you
Related
I am using this example https://github.com/libp2p/js-libp2p/tree/master/examples/libp2p-in-the-browser and try to connect to a nodejs peer through the given hosted rendezserver ‘/dns4/wrtc-star2.sjc.dwebops.pub/tcp/443/wss/p2p-webrtc-star’ . The peer get found but the connection is not established. If i run the nodejs peer in the same machine as the browser peer they get connected but if the nodejs peer is on a different machine/network the peers find each other but they don’t get connected. Is this normal ?
Yes that's totally normal. WebRTC will only work if you can get through the NAT. IPv6 really helps with NAT traversal too, but it can be trickier with IPv4. So it will work over more than locally, but each peer must be able to directly reach each-other.
https://docs.ipfs.io/how-to/create-simple-chat-app/
We can use WebRTC-Star nodes to help discover other peers we can connect with directly browser-to-browser. If you're familiar with the concept of STUN, it might be helpful to think of them as conceptually similar. Effectively, each connecting node will be given a WebRTC-Star multiaddress that other nodes can use to discover and connect to your browser directly. This means that if you peer with someone using the star node, and the star node goes offline, you remain connected!
[...]
Tip
This is a very clean and effective method of P2P communications; however, sometimes NATs get in the way. We use p2p-circuit to get around that.
Suppose, we have a media server S deployed. We have a client C who is behind a symmetric NAT. The direct WebRTC media streaming is not possible due to symmetric NAT. So we want to deploy a TURN server T, which would relay all media between S and C.
Now, it seems that developers sometime deploy T near S for simplicity. But does it help to stream media between C and S? "Near" means "in the same network", so S and T are behind the same NAT if there is some. Since, they are behind the same NAT, it doesn't seem to improve connectivity: chances to stream WebRTC traffic between S and C are the same as between T and C.
Is this reasoning correct or am I missing something? In my current understanding, TURN servers act like a proxy with better connectivity with respect to C. So they should be placed in another network to make any effect.
C -> T can do a few things that C -> S can't do
DTLS and TLS transport, ICE only allows UDP and TCP. Some gateways only allow TLS on 443
Single port, you can do all traffic on one well know port. Gateway may only allow :443
S may not support ICE-TCP. Some SFUs do support it though!
In my case, I have a webrct based web app that supports multi-parti video chat and has STUN and TURN servers configured. The connections are done in a mesh way (peer to peer) What happens when some of the users involved in the video chat need to establish the connection via TURN? Do all of the users start to use TURN? What if I'm the user that's behind a NAT? Does that mean that all connections established with me are using TURN?
Connections are peer to peer, so if one connection uses TURN then it doesn't affect other peer to peer connections.
If the user is behind a NAT, he may not need TURN in some cases: all depends on the type of the NAT.
i have a problem. I've developed a web-app using WebRtc for one-to-one videocall via browser using WebRtc with signalling server on node js (listening e.g. on 8181 port).
Now i would implement MITM attack. I was thinking that, wheen Peer_1 should invoke two rtc peer connection, one for the second peer (Peer_2), one to the MITM. The same thing for the second peer.
Now, i was thinking that signalling server needs to listen on another port, for each rtc peer connection received from the two peers (e.g. 8282 for Peer_1 and 8383 for Peer_2).
Am i right? I think that because signalling server's implementation is to one-to-one communication.
In this way, signalling server on port 8181 allows end-to-end communication for Peer_1 and Peer_2, on 8282 there is the signalling path for Peer_1 and the MITM, and on 8383 for MITM and Peer_2.
Am i right or not? Thanks for the support.
Man in the middle refers to interception during transmission, which WebRTC itself is secured against using DTLS and key exchange, so the weak point is usually the signaling server chosen by an application instead.
But what you describe however sounds like Man on both ends. You have to trust the service (the server) to guarantee whom you're being connected to. If that server is compromised, or either client is compromised - say by injection - then there's no guarantee whom you're talking to, since a client can easily forward a transmission to another party.
I am writing a WebRTC application and although everything works fine inside my LAN. However, I have an ICE Failed error when peers are on different networks.
My STUN server returns public IP candidates so I assume it is set up correctly. The problem is that the candidate IPs are not "paired correctly". The browser always tries to connect one public IP with one private IP so the connection fails (See Candidate Pairs).
What could be the problem here? the signaling server or the rtcpeerconnection configuration?
Using only local host and server-reflexive candidate you can only connect if your NAT allows incoming packets from other peer, usually NAT doesn't allow incoming packets from a source which is unknown to the NAT. You can do a NAT discovery outside of your WebRTC implementation following the RFC-3489 (obsolete though, but still helpful) or just create NAT binding without knowing the NAT type which will work if you are behind port-restricted cone or full-cone NAT types. The easy solution to connect using WebRTC would be using a TURN server to have Relay candidate if you don't want to do NAT discovery and apply some intelligence to traverse the NAT.