I just installed trial version of wowza on my system,but when I try to connect to wowza server on local network at port 1935 it does not accept connections. If I make connection on a different port on same machine it is accepted.
When I type localhost:1935 in address bar it gives me the version of wowza server. when I tested the ports using netstat -an it described the port no 1935 as listening. But might be the possible reason for this.
A response of Listening on port 1935 means that your Wowza server is listening on this port and is able to receive client connections. This is the expected behavior for the service. If you can't connect to your Wowza server streams, then it is likely because the packets are not getting to your Wowza streaming port. Then you can go through the following:
Check that you don't have any firewall settings configured on your Wowza server blocking port 1935
From the client device, launch the following URL http://<wowzaServerIP>:1935/ and you should also be able to see the Wowza server version similar to launching http://localhost:1935/ from within the Wowza server
Run a Wireshark capture and see if the packets are getting to the server
Related
I work on a remote server via ssh, I ran a service locally on the remote server but how can I hit API's from my local machine's Postman to the service API's on remote server.
I am able to make curl requests from the remote server but I am not able to do the ssh tunneling in Postman, what are the steps I should follow?
While both ssh and HTTP are protocols to communicate between client and server. The basic difference between SSH and HTTP;
I guess you know, but just for others/clarification - SSH means “Secure Shell”. It has a built-in username/password authentication system to establish a connection. Thing is, it uses Port 22 to perform the negotiation or authentication process for connection. Authentication of the remote system is done by providing a public-key from your machine.
The default Port for most Web-Servers to listen for requests is either Port 80 for HTTP or 443 for HTTPS
To make it work
You can either expose a Port on your remote server by defining a firewall rule (even though 80 should probably be open) and make your server listen to incoming requests on that Port.
OR
Now, if you wan't to making it publicly available
put both, your remote Server and your local machine in the same VPN Network - still your server needs to listen for HTTP requests on some Port.
If you are not using some kind of reverse proxy, make sure to specify the port you are contacting the server on e.g. http://localhost:8080
I am using ubuntu 18.04 in my GCP and have setup my firewalls to listen to port 5000 by default:
my output for netstat -tupln:
when I open <my-ip-address>:5000 I can access my hosted website, but when I try to do <my-ipaddress> It says connection refused. I don't know why it says show as I have changed default port on firewall as well. Can someone please help me out here?
when you open up the public address in a web browser it will go to the server looking for an application running on port 80 or 443 in case of https request. That is why the connection is refused because your firebase only allows for 5000 port request will be forward to your machine.
I'm trying to setup a VNC server on my GCE instance running debian. Normally I connect over SSH, but I need a graphical interface for some other use cases. I have a very basic firewall rule that looks like this
But when I use netcat to check the external IP on port 5901 I get that the connection is refused. Checking a port like 22 works, but none of the other ones let me connect. Am I missing a step here?
The most common problem related to your issue is that the application / server is configured for localhost or 127.0.0.1, which means accept connections only on the local machine. You need to bind with 0.0.0.0 which means listen on all available networks.
When connecting from the public network (outside your system) Connection refused means that nobody is listening. This is not a firewall rule issue as the error message indicates that the connection is not being blocked (no response) versus refused (permission denied).
Connect to your instance via SSH. Then run this command: netstat -a. Look for a line that says LISTENING on your port number. Then look at the IP address. If it shows 127.0.0.1, this is your problem. If you do not see your port number in LISTENING state, then you do not have a process listening on that port.
I have a computer, let's call it linux#home.
I have a dedicated distant linux server, let's call it linuxHost#datacenter.
I have a virtualbox virtual machine running windows 7 on the dedicated server, let's call it windowsGuest#datacenter.
I set up a NAT network interface on windowsGuest through virtualbox manager.
windowsGuest#datacenter is running a service that needs to access an sql database on linuxHost#datacenter, and that works fine. The same service on windowsHost needs to listen to connections on an udp port, let's say 12345. windowsGuest can access internet, web browsing works properly (doesn't need to, but that works fine).
So, now i need linux#home tu run a client application that connects on udp port 12345 on windowsGuest#datacenter. What i did is configure a port forward on the NAT network i use for windowsGuest :
-host ip : 127.0.0.1
-host port : 12346
-protocol : UDP
-guest ip : 10.0.2.4 (which is windowsGuest#datacenter ip address)
-guest port : 12345
I expect that any connection on linuxHost#datacenter on UDP port 12346 would be forwarded to windowsGuest#datacenter UDP port 12345, but that doesn't seem to happen.
a few more information :
- windowsGuest#datacenter's firewall is turned OFF
- linuxHost#datacenter runs iptables and is configured to allow any connection from linux#home, both tcp and udp.
- linuxHost#datacenter 's iptables doesn't log any blocked packets.
- I don't want to turn off iptables since linuxHost#datacenter is running other services and i don't want to expose that.
- I cannot test the client application on linuxHost#datacenter
What did I do wrong? Should i manually forward connections from internet to linuxHost#datacenter on port udp 12346 to 127.0.0.1:12345? should i configure the NAT port forwarding differently? Am i totally wrong and that's not the way i should manage this situation?
Thanks to this answer i could manage what i wanted. I had to modify my NAT port forward in the virtualbox manager preferences. The host ip field can be left blank, so that connections from any ip address would be forwarded to the guest.
i hope your help.
My cloudWatch example is below.
image capture: ssh connection logs with 172.0.0.10
As you see, cloudWatch is logging both of request and response packets.
In this case, everyone knows that packets displaying 22 as destination port is reponse packets because port 22 is well-known ssh server port.
However, if it is not a well-known port number, you will not be able to distinguish between request and response packets. How do you distinguish it in that case? The cloudwatch log alone does not show me how. No matter how I google it, I can not find a way. Please advise.
In this case, everyone knows that packets displaying 22 as destination port is reponse packets because port 22 is well-known ssh server port.
That's not actually correct. It's the opposite.
The server side of a TCP connection is using the well-known port, not the client¹ thus the well-known port is the destination of a request and the source of a response.
Packets with the source port of 22 would be the SSH "response" (server → client) packets. Ports with the destination port of 22 would be the SSH "request" (client → server) packets.
When I make a request to a web server, my source port is ephemeral but the destination port is 80. Responses come from source port 80.
But of course, the argument can be made that the terms "request" and "response" don't properly apply to packets,
But rather they apply to what the packet contains -- and that is protocol specific. In many cases, the client does the requesting and the server does the responding, but that correlation does not cleanly map down to the low layers of the protocol stack.
In the case of TCP, one side is always listening for connections, usually on a specific port, and that port is usually known to you, if not a "well-known" port, because you are the one who created the service and configured it to listen there.
As these flow log records do not capture the flags that are needed to discern the source and dest of the SYN... SYN+ACK... ACK sequence, you can't ascertain who originated the connection.
With no knowledge of the well-known-ed-ness or other significance of "port 22," it is still easy to conclude from your logs that 172.0.0.10 has a TCP socket listening on that port and that numerous other clients are connecting to it from their ephemeral ports... and we can confirm that this is still listening by running netstat -tln on that machine.
¹ not the client most of the time. There are cases where a server daemon is also a client and will use the well-known port as its source port for outgoing connections, so source and dest might be the same in such a case. I believe Sendmail might be an example of this, at least in some cases, but these are exceptions.