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
We had multiple clients configured to talk to this cluster of aerospike nodes. Now that we have removed the configuration from all the clients we are aware of, there are still some read/write requests coming to this cluster, as shown in the AMC.
I looked at the log file generated in /var/log/aerospike/aerospike.log, but could not get any information.
Update
The netstat command as mentioned in the answer by #kporter shows the number of connections, with statuses ESTABLISHED, TIME_WAIT, CLOSE_WAIT etc. But, that does not mean those connections are currently being used for get/set operations. How do I get the IPs from which aerospike operations are currently being done?
Update 2 (Solved)
As mentioned in the comments to #kporter's answer, a tcpdump command on the culprit client showed packets still being sent to the aerospike cluster which was no more referenced in the config file. This was happening while even AMC of that cluster did not show any more read/write TPS.
I later found that this stopped after doing a restart of the nginx service on the client. Please note that the config file in the client now references a new aerospike cluster and packets sent to that cluster did not stop after the nginx restart. This is weird but it worked.
Clients connect to Aerospike over port 3000:
The following command, when run on the server nodes, will show the addresses of hosts connecting to the server over port 3000.
netstat --tcp --numeric-ports | grep 3000
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
I am working with Redis 3.2 and while connecting to the sentinel from a differnt machine I get the following error:
Trying X.X.X.X...
Connected to X.X.X.X.
Escape character is '^]'.
-DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients. In this mode connections are only accepted from the loopback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions: 1) Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent. 2) Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server. 3) If you started the server manually just for testing, restart it with the '--protected-mode no' option. 4) Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.
Connection closed by foreign host.
Can somene help me resolve this?
From redis 3.2, Sentinel by default, is not reachable from interfaces other than localhost.
Either use the 'bind' directive to bind to a list of network interfaces, or disable protected mode with "protected-mode no" by adding it to this configuration file.
For example you may use one of the following:
bind 127.0.0.1 192.168.1.1
protected-mode no
For testing, you can try
redis-server --protected-mode no
This will set Redis protected mode to no.
As from documentation suggested steps.
1) Just disable protected mode sending the command 'CONFIG SET
protected-mode no' from the loopback interface by connecting to Redis
from the same host the server is running, however MAKE SURE Redis is
not publicly accessible from internet if you do so. Use CONFIG REWRITE
to make this change permanent.
2) Alternatively you can just disable the protected mode by editing
the Redis configuration file, and setting the protected mode option to
'no', and then restarting the server.
3) If you started the server manually just for testing, restart it
with the '--protected-mode no' option.
4) Setup a bind address or an authentication password. NOTE: You only
need to do one of the above things in order for the server to start
accepting connections from the outside.
I can't access to AWS EC2 instance from one day.
(AMI: ubuntu/images/ebs/ubuntu-precise-12.04-amd64-server-20121001 (ami-22ad1223))
$ ssh -v -i mykey.pem ubuntu#XXX.XXX.XXX.XXX
OpenSSH_5.9p1, OpenSSL 0.9.8x 10 May 2012
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22.
debug1: connect to address xxx.xxx.xxx.xxx port 22: Operation timed out
ssh: connect to host xxx.xxx.xxx.xxx port 22: Operation timed out
This is my "Security Groups" setting in EC2.
I did not change the setting from the time had a good connection.
Ports Protocol Source
22 tcp 0.0.0.0/0
80 tcp 0.0.0.0/0
3000 tcp 0.0.0.0/0
3006 tcp 0.0.0.0/0
I've tried many times to restart the server.
Web server is going well. However SSH connection is not.
What could be problem and how to make it work?
My usual checklist:
On AWS console: is the Instance up and healthy?
Is it in a public Subnet?
Does it have a public ip?
Does the VPC have an associated Internet Gateway?
Does it have the Routing Table to the Internet Gateway? (Attached to the subnet?)
Are the Network ACL rules default?
Does the Security group allow ping? If yes, does the ping work?
Does the Security group allow SSH inbound?
If there is still no clue, then fire up a new instance (from a base AMI) in the same VPC. Connect to it via SSH. If it was successful, try to ssh from that instance.
I too faced the same issue. Actually, by mistake, I deleted the default Internet Gateway.
Go to VPC and click "Internet Gateways" from the left menu.
Click "Create internet gateway" button and provide Name tag (any name - optional) and click create.
By default, it is detached. So click the Actions drop-down and select "Attach to VPC" and attach it with default VPC
Now go to "Route Table" and select default route table and edit the route by clicking "Edit routes" button under Routes tab
Then in the Destination text box provide "0.0.0.0/0" and in target select the newly created Internet gateway (starts with igw-alphanumeric) and save the route.
Now you should be able to SSH EC2 instance.
For newbies to AWS, like me, remember the hostname can change if you reboot or stop/start your instances. So remember to use the right hostname - visible in the description of your instance each time you ssh.
If this happens "from one day", the IP your AWS EC2 instance associated with may be blocked from this day.
If the IP is blocked, you need to add a new dynamic IP and associate this new dynamic IP with your AWS EC2 instance.
Steps:
1.Go to "Elastic IPs".
2.Allocate new address.
3.Choose this new address. Click "Actions" and "Associate address".
4.Select your instance and Click "Associate".
In my case, adding new dynamic IP to my AWS EC2 instance fix the problem.(My problem was I can't access to AWS EC2 instance from one day too)
Kindly create a new security group and select type SSH
SSH
TCP
22
0.0.0.0/0
In addition to Adam's answer, also check if your public subnet's RT table is using the IGW and the private Subnets' RT has 0.0.0.0/0 -> NAT instance Id.
Check that you are connecting to the public dynamic IP or associate an ElasticIP and connect to it.
I was using public wifi in the library and that was not letting me connect, which I came to know when I switched to my mobile hotspot wifi (password protected). Try switching to a protected network.
Even I also faced this same problem, good to know i have not allowed from route table.
Check EC2 Instance associated
And try these steps
subnet,Route table and allowed CIDR blocks
key pair associated with EC2 Instance
security group ssh port 22 allowed or not.
If you are accessing from a new machine, then make sure the IP of the machine you are accessing from is included in the inbound rules. If not add a rule
SSH | TCP | Port:22 | Source: MY IP
For me, I had to delete all my rules for the security group for the particular instance and create new rules for the same ssh, http and https
For some reason after stopping the instance and starting it later, my IP changed... probably because I switched my wifi connectivity device.
But putting new rules with the new IP address worked! You can check the ip by googling "myip"
Well, if this happened all of a sudden, try disconnecting and connecting back to your VPN (if accessing through a VPN). It might work!
I was able to fixed it simply by following this instruction
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html
It sets up your private key pair as well as security group. The issue I think mainly because the default security group doesn't has a ssh inbound for your local IP setup.
If none of the troubleshooting steps above work for you, make sure that your EC2 container meets all system requirements for the application(s) you're running on the container. SSH will sometimes not be able to start if the memory runs out before getting to the SSH service.
Example: I was perfectly able to SSH into my EC2 container when I first launched it. I then proceeded to install Mailcow. My issue with SSH arose after restarting my container because the application I had installed required heavy services -- Docker, for example. After reading the system requirements from Mailcow, I realized a t2.micro wasn't even close to what I needed to run everything. I changed to a t3.large, and all worked perfectly.
Even after doing this for awhile, you can sometimes forget the most basic steps and requirements.
Try stopping the ec2 instance and then restarting. It worked for me!