I currently have the following network setup and would like to be able to make WebRTC calls between the two clients in different networks.
I enabled IPv4 forwarding on the openSuse Leap 15.2 server and both devices have either 192.168.2.1 or 192.168.4.1 as their default gateway. The web application as well as the signaling service are both hosted on this server as well.
With the Firewall disabled the call works as suspected, but with the Firewall on the call no longer works. I thought about hosting a Coturn STUN/TURN server on this server, as I've read that you should provision one, if you run into troubles with a firewall.
Is a setup like this doable with lets say Coturn and what would the configuration look like for a scenario like this?
I ended up solving it as I describe in my GitHub issue for this matter.
Related
I have a set up I would like to implement but just not sure on the details. As you can see in the image below I have a single VPS in the web which I would like to use as a gateway to a number of locally running web servers. Im using the VPN to hide the IP/location of the server farm while maintaining the ability to host locally.
What I am not sure on is the implementation as I have never used a VPN before. My understanding is that I can host the VPN server on the server farm, have the VPS connect to it which will give me another 'local' network interface which I can then use apache to proxy traffic through?
The server farm is basically a small Kubernetes cluster give or take a little.
Is my understanding correct and can you offer any advice on implementaion?
Thanks in advance!
server farm example image
The VPN server should have two network interfaces. The first is the public interface that connects to the Internet and the second is the local interface that connects to the server farm. All the servers in the farm should connect only to the local interface and have the gateway set as the VPN server.
You can use the Reverse Proxy functionality in Apache to route incoming traffic to the appropriate server. See Reverse Proxy Guide
I have developed a WebRTC based application along with Kurento-Media-Server.
Problems with this application is:
It works but only on open network (i.e. if run on a network without firewall).
When in firewall it runs sometimes (once out of 10 attempts).
I have tried several things with the firewall, I have disabled all kind of incoming/outgoing traffic. I have created a port-forwarding for my application as well as Kurento-media server.
I am not sure how much useful this information might be but I am deploying my
application on the same physical box along with Kurento-Media-Server. I have configured google's STUN server on my client.js, I have also configured same STUN servers on kurento using code. I haven't configured TURN server.
Just confirming this, signaling server can be behind firewall along with rest of the application, correct?
I am not sure what to look for now, any help in this area would be great.
EDIT-1
From this link I learned that my current network on which my isn't working it has issues with plain websocket connection, it doesn't allow it, it only allows secure Websocket connections.
EDIT-2
Image of netscan:
In my phone network where my app works fine I see all greens in Websocket's "plain" column.
EDIT-3 Solved
Finally found the problem, We were using a router for testing and development and I found that the router had issues, I used LAN cable on the same router and everything worked fine. Calls from application were working just fine. Firewall related details help in configuring the firewall later on.
Based on your problem description it seems all the UDP traffic is not open in your firewall. WebRTC media run on UDP ports.As you mentioned it works one out of 10 times whch means only few UDP ports are open in your firewall.You are lucky when traffic comes via tose ports.You can open port-range in your firewall and configure the same in kurento-media-server config.Your job should be done.
Even if you configure TURN server you need to open certain ports for outgoing and incoming UDP traffic.For TURN server default port is 3478 or 8443 for sending data towards it but for incoming traffic you need to configure port-range on your TURN server and open those ports in your firewall. Always remember TURN server is assured way to connect but it's always costly.
Is it possible (or any hack) to configure multiple stun/turn servers on the WebRtcEndpoint.conf.ini or through our signaling servers? So that if one stun fails it falls back to another? If the feature is not available what would be the closest solution?
I am not sure if I am looking into the right location - I've seen that WebRtcEndpoint has methods for- getStunServerPort()/getStunServerAddress(). So a possible client side configuration?
Reason - We've been using kurento media server (6.0) and elasticRTC 6.5 (For the future development) on an AWS vpc. It was working fine by using one of the publicly available STUN servers. Suddenly it stopped working and we figured out the STUN server was not working anymore. So we switched to Google stun and it started working normally
I would suggest, instead of using a globally configured IP in WebRtcEndpoint.conf.ini, to use the methods that you mention in the WebRtcEndpoint. That way, you can use a CNAME and resolve the IP every now and then. You might have a separate scheduled task that checks the STUN server to see if it's still available, and then refresh it when it is no longer valid.
I want to implement a restund server for WebRTC audio on my website. I wish to have one user be able to talk to all the other users on the platform (if anyone knows an easier way to do this than implementing a restund WebRTC server, please let me know, would help me out a lot).
But before I go and try to get restund working, I was wondering if it could be installed to work alongside my Apache HTTP dedicated server I use to host my website.
Well, STUN/TURN services are running on ports 3478 and 5349 by default. That should not conflict with those required for HTTP operations (e.g. 80, 443, 8080). So yes, this should be possible.
So, we all use TeamViewer for accessing GUI based (Windows / Linux) remotely and of course, it works really well.
Any ideas of how to do the same with headless (Ubuntu) servers? I'm thinking that the headless servers would run some sort of service that connects to a central server, which I can then remote into (somehow) and then route through the central server to the remote server.
It's kinda like the server based TightVNC that was popular a view years ago, where you could host the "server" module and have all your TightVNC clients connect to that server, whilst you do the same on your client, and the server module provides a gateway through to the remote systems. Just like TeamViewer really.
I wonder if the remote servers can connect to the (central) gateway server via SSH, I would do the same (again via SSH) but then the gateway server will provide me a "tunnel" through to the remote server.
I would of course prefer to have the remote servers have SSH ports opened through their firewall and then connect to them directly, but sometimes their IT teams don't like that. Having a server that runs a service, connects to a public server, means that the IT team will typically permit this, as the traffic is initiated internally and would be even more so agreeable to permitting it if that traffic uses an encrypted protocol.
Anyway - I just wondered if there was something out there that I could have a look at and see if it would work??
If you don't want a cloud controlled service (with serious security issues as of late), then check out the self-hostable MeshCentral project. It creates outbound tunnels that allow devices to communicate behind NAT and other networks.
Good news! Teamviewer 11 supports headless Linux servers :)
https://www.teamviewer.com/en/help/1111-How-do-I-install-TeamViewer-on-a-Linux-system-with-no-graphical-user-interface
Try https://www.dwservice.net/en/
Works on RPI, Linux and Windows.Best Part is free and Support for Terminal access
not just GUI ( so works faster in slower internet ) .
Client side- > just run the script ( not need of GUI)
Remote side - > Run just browser.