I want to connect my instance with another instance through sockets and i can choose the port on which my instance build up the connection. It does not matter what port i take between 1024 and 65535, i get the information that the port is busy and i should choose another port.
Does somebody know what to do ?
If i take the internal ip address, it works, but the other instance can not contact my instance.
First, You can check your VM instance if there’s an active firewall.
For Debian/Ubuntu you can run the command:
‘sudo ufw status’
For Centos/Redhat you can run the command:
‘sudo firewall-cmd --state’
Basically if there are no active firewalls inside your two VM instances and within the same VPC it should be able to connect to each other.
In addition, you can install “Nmap” to scan the open ports to the other VM instance.
Related
I am trying to run a Docker container on my EC2 machine. The container is an API for a game lobby service, and it listens to port 4242 by default.
When I try to send an HTTP request in the browser, I don't get anything. Does the EC2 even have a port 4242?
My apologies if this question is too vague. I am very new to this whole networking thing.
An EC2 instance is a Windows or Linux computer. It has all the TCP ports, from 0 to 65535, just like any other computer.
You may need to open the port in any firewall software running on the server, and you will definitely need to open the port in the AWS Security Group assigned to the EC2 instance.
Launching an AWS EC2 instance seems quite straightforward although when it comes to connecting to the newly launched instance things get sticky. The process for connecting to an instance proposed by such a tech giant is very counter-intuitive.
As a short reminder I should add that an "instance" is technically a virtual machine running on Amazon's Elastic Compute Cloud (EC2), for more info one could have a look at this link.
The ec2 instance referred to in this discussion is Ubuntu Server 20.04 LTS (HVM).
The instruction for working with EC2 Linux instances is given here.
AWS EC2 proposes three different ways of connecting to an instance:
EC2 Instance connect (browser-based SSH connection),
Session Manager
SSH Client
Now with regard to connecting to the above-mentioned instance there are only certain connections that establish correctly and the rest of the proposed methods fail, here is the list of connection successes and failures :
Ubuntu instance, security group source "Custom=0.0.0.0/0", Connection establishes using both EC2 Instance Connect (browser-based SSH connection) and SSH client.
Ubuntu instance, security group source "My IP=$IP", Connection establishes only using SSH client (terminal on Ubuntu and PuTTY on windows) and not using EC2 instance connect.
Both above cases have been tried on Ubuntu 20.04 and Windows 10 as local machine and the problem remains similar on both machines. I went through most of the failure cases discussed in the troubleshooting documents proposed here and verified them on my instance. Yet the problem persists. I should also add that I never tried "session manager" connection method although opening its tab already would give some info about "not installed" agents and features.
Any idea regarding this problem? Somebody out there facing the same issue?
From Docs
(Amazon EC2 console browser-based client) We recommend that your instance allows inbound SSH traffic from the recommended IP block published for the service.
Reason for this -> EC2 Instance Connect works by making an HTTPS connection between your web browser and the backend EC2 Instance Connect service on aws. Then, EC2 Instance Connect establishes a "mostly normal" SSH connection to the target instance in other words the request is going from backend ec2 instance connect and not your browser that is why it needs IP address from accepted ranges of that region .
Browser based EC2 Instance Connect uses specific IP ranges for browser-based SSH connections to your instance. These IP ranges differ between AWS Regions. To find the AWS IP address range for EC2 Instance Connect in a specific Region, use the following( just replace your region with your region) ( for Linux required curl and jq as prerequisite)
curl -s https://ip-ranges.amazonaws.com/ip-ranges.json| jq -r '.prefixes[] | select(.region=="Your region") | select(.service=="EC2_INSTANCE_CONNECT") | .ip_prefix'
whatever the value is returned just add up to your security rule and it will work.
Ubuntu instance, security group source "Custom=0.0.0.0/0", Connection establishes using both EC2 Instance Connect (browser-based SSH connection) and SSH client.
this works because 0.0.0.0/0 allows connection from all the IP ranges( which includes your region IP too).
for more details try reading this troubleshoot
I have created n1-standard-1 (1 vCPU, 3.75 GB memory) VM and installed LAMP on it with a static IP address. When I am trying to hit the static IP address in browser, it says This site can’t be reached However I have checked firewall rules and port 80 is opened.
Below is the output of gcloud compute firewall-rules list command -
And the output of telnet is as -
Is there anything else I need to do to open port 80 and 443?
Please help, thank you!!
This could be the VM's configuration. You'll want to check that the machine is actually listening on that port. You may have installed LAMP but are the services started, for instance? Best way to do that is SSH into the system and curl localhost. If the curl fails, you know the services are not listening on that port.
After that check that you can access the system from the VPC if you can, for example via another system in the same VPC, run curl <machine>. If that doesn't work, you may find the system is only listening on 127.0.0.1 or has other settings blocking connections from other machines.
If those steps succeed then your firewall rules are indeed to blame - check that your system is in the correct VPC (default you listed above).
Finally, you haven't specified how you assigned the static IP address but make sure that the address is created and assigned to that instance.
I have an EC2 instance (running CentOS 7) with two network interfaces on it. The primary is ens5 and the secondary was attached as eth0. What I'm attempting to do is bind my docker container to eth0, so that both incoming and outgoing traffic is associated with the IP address of eth0.
I have a couple of external ports exposed. The first thing I tried in my docker run command was to just do eth0_ip:port:port. The container did start up successfully, and I was able to hit the container from the host on the IP of eth0, however when making requests from other EC2 instances in the same VPC, the requests timed out. Using tcpdump I was able to confirm that external requests are making it to the instance, however requests aren't making it to the container.
I also attempted to create a new network associated with the IP address of eth0, and then set the --network flag in my run command, but I was greeted with the same exact failure.
Any help would be greatly appreciated!
Created an AWS AMI instance.
I can telnet from the instance itself
telnet [Pv4 Public IP] 9200
But not from my pc.
This is my security group
What am I doing wrong?
You can check your Network ACL configurations.
It looks like there is some other firewall in between your PC and server which is blocking you on 9200.
If you can access port 80 via telnet or you're able to SSH in it's likely you have a network ACL in place. If you can not access port 80 via telnet but you can via a browser it's like a local config - maybe AV or a firewall.
EC2 instances use security groups for their firewall
Another test to narrow down the the issue would to see if you could telnet from another instances in the same subenet in the same AZ. Being in the same subnet you should not be affected by a network ACL.
You can have a look at this telnet-to a cloud instance from outside
The solution to problem was "Open the services and make the telnet manual and right click on it and chose start"
As well make sure that the instance is residing in a public VPC
Based on what you've described, there isn't really much else to work with. Your ability to telnet the public IP from the instance implies the server is listening on the external interface and your security group is already set to have the port open to all incoming connections.
Aside from the trivial overlooking of not actually having the instance under the listed security group, the only possibility I can think of now is an active firewall on the instance. In the case of iptables or ufw (which is an interface to iptables), it's trivial to verify whether they are indeed getting in the way:
// List iptables access rules
sudo iptables -L -v
// List access rules via ufw
sudo ufw status
You said: "This is my SG", but...which way? Inbound or outbound?
It can simply be that your host can't reply to your PC.
Try to add a rule which adds outbound TCP ranging from ports 32768 to 65535 (ephemeral ports), so that the telnet server response packets can travel back to your PC.
Otherwise, like the others said, look at one level up, VPC-level (network ACL).
You might have your acceptor process running on 127.0.0.1:9000 which means only local clients can connect. This is not related to your Security Group which could be wide open.
Run lsof -i:9000 if on unix.
If you see something like this under NAME then host IP used to start your acceptor will needs to change from 127.0.0.1 to 0.0.0.0 (and secure via SG/FW).
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
java 2777 ubuntu 148u IPv6 26856 0t0 TCP localhost:afs3-callback (LISTEN)
A Telnet service is not installed by default on an Amazon Linux AMI.
If you wish to use it, you will need to install it yourself, eg: Install and Setup Telnet on EC2 Amazon Linux or CentOS.
However, these days it is recommended to use ssh instead of telnet because it is more secure. See: Telnet on wikipedia
Just a thought, check firewall of your PC.
Need to ensure your SSH key you generated via IAM and attached to the EC2 at launch is added to the login:
ssh-add -K <yourkeyname>.pem
ssh ubuntu#<yourdns or ip>.com == or == ssh ec2-user#<yourdns or ip>