Setting up Kurento in AWS behind a NAT, in front of a load balancer and in a private subnet.

464 views
Skip to first unread message

gl...@skooli.com

unread,
Nov 19, 2015, 2:09:15 PM11/19/15
to kurento
Basically the scenario is this:

1. Kurento is hosted in an instance inside a private subnet.
2. An elastic load balancer lives in the public subnet.
3. A NAT also lives in the public subnet.

Kurento inbound traffic comes from Elastic Load Balancer and outgoing traffic from Kurento go through NAT.

I edited WebRTCEndpoint.ini to include a STUN server but that doesn't work.

I don't understand what can the STUN server do here? The instance does not have a public IP at all. The only way traffic can come in is through the load balancer IP. How in the world can a STUN server find the load balancer's IP?

Ivan Gracia

unread,
Nov 20, 2015, 4:58:44 AM11/20/15
to Kurento Public
If you want to completely close your KMS to the outer world, the only option you have is to route all traffic through a TURN server. Your loadblanacer can only route traffic that goes to the websocket port, but won't be any good for routing media.

Ivan Gracia



--
You received this message because you are subscribed to the Google Groups "kurento" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

gl...@skooli.com

unread,
Nov 20, 2015, 6:47:02 AM11/20/15
to kurento
Can I route all the traffic to the turn server through an internal load balancer? Also how does the outside world connect to a TURN server?

I want everything to be scalable hence the load balancers at every traffic flow. I could have several KMS servers or TURN servers depending on the load.

Ivan Gracia

unread,
Nov 24, 2015, 5:53:59 AM11/24/15
to Kurento Public
The best thing is to make TURN and KMS open for access from the outside world. I'm afraid you'll have develop a piece of software that does the load balancing, sending clients to new KMS servers if one falls, rebuilding the pipeline. Keep in mind that the SDP negotiation involves the exchange of candidates, and that those candidates have the IPs of the KMS. Another option is to mangle the SDPs, and change the internal private IPs for public IPs of your loadbalancer, but you still need to keep track of which publicIP:port is mapped to which privateIP:port.

Ivan Gracia


Reply all
Reply to author
Forward
0 new messages