I am using AWS EC2 CentOS based system. I also have a website is running on it at the domain mydomain.com
I have installed VLC successfully for my server. I can do SSH and remote to my server (I can use GUI application with gnome)
I start the vlc server with the below command:
vlc --ttl 34 -vvv --color -I telnet --telnet-password vlc --rtsp-host 0.0.0.0 --rtsp-port=554
and setup the stream on it by:
root#whm [~]# telnet localhost 4212
Trying ::1...
Connected to localhost.
Escape character is '^]'.
VLC media player 2.0.8 Twoflower
Password:
Welcome, Master
> new sample01 vod enabled
new
> setup sample01 input file:///home/myuser/public_html/mywebsite/folder/video.mp4
setup
The output of the log is good.
[0x7f24a002c5b8] stream_out_rtp vod server debug: RTSP stream at /sample01
[0x7f24a002c5b8] main vod server debug: net: listening to 0.0.0.0 port 554
[0x7f24a002c5b8] stream_out_rtp vod server debug: RTSP: adding /sample01/trackID=0
[0x7f24a002c5b8] stream_out_rtp vod server debug: RTSP: adding /sample01/trackID=1
[0x7fce4802d8c8] [Media: vod] main input debug: `file:///home/myuser/public_html/video.mp4' successfully opened
If I stay on the server it self, using GUI, I can use the VLC player to open network stream URL:
rtsp://localhost:554/sample01 (it works)
If I use vlc player from another network to connect to the stream by the below URL
rtsp://mydomain.com:554/sample01 (this is the domain that is working for my website)
rtsp://my-server-public-ip.com:554/sample01 (does not work too)
I guess there is something wrong with the port, then I went to AWS console and added more port 554 and 4212 into Inbound list in the Security Group of my instance (like what I'd done for other ports), but it does not help.
The error of the vlc client is:
[000000010050e4c8] core libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
[000000010022a7e8] [http] lua interface: Lua HTTP interface
[0000000104a00978] live555 demux error: Failed to connect with rtsp://mydomain.com:554/sample01
[00000001002b2dc8] core access error: connection failed: Connection refused
[00000001002b2dc8] access_realrtsp access error: cannot connect to mydomain.com:554
[0000000100618e58] core input error: open of `rtsp://mydomain.com:554/sample01' failed
CoreAnimation: warning, deleted thread with uncommitted CATransaction; set CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.
Please help me on this to troubleshoot this problem.
My problem is solved. I have done following things to resolve it, but I am not sure which one is correct. If anyone got same issue, you could try one of these
I enable to Elastic Load Balance serivice of Amazon and add port fowarding for port 554 (RTSP default port)
The streaming server was running well on localhost on server itself but it is inaccessible from outside, I guess it is something about firewall and port.
I scan mydomain.com to see the port is open or not
nmap -v -Pn -sT mydomain.com
Temporarily disable firewall on AWS EC2 instance OR add a line into iptables to open port 554.
Open and edit file by
vi /etc/sysconfig/iptables
Add below line into it
-A cP-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dpport 554 -j ACCEPT
or shutdown the firewall absotelutely
sudo service iptables save
sudo service iptables stop
sudo chkconfig iptables off
Optional, if you are using firewall of Cpanel, you have to check the same with the allowed port of that firewall.
Related
I have an EC2 instance which is running with the following security groups:
HTTP - TCP - 80 - 0.0.0.0/0
Custom UDP Rule - UDP - 1194 - 0.0.0.0/0
SSH - TCP - 22 - 0.0.0.0/0
Custom TCP Rule - TCP - 943 - 0.0.0.0/0
HTTPS - TCP - 443 - 0.0.0.0/0
However, when I try to access http://{PUBLIC_IP} or https://{PUBLIC_IP} in the browser, I get a "{IP} refused to connect" error. I'm new to AWS. Am I missing something here? What should I do to debug?
One way to debug this particular class of problem is to use netcat in order to determine where the problem lies.
If you run netcat against port 80 on the public IP address of your instance and just get a hang (no output at all), then most likely your security group isn't allowing traffic through. Here is an example from an EC2 instance that is in a security group that doesn't allow port 80 traffic inbound:
% nc -v 55.35.300.45 80
<just hangs>
Whereas if the security group is changed to allow port 80, but the EC2 instance doesn't have any process listening on port 80, you'll get the following:
% nc -v 55.35.300.45 80
nc: connectx to 52.38.300.43 port 80 (tcp) failed: Connection refused
Given that your browser gave you a similar "connection refused", most likely the problem is that there is no web server running on your instance. You can verify this by ssh'ing into the instance and seeing if you can connect to port 80 there:
ssh ec2-user#55.35.300.45
% nc -v localhost 80
nc: connect to localhost port 80 (tcp) failed: Connection refused
If you get something like the above, you're definitely not running a webserver.
I'm not sure if it's too late to help but I was stuck with a similar issue with my test server
SG Inbound: ssh -> 22
HTTP -> 80
NACL: default allow/deny settings
but still couldn't ping to the server from my browser, then I realize there's nothing running on the server that can serve the request, and I started httpd server (webserver) and it worked.
sudo yum -y install httpd
sudo service httpd start
this way you can test the connectivity if you are playing with SGs and NACLs and of course it's not the only way, just an example if you're figuring your System N/W out.
Have you installed webserver(ngingx/apache) to serve your requests. If so please share your the config files. (So that it will help to troubleshoot)
I think the reason is probably that you did not set up a web server for your EC2 instance, because if you try to access http://{PUBLIC_IP} or https://{PUBLIC_IP}, you need to have a background server to serve the http request as #Niranj Rajasekaran said.
By the way, by simply pinging the {PUBLIC_IP}, you could see if your connection to your EC2 instance is normal or not.
In command prompt or terminal, type
ping {PUBLIC_IP}
In my case, the server was running but available on just 127.0.0.1 so it refused connections from external hosts. To see if this is your situation, you can run
netstat -an | grep <port number>
If it says 127.0.0.1:<port number> instead of 0.0.0.0:<port number>, you have this problem.
Usually there's a flag or an argument in your server code somewhere to set the host to 0.0.0.0:
app.run(host='0.0.0.0') # flask example
However, in my case, I had already set this so I thought that couldn't possibly be the issue, which is how I ended up on this thread, which asks more generally about the problem. Unfortunately, I was using docker, and had set 0.0.0.0 on the container but was mapping that explicitly to 127.0.0.1 on the host in the docker-compose port-mapping:
ports:
- "127.0.0.1:<port number>:<port number>"
Changing that line to remove the host IP specification fixed the problem upon re-deploy:
ports:
- "<port number>:<port number>"
There is a related post here: Port mapping in Docker on Mac OSX installed with Docker Toolbox
but it didn't work for me
Get ports for container
docker port 485186e65a5e
8080/tcp -> 0.0.0.0:33360
8088/tcp -> 0.0.0.0:33359
19888/tcp -> 0.0.0.0:33358
50070/tcp -> 0.0.0.0:33357
50075/tcp -> 0.0.0.0:33356
8042/tcp -> 0.0.0.0:33361
Check that someone listens to ports in container
bash-4.1# netstat -alnpt | grep 19888
tcp 0 0 127.0.0.1:19888 0.0.0.0:* LISTEN 1094/java
Do wget in container
bash-4.1# wget 127.0.0.1:19888
--2016-04-11 14:16:54-- http://127.0.0.1:19888/
Connecting to 127.0.0.1:19888... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://127.0.0.1:19888/jobhistory [following]
--2016-04-11 14:16:54-- http://127.0.0.1:19888/jobhistory
Reusing existing connection to 127.0.0.1:19888.
HTTP request sent, awaiting response... 200 OK
Length: 6763 (6.6K) [text/html]
Saving to: `index.html'
100%[================================================================================================================================================================================>] 6,763 --.-K/s in 0s
2016-04-11 14:16:54 (182 MB/s) - `index.html' saved [6763/6763]
Try to access forwarded port from host, no luck... :(((
$docker-machine ip default
192.168.99.100
$ wget 192.168.99.100:33358
--2016-04-11 16:18:04-- http://192.168.99.100:33358/
Connecting to 192.168.99.100:33358... failed: Connection refused.
What do I do wrong?
Omg, desired service started on 127.0.0.1 in container, that is why it wasn't visible from outside world. I've modified service config to start on 0.0.0.0 and now I can access forwarded container port
I had the same problem and was able to fix it by specifying the host that the server within the container uses.
NOTE: when using host below, it means a web server host. When I use host-machine, I mean the main operating system I'm using, (i.e. not a container or a web server, just my laptop as a machine)
The Problem
Running web servers on the container like webpack-dev-server and http-server automatically run the app using a host of http://localhost. Typically you will see that in the output when you start the server. Something like :
Project is running at http://localhost:8080
or
Server available at http://127.0.0.1:8080
On most machines, localhost and 127.0.0.1 are the same thing. This host is not publicly viewable. As a result, your host machine can't see anything, even though it's looking in the right place.
Solution
You should specify a public host when you run the server inside your container.
webpack-dev-server --port 8080 --host 0.0.0.0
or
http-server -p 8080 -a 0.0.0.0
Because the 0.0.0.0 address is viewable to any outside machine, you should be able to see your app working as expected from your host machine.
NOTE: This works for any server, like Python's SimpleHTTPServer, etc. Just look up how to change the host for your chosen server in the documentation
Resources/Nods
(how to run webpack-dev-erver with a publicly accessible host)[How to make the webpack dev server run on port 80 and on 0.0.0.0 to make it publicly accessible?
I am trying to install Red5 on server (Windows Server 2012R2) so that I can use it remotely.
What I have tried till now...
case 1:
-set the path for java jre.
-I installed red5 with ip 127.0.0.1 with port no 5080 (already opened this port)
-Start the red5 service.
-Working fine.
But the problem is It's working as localhost, I was not able to access it as remotely then I changed "red.properties" and set rtmp.host to my server IP,
But It didn't work for me.
Case 2:
-I reinstalled red5 server with my server IP with port 5080
-open 5080 port on firewall
-start the server
This setting also didn't work for me.
Where Should I make change to access it remotely..?
Assign correct ip in red5.properties
Change passwords in realm.properties
Open firewall for port 1935 for RTMP and 5080 if you want to access the webserver
(control panel - system and security - windows firewall - advanced settings - new inbound rule - port tcp)
Red5 guide for more installation techniques and videos : link
My lab runs RStudio on a server. A couple weeks ago, from my cousin's house, I successfully ssh'd into the server and pulled up the server-side RStudio through my local Firefox browser. Now when I try to access the server RStudio from home (via my own router), it doesn't work. I need help troubleshooting, and I'm guessing it's some problem on the router. I'm running Mac OSX 10.6.8. No idea what the university server's running, but I don't think it's a server-side problem.
Here's how it worked the first time I did it, at my cousin's house: first, I VPN into the university network; then I call SSH with port forwarding; then I open a Firefox browser, connect to my localhost port, and it opens up RStudio on the server side which I can access through my local browser window.
Here's the problem I'm having right now when I try to log-in from my home network:
I can make the VPN connection successfully. I can also set up SSH successfully with this command:
ssh -v -L 8783:localhost:8783 myacct#server.com
Here are the last several lines of the verbose output from the successful ssh command:
debug1: Authentication succeeded (password).
debug1: Local connections to LOCALHOST:8783 forwarded to remote address localhost:8783
debug1: Local forwarding listening on 127.0.0.1 port 8783.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on ::1 port 8783.
debug1: channel 1: new [port listener]
debug1: channel 2: new [client-session]
debug1: Entering interactive session.
Last login: Mon Sep 2 04:02:40 2013 from vpnipaddress
So I think I'm still succeeding at the VPN and SSH stage (though I don't know why it says my last login was Sep 2 when I've logged in a few times since then).
Next, I open Firefox, and I type localhost:8783, and instead of getting an RStudio server app through my browser window, I get the following errors:
In the Firefox browser window, it says: Server not found, Firefox can't find the server at www.localhost.com, Check the address for typing errors etc.
In the terminal window, it says:
debug1: Connection to port 8783 forwarding to localhost port 8783 requested.
debug1: channel 3: new [direct-tcpip]
channel 3: open failed: connect failed: Connection refused
debug1: channel 3: free: direct-tcpip: listening port 8783 for localhost port 8783, connect from 127.0.0.1 port 50420, nchannels 4
I'm not sure what I've got wrong. I haven't changed anything on my laptop since my last successful connection. I'm on my own router (instead of my cousin's), so maybe I need to mess with the firewall? I already allowed ports 22 and 8783 to come through the firewall to my laptop (I'm not even sure I needed to do that though). Help?
ssh -v -L 8783:localhost:8783 myacct#server.com
...
channel 3: open failed: connect failed: Connection refused
When you connect to port 8783 on your local system, that connection is tunneled through your ssh link to the ssh server on server.com. From there, the ssh server makes TCP connection to localhost port 8783 and relays data between the tunneled connection and the connection to target of the tunnel.
The "connection refused" error is coming from the ssh server on server.com when it tries to make the TCP connection to the target of the tunnel. "Connection refused" means that a connection attempt was rejected. The simplest explanation for the rejection is that, on server.com, there's nothing listening for connections on localhost port 8783. In other words, the server software that you were trying to tunnel to isn't running, or else it is running but it's not listening on that port.
Posting this to help someone.
Symptom:
channel 2: open failed: connect failed: Connection refused
debug1: channel 2: free: direct-tcpip:
listening port 8890 for 169.254.76.1 port 8890,
connect from ::1 port 52337 to ::1 port 8890, nchannels 8
My scenario; i had to use the remote server as a bastion host to connect elsewhere. Final Destination/Target: 169.254.76.1, port 8890. Through intermediary server with public ip: ec2-54-162-180-7.compute-1.amazonaws.com
SSH local port forwarding command:
ssh -i ~/keys/dev.tst -vnNT -L :8890:169.254.76.1:8890
glue#ec2-54-162-180-7.compute-1.amazonaws.com
What the problem was:
There was no service bound on port 8890 in the target host. i had forgotten to start the service.
How did i trouble shoot:
SSH into bastion host and then do curl.
Hope this helps.
Note: localhost is the hostname for an address using the local (loopback) network interface, and 127.0.0.1 is its IP in the IPv4 network standard (it's ::1 in IPv6). 0.0.0.0 is the IPv4 standard "current network" IP address.
I experienced this error with a Docker setup. I had a Docker container running on an external server, and I'd (correctly) mapped its ports out as 127.0.0.1:9232:9232. By port-forwarding ssh remote -L 9232:127.0.0.1:9232, I'd expected to be able to communicate with the remote server's port 9232 as if it were my own local port.
It turned out that the Docker container was internally running its process on 127.0.0.1:9232 rather than 0.0.0.0:9232, and so even though I'd specified the container's port-mappings correctly, they weren't on the correct interface for being mapped out.
In my case, it worked after running the vncserver on linux.
Entered this on linux command line : sudo ssh -L 5901:localhost:5901 -i <ssh_private_key> <username>#<public-IP-address>
Type there vncserver
Go to VncViewer application and connect using localhost:5901
I used to meet the similar problem because 'localhost' was not available on server when it restarted network service, e.g. 'ifdown -a' but followed by only 'ifup -eo1'. Besides server is not listening to the port, you can also check 'localhost' is available or not.
ps: Post it just hope someone who has the similar problem may benefit.
I had this problem when I wanted to make a vnc connection via a tunnel.
But the vncserver was not running.
I solved it by opening the channel on the remote machine with vncserver :3.
In my case, it worked after checking the correct IP address of the user credentials
previously I was using the wrong IP of the server
ssh -NfL 127.0.0.1:8084:127.0.0.1:8888 user#ip_address_of_server
after correcting it, works fine.
Encountered with the same error.
In my case, I found the problem was in the config file of jupyter.
Let's say there are 3 computers named A, B, and C, and A can access B but can't access C; B can access C.
To access jupyter-notebook service of C from A, first I established ssh tunnel from A to C through B, then I access jupyter-notebook by typing localhost:port_number, then I got the error.
Finally the problem was solved by writing the "c.NotebookApp.ip = '0.0.0.0'" in jupyter-notebook's config file, where '0.0.0.0' allows the access of other IPs.
Hope someone in a similar situation may benefit.
I had the same error when I was trying to tunnel my mlflow ui over ssh to view remotely. As mentioned in the first answer, the error arises because nothing on the server is listening for the port. This, for me, is because I forgot to start the mlflow app on my remote machine! So in general – make sure the app you're trying to access remotely is running.
Just replace localhost with 127.0.0.1.
(The answer is based on answers of other people on this page.)
This means the remote vm is not listening to current port i solved this by adding the port in the vm server
This is a very basic Amazon EC2 question, but I'm stumped so here goes.
I want to launch an Amazon EC2 instance and allow access to HTTP on ports 80 and 8888
from anywhere. So far I can't even allow the instance to connect to on those ports using
its own IP address (but it will connect to localhost).
I configured the "default" security group for HTTP using the standard HTTP option on the management console (and also SSH).
I launched my instance in the default security group.
I connected to the instance on SSH port 22 twice and in one window launch an HTTP server
on port 80. In the other window I verify that I can connect to HTTP using the "localhost".
However when I try to access HTTP from the instance (or anywhere else) using either the public DNS or the Private IP address I het "connection refused".
What am I doing wrong, please?
Below is a console fragment showing the wget that succeeds and the two that fail run from the instance itself.
--2012-03-07 15:43:31-- http://localhost/
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: /__whiff_directory_listing__ [following]
--2012-03-07 15:43:31-- http://localhost/__whiff_directory_listing__
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: “__whiff_directory_listing__”
[ <=>
] 7,512 --.-K/s in 0.03s
2012-03-07 15:43:31 (263 KB/s) - “__whiff_directory_listing__” saved [7512]
[ec2-user#ip-10-195-205-30 tmp]$ wget http://ec2-50-17-2-174.compute-1.amazonaws.com/
--2012-03-07 15:44:17-- http://ec2-50-17-2-174.compute-1.amazonaws.com/
Resolving ec2-50-17-2-174.compute-1.amazonaws.com... 10.195.205.30
Connecting to ec2-50-17-2-174.compute-1.amazonaws.com|10.195.205.30|:80... failed:
Connection refused.
[ec2-user#ip-10-195-205-30 tmp]$ wget http://10.195.205.30/
--2012-03-07 15:46:08-- http://10.195.205.30/
Connecting to 10.195.205.30:80... failed: Connection refused.
[ec2-user#ip-10-195-205-30 tmp]$
The standard tcp sockets interface requires that you bind to a particular IP address when you send or listen. There are a couple of somewhat special addresses: localhost (which you're probably familiar with) which is 127.0.0.1. There's also a special address, 0.0.0.0 or INADDR_ANY (internet protocol, special shorthand for ANY ADDRESS). It's a way to listen on ANY or more commonly, ALL addresses on the host. This is a way to tell the kernel/stack that you're not interested in a particular IP address.
So, when you're setting up a server that listens to "localhost" you're telling the service that you want to use the special reserved address that can only be reached by users of this host, and while it exists on every host, making a connection to localhost will only ever reach the host you're making the request from.
When you want a service to be reachable everywhere (on a local host, on all interfaces, etc.) you can specify 0.0.0.0.
(0) It's silly but the first thing you need to do is to make sure that your web server is running.
(1) You need to edit your Security Group to let incoming HTTP packets access your website. If your website is listening on port 80, you need to edit the Security Group to open access to port 80 as mentioned above. If your website is listening on some other port, then you need to edit the Security Group to access that other port.
(2) If you are running a Linux instance, the iptables firewall may be running by default. You can check that this firewall is active by running
sudo service iptables status
on the command line. If you get output, then the iptables firewall is running. If you get a message "Firewall not running", that's pretty self-explanatory. In general, the iptables firewall is running by default.
You have two options: knock out the firewall or edit the firewall's configuration to let HTTP traffic through. I opted to knock out the firewall as the simpler option (for me).
sudo service iptables stop
There is no real security risk in shutting down iptables because iptables, if active, merely duplicates the functionality of Amazon's firewall, which is using the Security Group to generate its configuration file. We are assuming here that Amazon AWS doesn't misconfigure its firewalls - a very safe assumption.
(3) Now, you can access the URL from your browser.
(4) The Microsoft Windows Servers also run their personal firewalls by default and you'll need to fix the Windows Server's personal firewall, too.
Correction: by AWS default, AWS does not fire up server firewalls such iptables (Centos) or UAF (Ubuntu) when you are ordering the creation of new EC2 instances - That's why EC2 instances that are in the same VPC can ssh into each other and you can "see" the web server that you fired up from another EC2 instance in the same VPC.
Just make sure that your RESTful API is listening on all interfaces i.e. 0.0.0.0:portID
As you are getting connection refused (packets are being rejected) I bet it is iptables causing the problem. Try to run
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -p tcp --dport 8888 -j ACCEPT
and test the connection.
You will also need to add those rules permanently which you can do by adding the above lines into ie. /etc/sysconfig/iptables if you are running Red Hat.
Apparently I was "binding to localhost" whereas I needed to bind to 0.0.0.0 to respond to port 80 for the all incoming TCP interfaces (?). This is a subtlety of TCP/IP that I don't fully understand yet, but it fixed the problem.
Had to do the following:
1) Enable HTTP access on the instance config, it wasn't on by default only SSH
2) Tried to do nodejs server, so port was bound to 80 -> 3000 did the following commands to fix that
iptables -F
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
sudo service iptables-persistent flush
Amazon support answered it and it worked instantly:
I replicated the issue on my end on a test Ubuntu instance and was able to solve it. The issue was that in order to run Tomcat on a port below 1024 in Ubuntu/Unix, the service needs root privileges which is generally not recommended as running a process on port 80 with root privileges is an unnecessary security risk.
What we recommend is to use a port redirection via iptables :-
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
I hope the above information helps.