P2P between public IP peer and one behind symmetric NAT without TURN

[V I]

Good day everyone,

I have this setup with one peer (sender, libwebrtc-based CLI app) sitting on an EC2 instance with a public IP and another one is a regular desktop/laptop behind a NAT (receiver, browser-based, i.e. JS).

It works fine if the receiver is behind a "normal" NAT, but fails 100% when tethering through an iPhone (verified that it's a symmetric NAT, not UDP block). Coturn running on one more EC2 instance (right next to the sender, the same subnet) resolves the issue, but raises the question why I can't connect to the sender directly as its network situation is identical to Coturn's.

Moreover, I can write a C app listening on a socket on the sender instance with a peer connecting to it on the receiver side - they'll be sending data back and forth over UDP in 10-15 min. No STUN, ICE or TURN needed in any shape or form.

The question is can I circumvent all that unnecessary and rather flaky complexity of NAT hole punching and TURN and just generate my own ICE candidate pointing to the public IP and port of the sender? And configure the sender that it doesn't do any ICE, just listen on a particular port?

TIA

[shakeeb nazmus]

Hi.

You want to connect two clients. One has  public IP address and another one is behind NAT.

In this case you really don't need any STUN, TURN or ICE. You can simply write a c app to send receive. Even if you are using browser, you don't need WebRTC library, you can just use Websocket to send receive.       

Even if one client has public IP it is not a matter what the NAT type of other client. It may be symmetric NAT or anything.

>>The question is can I circumvent all that unnecessary and rather flaky complexity of NAT hole punching and TURN and just generate my own ICE candidate pointing to the public IP and port of the sender? And configure the sender that it doesn't do any ICE, just listen on >>a particular port?

Why not. You can do it. As you are developing the app, you can change in the app code and in the library and do it.     

 
The main issue here, you are using EC2 instance with public IP address which is not a real public IP address. It is a NATed public IP address. Coturn needs some specific configuration to work with it and Client must use STUN server to discover it external IP address.

But certainly no TURN server is required here.

Thanks,

Shakeeb

[V I]

Hi Shakeeb,

Thanks for your reply.

I'm definitely not going to rewrite WebRTC from scratch to replace it with my own implementation based on ws.

EC2's public IPs work as advertised as long as you click the checkbox you need a public IP. There's absolutely no need for STUN or any sort of discovery process for "real public IP address". It doesn't matter if there's a NAT in between as long as the mapping is right and consistent (it is)

--
This list falls under the WebRTC Code of Conduct - https://webrtc.org/support/code-of-conduct.
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/7b0af8d9-75d0-49c3-b61e-8b7699004fcfn%40googlegroups.com.

[shakeeb nazmus]

>> EC2's public IPs work as advertised as long as you click the checkbox you need a public IP. There's absolutely no need for STUN or any sort of discovery process for "real public IP address". It doesn't matter if there's a NAT in between as long as the mapping is right and consistent (it is)

It is true that NATed public IP and real public IP are same in the most of the cases but not always.    

Some application like TURN server or Webrtc Client discovers its IP address from the interface address and send others by signaling. for them NATed public IP and real public are not same as they can not discover it from interface address. They need some way to discover it. 

Thanks,

Shakeeb

[Harald Alvestrand]

Symmetric NAT is hell-on-wheels for getting peer-to-peer connections working, for the reasons described in RFC 3489.

If you have symmetric NAT, your best bet is to use a TURN server.

(It SHOULD work if the sender has a public IP. But I guess this is EC2 magic.

Turning off STUN/ICE in WebRTC is not possible - there are multiple reasons for it being there, hole-punching is just one of them.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/2f6190a4-fe4c-4699-be32-5b35d2b0f73en%40googlegroups.com.

[Pavel Punsky]

If it works through coturn but does not work directly with the EC2 app then my bet is that there is something with your EC2 app that is not working correctly.

For example, it does not generate a candidate that can be used to create a p2p connection (ec2 addresses can be confusing - I do not know if libwebrtc can be trusted to correctly generate list of candidates when it runs on EC2 instance)

Is your app (as in JS app) the initiator? Since your EC2 app has public IP you could use ice-lite and only send candidates to EC2 app.

But I agree with your sentiment - no reason why it would not work. I ran webrtc SFUs on EC2 instances with public IP for years.