I want to make use of a webservice that offers WebRTC for inbound calls. I log in onto the service with my browser, which redirects the call to my headphone. However, I need to bypass the firewall over here. This firewall only allows outbound traffic on 80 and 443.
Therefore, I figured out to use a proxy, namely a Socks5 tunnel (Putty --> SSH tunnel with dynamic port forwarding), to enable WebRTC. This does not work. I guess this is because WebRTC uses UDP, or that the inbound traffic on the remote end of the tunnel is not forwarded to my local pc.
So, my question is the following:
How can I set up a tunnel that supports WebRTC? My preference would be to use a standard SSH tunnel, because that's what I already have.
However, when that is not possible, I would love to know other possibilities to bypass the restrictive firewall to enable WebRTC.
Thanks
You could use a TURN server Secure (TURNS) hosted on the Internet. It will relay your WebRTC flows over a TLS layer. Your server has to listen on port 443.
Related
If I am building a WebRTC app and using a Selective Forwarding Unit media server, does this mean that I will have no need for STUN / TURN servers?
From what I understand, STUN servers are used for clients to discover their public IP / port, and TURN servers are used to relay data between clients when they are unable to connect directly to each other via STUN.
My question is, if I deploy my SFU media server with a public address, does this eliminate the need for STUN and TURN servers? Since data will always be relayed through the SFU and the clients / peers will never actually talk to each other directly?
However, I noticed that the installation guide for Kurento (a popular media server with SFU functionality) contains a section about configuring STUN or TURN servers. Why would STUN or TURN servers be necessary?
You should still use a TURN server when running an SFU. To understand diving into ICE a little bit will help. All SFUs work a little differently, but this is true for most.
For each PeerConnection the SFU will listen on a random UDP (and sometimes TCP port)
This IP/Port combination is giving to each peer who then attempts to contact the SFU.
The SFU then checks the incoming packets if they contain a valid hash (determined by upwd). This ensures there is no attacker connecting to this port.
A TURN server works by
Provides a single allocation port that peers can connect to. You can use UDP, DTLS, TCP or TLS. You need a valid username/password.
Once authenticated you send packets via this connection and the TURN server relays them for you.
The TURN server will then listen on a random port so that others can then send stuff back to the Peer.
So a TURN server has a few nice things that an SFU doesn't
You only have to listen on a single public port. If you are communicating with a service not on the internet you can just have your clients only connect to the allocation
You can also make your service available via UDP, DTLS, TCP and TLS. Most ICE implementations only support UDP.
These two factors are really important in government/hospital situations. You have networks that only allow TLS traffic over port 443. So a TURN server is your only solution (you run your allocation on TLS 443)
So you need to design your system to your needs. But IMO you should always run a well configured TURN server in real world environments.
will I need STUN/TRUN-Servers, if the devices running my WebRTC-application are in a corporate VPN, or can I expect it to just work like in LAN?
I am using the PeerJS library and the PeerServerCloud for Signaling.
if both( or all) peers are behind the corporate VPN network, then probably not. In most other cases, you would most definitely need a TURN Server,
also, if your network blocks/ restricts the 443 port to internet, you would need to connect with the TURN server through TCP transport instead of the usual UDP.
I have developed a p2p video chat using Webrtc. I am aware that STUN or TURN server is required to identify the public IP behind NAT. Currently am using Google's STUN server.
I have the application installed in the server connected to the LAN which will not have internet access, do I need to install the STUN server in my server to make Webrtc video chat work within the LAN?
Peers should be able to connect within a LAN (on the same side of a NAT) without STUN, i.e. using the host candidates. Try it out!
In general, you won't need a STUN server. However, depending on the firewall configuration, you may actually need STUN (and even TURN). For example, at the SFHTML5 WebRTC Hackathon, we were on a corporate guest WiFi network that blocked local UDP and TCP traffic. Making successful calls required a TURN server in this case.
I created a vb .net app and basically it connects to the server (my brother's computer at his house) and sends messages. The problem I'm having is, we both have routers. The only way I'v gotten all of this to work, is by both of us connecting ppeo broadband and then our ips work, otherwise the "real ip" is used for all the pcs in my house. How can I connect tcp to him wothout him having to connect broadband. Because to connect broadband he needs to be connected to an ethernet port, so then he cannot be wireless.
Thanks
I don't know what you mean by "connect broadband", but if the computers are not on the same local network, and you have a NAT router in between, you will either have to connect them via a VPN (like Hamachi for example) or configure port forwarding on both sides on the routers.
See: How do you get Java sockets working with public IPs?
Some routers also have "Dynamic Port Forwarding", where if you are using, say port 8084 for your traffic, both your and your brother set your routers to dynamic port forward port 8084.
The router then listens for client computers connecting across port 8084, and when it sees that traffic, it will route traffic across that port to the client computer that first requested it.
Another popular "NAT-traversal" technology is UPnP. See this SO question and associated article for more information on how to use .NET to control UPnP. Again, router hardware must support it and be configured to use UPnP.
Edit: Untested, but you could try also to use and IPv6 tunneling software such as the one from go6 to create a public IP. This is like VPN, but one-sided, and less private.
Rather than router configuration, you could use a VPN. Hamachi is free and easy.
I need a Reverse Proxy to front both Lablz Web server and SSL VPN Adito (SSL Explorer fork) by sitting on one IP/port. Failed to achieve that with Nginx. Failed to use Adito as a generic reverse HTTP proxy.
Can HAProxy fall back to being a TCP proxy if it does not sense HTTP traffic?
In other words can it fall back to Layer 4 if its Layer 7 inspection determines this is not HTTP traffic?
Here is my setup
EC2 machine with one public IP (Elastic IP).
Only one port is open - 443.
Stunnel is sitting on 443 and is passing traffic to HAProxy (I do not like to use Stunnel but HAProxy does not have full support for SSL yet, unlike Nginx).
HAProxy must be configured to pass some HTTP traffic to one server (Apache server which fronts the SVN server) and the rest of the HTTP traffic to our Lablz Web/App server.
All non-HTTP traffic must be forwarded to Adito VPN.
This traffic is:
VNC, NX, SMB
... and all other protocols that Adito supports
I can not rely on source IP address or port to split traffic into HTTP and non-HTTP.
So, can such config be accomplished in HAProxy? Can any other reverse proxy be used for this? Let me know if I am not thinking right about HAProxy and an alternative approach is possible.
BTW, Adito SSL VPN is amazing and if this setup works we will be able to provide Lablz developers with a fantastic one-click single-login secure VNC-over-HTTPS access to their boxes in the cloud.
No solution exists for this but via Adito - please prove me wrong. But please do not say that VNC over SSH is better. Yes, VNC-over-SSH is faster, more secure, but also is much harder (for our target user base) to setup and presumes that user is behind the firewall that allows outbound traffic on port 22 (not always the case).
Besides, Adito is much more than the remote access gateway - it is a full blown in-browser VPN, a software distribution platform and more. I am not associated with Adito guys - see my Adito post on our Lablz blog.
OK, first off, I'd use a simple firewall to divide all HTTP from NON-HTTP traffic. What you need is packet inspection to figure out what it is that is coming in.
Neither haproxy or nginx can do that. They are both made for web traffic and I don't see how they could inspect traffic to guess what it is that they are dealing with.
Update: Looked into this it a bit and with iptables you could probably use string matching to devide the traffic. However, that's all tricky, especially with the encrypted nature. A friend of mine discovered l7-filter and this looks like what you need. Let me know if this helps.