1

ICE Connection fails when we have a Load Balancer and more than 1 VM behind the load balancer. On reading through the logs we found that the Binding requests from two peers go to different VMs behind the LB, if both the peers are directed to the same VM by LB, ICE connection succeeds and communication channel establishes.

Does this mean that we need to make sure both the peers send Binding requests to same TURN server? Does ICE framework expects that there should be same TURN server for communicating peers?

Can we not have multiple TURN servers - which enables peers to communicate? Does the candidate pairing not happen with different TURN servers for two communicating peers?

Looking for your valuable inputs.

msk
  • 101
  • 1
  • 10
  • Do the VMs have an actual public internet IP? Both peers can allocate ports on different TURN servers, but if that IP:port pair coming back is the public IP of the LB instead of the VM, there can be problems. – selbie Apr 29 '20 at 00:47
  • yes the VMs have the public ip but are not expose directly to peers. It is the load balancer public - DNS which is being used by the peers(clients), – msk Apr 30 '20 at 04:17
  • Right, so the clients make a TURN allocation request to the public IP of the load balancer. When the allocation request comes back, does it contain the IP address of the LB or the VM? If you are configuring the VM to return a port allocation using the LB's IP address, that's the issue. I'm happy to elaborate and I may not know everything about your config. – selbie Apr 30 '20 at 07:15
  • It comes back with the IP of LB. I could see that in the wireshark. The source and destination matches with the LB's IP for respective Requests. – msk Apr 30 '20 at 17:37
  • I suspect you need to configure the TURN server running on the VM to return it's actual public IP. Otherwise, when the peer connection attempts to negotiate ICE and do connectivity checks, it only has a marginal chance of arriving on the same TURN server as the peer intended. – selbie Apr 30 '20 at 17:42
  • I've had people contact me about running STUN behind a load balancer. And they are surprised to see that the STUN server returns the IP address of the load balancer to the client instead of the client's public IP. I suspect that might be happening as well with your TURN configuration. In any case, the better solution is use round-robin DNS instead of a load balancer if possible. – selbie Apr 30 '20 at 17:46
  • Ah! the success rate for STUN case is much higher for the same LB scenario, but TURN fails when both client requests dont go to same VM. ICE negoitation fails. The one VM behind LB case works again! For round-robin DNS you mean TURN server has any default configuration? Or an external DNS based Load balancer like TM of azure? – msk Apr 30 '20 at 18:10

0 Answers0