Just a bit of background first.
I have installed coturn server in my local machine (Behind a firewall and with local IP).
I have created a port forwarding for cotrun server lets say my local ip is: 192.168.0.11:3478 is mapped with my public ip 10.1.10.212:3478.
When I use some online utility to check my public IP has this port open it? that utility shows that it is open.
I am trying to test this server using this fiddle: Code to test TURN server
I removed the stun configuration from it, and added my live ip and port. And when I try to test it, it says your TURN server is broken in console on web browser. And I see failed as output.
I have also used following commands to create a user from this link.
Wiki to Coturn Configuration
// created test user
sudo turnadmin -a -u test -r test -p test
// enabling admin support in web (not sure how to access it in browser)
sudo turnadmin -A -u test -p test
I start the turn server using following command:
turnserver -L 192.168.0.11 -a -f -v -X -r test
I have enabled the "TURNSERVER_ENABLED"
/etc/default/coturn
TURNSERVER_ENABLED=1
Screenshot of my about:webrtc:
Please find the below attached Screen shot for my about:webrtc. I am not sure what is missing.
EDIT-1
I can also see the incoming packet message processed, error 401: Unauthorized in the console of TURN server
EDIT-2
I resolved the TURN server related issue, added the turn server in client code as well, still facing issue, call is not going through,
Update
Here is what I found, the reason why it wasn't working earlier was due to a defective router in the network. This thing has harassed me for almost a month (however the internet used to work fine). But I found that there is a loss of packets and I switch to LAN cable I even avoided the firewall of the organization and there it was working just fine. Then I configured the rules in firewall and it started working as well.
A few issues that might be causing this:
The -X option requires an argument - the external IP if the TURN server is behind a NAT.
If you are setting all your parameters on the command line, you should include -n to ensure that it does not load an unrelated configuration file.
TURNSERVER_ENABLED=1 is to start turnserver with default configuration at system boot. You do not want this if you are starting turnserver manually from the command line.
https://github.com/coturn/coturn/blob/master/README.turnserver
" I have created a port forwarding for CoTurn server lets say my local ip is: 192.168.0.11:3478 is mapped with my public ip 10.1.10.212:3478."
Now surely you are aware that the private address-spaces in IPV4 are (private IP ranges):
10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255
So, your first IP is in the last private IP range, and your so-called "public IP" is in the first private IP-range. Now you need to find your TRUE REAL public-IP address to try to connect to it from outside. I would say that it looks like your ISP has you behind a NAT. So your TURN server might be behind two NATs. Which is kind of ironic situation for a server designed to help penetrate NATs of webRTC-clients. You might want to try to put CoTurn somewhere where it is possible for it to work like AWS (special case of CoTurn friendly NAT).
Just recently got (well with lots of help -- that even did the most of the work) CoTurn to work in cloud and on local Ubuntu ;-) (never stopped me from bragging though). Though there is troubling few srflx-call-successes yet (mostly local network or relay(TURN) calls). :-D
Related
I need to access company's internal network without using their OPENVPN server directly (My ISP blocks it). So I used an instance with a public IP, where my company is located, and have configured a OPENVPN client then used it to connect to the company's OPENVPN server.
(public IP instance) ===OPENVPN===> (Company)
Now, I need to achieve a further thing, which is working from my local machine by using VPN over SSH tunnel using sshuttle, such that the topology becomes:
(local) ===SSHUTTLE===> (public IP instance) ===OPENVPN===> (Company)
Note that public IP instance has two network adapters; eth0 (it has public IP) and tun0 (which belongs to OPENVPN)
I installed sshuttle, and tested the next command:
sshuttle --dns -r <user>#<public IP instance address> 0.0.0.0/0
It says connected after then but I still cant access anything. I tested dig and it returned results showing addresses of company's internal services. However, I still can't ping them. I tested using traceroute and it stops at some point after displaying some hops.
One important point is that I can't ping the tun0 address (on public ip instance) from my local machine.
I suspect that I need to add some routes on the intermediate public IP instance, but I am not sure.
I would appreciate any help
Thanks in advance
your setup is right but your assumptions are wrong.
Initially, check that your vpn is working fine on the jump box , if linux just check
route -n
Wrong assumptions:
sshuttle will route your dig commands , sshutle only route TCP and DNS queries are UDP
using --dns in your sshuttle meanless as you wont gain dns of vpn but of the jump box and that wont work
you should add the DNS of local vpn in your /etc/resolv.conf with target domain for local discovery
like : < call tech support to provide you with right DNS , you can find it in vpn log on jump box
search companydomain.internal
nameserver 10.x.y.z
its better to split the traffic and only target your company CIDR over sshuttle , most of them use parts of 10.0.0.0/8 instead of all traffic 0.0.0.0/0
important note: that may be your company block egress traffic to the internet over VPN access
I have my stun / turn server running on local pc (CoTurn). It is tested on "https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/" and works. I have a domain name and configured the modem with public ip. I configured apache2 to make the site visible to the world. I have active and valid letsencript certificates. Everything works in short. But the test application starts the connection (the external pc communicates with the local via socket.io) but then the video is not seen and the console returns the error: ICE failed, your TURN server appears to be broken, see about:webrtc for more details.
The link of the application that I use as a test, because with my original I had no comparisons to make. First time with socket.io. But socket.io send and receive messages so these not appear a problem for now.
https://github.com/anoek/webrtc-group-chat-example
P.S.:
Ok. Server is behind the nat. My app (but linked app too) work very fine on local network (sorry I checked this point first before). These with my turn/stun server, than with public stun/turns google servers. This evidently indicates a bad setting of apache2 server or/and turn server. Where could I find a guide about it?
My server situation: myServerIpLocal-xxx.xxx.xxx.xxx -> nat/router/modem WithPublicIpStatic-xx.xx.xx.xx. I can see my sites from all the world, but turn server not work outside the local network. Inside local network work ok.
these my turn config:
listening-port=3478
tls-listening-port=5349
alt-listening-port=3479
alt-tls-listening-port=5350
listening-ip=xxx.xxx.xxx.xxx /*mylocal ip*/
relay-ip=xxx.xxx.xxx.xxx /*mylocal ip*/
external-ip=xx.xx.xx.xx /*my public ip on nat/ruter/modem */
min-port=49152
max-port=65535
verbose
fingerprint
userdb=/var/lib/turn/turndb
realm=mysite.com
cert=/etc/ssl/certificate.pem
pkey=/etc/ssl/private.key
dh-file=/etc/turn/dhparam.pem
no-stdout-log
log-file=/myhome/.turn/turn.log
lt-cred-mech
user=myusername:mypasswd
# Turn OFF the CLI support.
# By default it is always ON.
# See also options cli-ip and cli-port.
#
no-cli
#Local system IP address to be used for CLI server endpoint. Default value
# is 127.0.0.1.
#
cli-ip=127.0.1.1
# CLI server port. Default is 5766.
#
cli-port=5766
# CLI access password. Default is empty (no password).
#
cli-password=logen
no-sslv3
no-tlsv1
my old code on turn.conf:
lt-cred-mech
user=myusername:mypasswd
but turn work only locally .... probabily because I use:
sudo turnserver -L myPublicIp -o -a myrealm
at every coturn start command ....
actually I try not use the command "turnserver" and I try to use onlu sudo coturn start .....
basically in my turn.conf file I change these:
lt-cred-mech
user=mypasswd:myusername /***** mind the gap ;) *****/
these because my index.js file debug never see my external connection as authrized user ..... magically at these time my app perform webrtc multiple connection with every pc and mobile .... inside and outside my lan .... (I try connect my appa from phone in barcelona spain to other one in london with good result).
May be coturn wiki need to update?
Finally I would like to thank the serverfault and super-user guys who rejected my question. Since I had to make arrangements, I was able to acquire new and interesting information on this subject.
regards
I am trying to set up a STUN/TURN server on my local computer for a webrtc application of me. I decided to use coturn. Note that my server is running behind a NAT.
So i fired up my Ubuntu VM and installed it. After reading through the wiki I got it working, atleast on my local network. For testing purposes, i use this site. Therefore, when i try it there with 192.168.178.25:3478, it works. When i try it with "public-ip":3478, it doesnt.
This told me, it is working locally and it should be a port/NAT issue. What i did:
1) I set the VM to Bridging
2) I opened the port 3478 on my router. To test if this is really working, i used telnet on a remote machine and it worked. Another test was that i set up a quick apache server on my local machine on port 3478 and it could be accessed from the outside. This told me that there is, or should be, not port/NAT issue and my turn server should be working.
Any ideas?
I am running my server with the following command:
"sudo turnserver -X "public-ip" -listening-port=3478 -v
The turnserver.conf looks something like this:
fingerprint
realm="myRealm"
lt-cred-mech
user=test:test
As telnet and apache server are both working, i am pretty sure i have a configuration issue. I basically spent the weekend trying and im really lost on what could be wrong.
Thanks for any help!
From the documentation of turnserver
-X, --external-ip <public-ip>[/private-ip] TURN Server public/private address mapping, if the server is behind NAT. In that situation, if a -X is used in form "-X " then that ip will be reported as relay IP address of all allocations. This scenario works only in a simple case when one single relay address is to be used, and no CHANGE_REQUEST STUN functionality is required. That single relay address must be mapped by NAT to the 'external' IP. The "external-ip" value, if not empty, is returned in XOR-RELAYED-ADDRESS field. For that 'external' IP, NAT must forward ports directly (relayed port 12345 must be always mapped to the same 'external' port 12345). In more complex case when more than one IP address is involved, that option must be used several times, each entry must have form "-X ", to map all involved addresses. CHANGE_REQUEST NAT discovery STUN functionality will work correctly, if the addresses are mapped properly, even when the TURN server itself is behind A NAT. By default, this value is empty, and no address mapping is used.
So, it is not enough that you expose only the listening port from the inside LAN to the public network but all ports that you are going to use to relay. Please, note what is said in the same documentation:
--min-port <port> Lower bound of the UDP port range for relay endpoints allocation. Default value is 49152, according to RFC 5766.
--max-port <port> Upper bound of the UDP port range for relay endpoints allocation. Default value is 65535, according to RFC 5766.
You should choose a range of ports in the server, configure with them the options --min-port and --max-port and create a NAT rule to expose those ports to the public side of the router without change.
I'm trying to get Apache working on a GCE instance.
Following GCE's Quickstart guide, I did the following:
Created instance "my-instance" in "my-project" (CentOS image)
Installed httpd, verified it's running
Added the following firewall rule:
gcutil addfirewall http2 --description="Incoming http allowed." --allowed="tcp:http"
and did the same for HTTPS and ICMP
Verified through gce gui that these rules were added to default network
I can ping my instance's IP address but I can't get an HTTP response. I've tried through the browser, from a curl command - no dice. And it works fine when on localhost so I know Apache is returning the index.html page.
When I use curl from a remote host, the error is:
curl: (7) Failed connect to (instance ip addr):80; Connection refused
Thoughts?
I did some experiments to replicate this. In short, I believe HTTP port 80 may be blocked by iptables firewall rules on the local Centos instance. This appears to be the default behavior.
I have a GCE firewall rule setup to allow port 80 traffic to all instances. I created a centos based image via the Cloud Console (which is indeed using the v1 API). Logged in via SSH and started a web server on port 80. I was not able to hit the web server from my laptop. However I was also not able to hit it from another instance in my project. This lead me to suspect a firewall local to the instance rather than Compute Engine's firewall.
I ran this command (which drops the default reject of all ports for testing - this is unsafe to do for machines which are directly exposed to the internet):
$ sudo iptables -D INPUT -j REJECT --reject-with icmp-host-prohibited
After running that, I was able to hit my webserver from both another instance and my laptop. Note that this change is lost after restarting the instance. I don't know the correct procedure for changing the default firewall rules on Centos.
Please try a similar experiment on your instances, especially try to hit the web server from another Compute Engine instance, since service level firewalls do not block traffic between instances on the same network.
Although I use some alias to do ssh tunnel or reverse tunnel, I never understand how it works. Does somebody know how to explain it in very simple way?
I think the 3 primary uses are:
First of all, I can use my home computer to ssh to foo.mycompany.com, without using any password
(foo is a server at work)
How to make foo.mycompany.com:8080 go to my home computer's localhost:3000 ?
If at home, I cannot access http://bar.mycompany.com, but foo can access bar, how to make the home computer able to access http://bar.mycompany.com?
If at home, I cannot access MySQL db at db.mycompany.com, but foo can, how to make it possible to access db.mycompany.com also using ssh tunnel.
Can it be explain in very simple terms? Are there actually some other popular use besides these 3? thanks.
1) Assuming you connect from home to foo, you need a reverse tunnel (-R)
ssh -R 8080:localhost:3000 foo.mycompany.com
This will enable processes running at foo to connect to localhost:8080 and actually speak to your home computer at port 3000. If you want other computers at your work to be able to connect to foo:8080 and access your home computer at port 3000, then you need
ssh -R 0.0.0.0:8080:localhost:3000 foo.mycompany.com
but for this to work you also need this option to foo's sshd_config
GatewayPorts yes
2) The best way to create an http proxy with ssh is with socks. First connect with
ssh -D 8888 foo.company.com
then go to your browser connection settings and enable proxy connection, choose socks4/5 and host: localhost, port 8888. Then just type http://bar.mycompany.com in your browser's address bar.
3) Now you need a local port forward (-L).
ssh -L 3333:db.mycompany.com:3306 foo.mycompany.com
This means that you will be able to connect at localhost:3333 from your home computer and everything will be forwarded to db.mycompany.com:3306 as if the connection was made by foo.mycompany.com. Host db will see foo as the client connecting, so you need to login with the same username and password you use when working from foo.
Adding -g flag will enable other computers from your home network to connect to your computer port 3333 and actually access db:3306.
SSH tunnelling is very simple. It opens a listening socket at one end. Whenever anyone connects to that listening socket, it opens a corresponding connection from the other end to the configured location, then forwards all information both ways between the two, over the SSH link.
Quite an old question, but see if this page helps explain it for you, it's got pretty pictures and all. :)
https://www.ssh.com/ssh/tunneling/
Basically, a SSH Tunnel is a tunnel that can be used to pass (tunnel) data from one place to another, encrypted.
It is also commonly used to route traffic (via a tunnel, think wormhole) to somewhere else, which allows for things such as tunnelling through a firewall or redirecting traffic (encrypted port forwarding).
Let's say you have a firewall between you and the server. The server can access another server (server2) on it's internal network.
[client]--------||------[server]----[sever2]
Let's say you want to access a web server on server2, and for obvious reasons you can't do this directly. Let's say that port 22 (ssh) is open on the firewall. So what we would do is create an SSH tunnel (on server) from server to server2. This will mean that any (outbound?) traffic on port 22 will be sent, via this tunnel, from server:22 -> server2:80.
[client]--------||------[server:22]======[sever2:80]
So (as I understand it), if we connect to server:22, it should redirect traffic on port 22 to the web server on server2:80 using this new SSH tunnel. (as far as I understand, the data is only encrypted in the tunnel, so the end will be decrypted data, if you're wondering if server:80 has to be SSL).
I suppose in one way that using SSH, is in itself, an SSH Tunnel for your old telnet communication. It's just that in most times you hear about SSH Tunnelling, people are referring to the (secure) port forwarding feature it offers, without having to have access to the firewall admin, which is a nifty little feature that a lot of hackers like to use to get around security.
On the more legitimate reasons; it's great way to relay certain traffic to an internal server that works on a different port, should you be limited by a firewall and such, or you want to secure the traffic between two machines (like the SSH program does).
Hope this helps.
EDIT
Found this over at the UNIX SO https://unix.stackexchange.com/questions/46235/how-does-reverse-ssh-tunneling-work, lots of answers with very clear (and pictorial) explanations of what you need!
First of all I will explain SSH:
SSH is remote login shell that helps you to connect remote machines using encrypted connection. So once you made ssh connection to any remote host the connection between hosts are secure and encrypted.
SSH tunneling is routing your traffic through SSH secure connection.
In simple words SSH tunneling is nothing but one connection is encapsulated by another connection. By taking this as a advantage we make tunnels by using SSH client.
Following command helps you to create simple socks proxy
ssh -D 8080 user#sshserverip
Read the man page, specifically the -L, -R and -D options. I don't think someone rewriting this, and possibly introducing mistakes, is useful. If you don't understand it though you could ask more specific questions.
-D gives a SOCKS proxy, which is another useful application of ssh tunnelling.