I'm setting up a new server in AWS, Ubuntu 18.04 and created the inbound rules and attached to the server permitting the port:
Custom TCP Rule TCP 7096 0.0.0.0/0
Custom TCP Rule TCP 7096 ::/0
and have a script php file that has to be acessed in that port, and I used UFW created the rules permitting the port: 7096 and finally I disabled it, I'm using a site that checks if the port is open and no matter what I do, the access is always not permitted. I have tryed many solutions found on the net but nothing solves. All other rules are ok for ports: 80, 22, 3306, but for that no way.
Assuming your security group is configured properly, which it seems like it probably is based on the inbound rules you've defined, it could be that your EC2 instance isn't reachable from the internet.
Is the instance in a public subnet? Does it have a public IP assigned? Are you testing connectivity using the IP or the AWS domain name? Is it in the default VPC? Or have you made your own?
There's a myriad of reasons why it might be failing, so it will be difficult to figure out without some more information.
Related
I have a basic web application running on a port in an EC2 instance. I have also created an A record in Route53 which points a domain name that I own towards the ip address of the EC2 instance.
When I directly access ip-address:port, it works fine, but because the a record does not point towards that specific port, the website cannot be accessed through the domain name.
How do I specify a port that all requests to that ip address should be routed to?
port is referenced by protocol you are using.
if you use http you will connect to port 80. https uses 443, ftp 21, smtp 25 and there are many others (they are called default ports for service but they may use every other defined).
You are probably running application, listening on some different port (but using protocol http) and that's why you can reach it by entering http://ip-address:port
what you can do to reach it by entering only http://ip-address is to set it to listen on port 80 (you will need root privileges to do this) or set redirect from port 80 to your applications port (you can use pure port redirection using iptables or (better) reverse proxy software. It can be apache as mentioned in comment above, or nginx or haproxy or something else (you haven't specified operating system anyway - those are mainly for linux).
Hope that helps
I have a strange problem wherein I am able to connect to an EC2 instance in a public subnet in AWS VPC using RDP and HTTP. However after successfully connecting to the instance through RDP, i am not able to connect to Internet (from the instance).
a) I created a non-default AWS VPC and associated an IGW to it. The address range of VPC is 10.0.0.0/16. A subnet with the address space 10.0.5.0/24 was created
c) In order to make the subnet public, i decided to retain the Main Route Table as it is and created an additional Route table with the following entries
10.0.0.0/16 local
0.0.0.0/0 igw
d) This route table was associated with the subnet 10.0.5.0/24. This makes it a public subnet
e) The NACL is set to allow:
INBOUND traffic HTTP(80),HTTPS(80),SSH(22), RDP(3389) for IPV4 and NACL
outbound traffic ALL TRAFFIC ALL PROTOCOL ALL PORT Range Destination 0.0.0.0/0
f) The security group settings are:
Inbound All traffic All All 0.0.0.0/0
Outbound All traffic All All 0.0.0.0/0
g) I created a single EC2 instance in the public subnet and assigned a Elastic EIP to it. I am able to connect to this using RDP and able to access the IIS Welcome page by typing the public DNS name of the EC2 in my local browser. However, from the instance when i open IE and try accessing any popular websites i am not able to access the Internet. I always get a 'Can't reach this page'
h) I disabled Windows Firewall and tried accessing Internet. But still it didnt work.
i) The tracert output just shows Request timed Out in all the lines.
Any help would be appreciated.
Thanks and Regards
Govind
First, verify that the following conditions are met:
The route table in the instance’s subnet has a default route to an
internet gateway. The security group attached to the instance’s
elastic network interface must allow outbound traffic on the following
ports: Port 80 for HTTP traffic Port 443 for HTTPs traffic Identify
the network access control lists (ACLs) that are associated with the
subnet that the instance is located on. These network ACLs must have
rules to allow inbound and outbound traffic on ports 80 and 443.
You don't need to open all the ports to enable outgoing web traffic.
https://aws.amazon.com/premiumsupport/knowledge-center/ec2-connect-internet-gateway/
Finally i was able to fix this issue. I added
ALL TCP TCP (6) 0 - 65535 0.0.0.0/0 ALLOW
as an INBOUND rule in NACL. Immediately i was able to access the Internet from the browser in Ec2 instance.
However i am not convinced that all the ports should be opened to use browser on an EC2 instance in the public subnet. Is there a better way to do this ?
Can i consider setting up a Forward Proxy server as a solution for browser based outgoing traffic as in this case ? Please suggest
Before anything else, I have read about 30+ StackOverflow answers and none of them seem to address my particular flavour of this problem. Below I list all the answers I have already tried before asking for more advice.
I am trying to access my ec2 instance via socket in PHP from a different machine via fsockopen, pointed at my ec2 public IP (I have an Elastic fixed IP address 54.68.166.28) and designated port.
Behaviour: I can access the instance and the ChatScript application running inside from within the instance, via the public IP directly on the browser. But if I run the exact same webpage with the exact same socket call on an external machine targeting my instance's IP address (double checked it is the correct one) I get a 500 Internal Server Error when connecting on port 1024 (for my custom TCP connection), another 500 on port 443 (HTTPS). On port 80 (HTTP) it hangs 20+ seconds then gives me status 200 success, except it does not connect properly to the application and responds with nothing.
Troubleshooting:
I have set up my security group rules to accept incoming TCP from anywhere:
HTTP (80) TCP 80 0.0.0.0/0
HTTP (80) TCP 80 ::/0
HTTPS (443) TCP 443 0.0.0.0/0
HTTPS (443) TCP 443 ::/0
Custom (1024) TCP 1024 0.0.0.0/0
Custom (1024) TCP 1024 ::/0
Outbound rules span port range 0 - 65535 with destination 0.0.0.0/0, so should work.
I ssh every time without problems into the instance on port 22. SCP also works fine.
Checked $sudo service httpd status: running, which is why my UI displays there fine.
Checked $sudo /sbin/iptables -L and all my policies are set to ACCEPT with no rules
Checked $ netstat --listen -p and the app I am targeting is listening on port 0.0.0.0.0:1024.
Checked Network Utility and ports 80 and 1024 are registered as open. Port 443 is not. Pinging did not work for any of them, with 100% packet loss.
Checked my instance is associated to the security group with all the permissions - it is. IP is clearly correct or I could neither ssh nor serve webpages... which I can.
I stopped and restarted the instance.
I replaced the instance.
I think this is due diligence before asking for help... now I need it!
I realised my configuration was correct: the problem was that the hosted domain I used for the GUI, like most hosted domains, does not open custom ports, so tcp did not work.
Hello today configured vps on Google Cloud and put Vesta control panel, but the problem is not open one https that is, and the ip server and the domain itself does not open on https. Set up Google Cloud firewall and opened ports 80,443 but https does not open the site itself is not the ip of the server. Checked through online services port 443 is closed but settings of the server and a firewall of Google and ip tables say that port 443 is opened (checked by several services port 443) and in the browser through ip of the server and the domain on https do not open. Please tell me how to open port 443?
Same with ports 8443,8080.
I am not able to comment but here are some steps that might help to isolate the issue:
Check to see if the port is open or closed or filtered using nmap
nmap [ip_address]
Firewall rules are defined at the network level and therefore make sure that you follow this document while creating the firewall rules to allow incoming traffic on TCP port 80 and 443 (same for other ports). In this document in step 11, choose " specified protocols and ports" and enter tcp: 80, tcp: 443.
As you previously stated, you need to make sure there is no firewall running inside the VM blocking those connections.
You also need to verify if the application running on your vps is listening on port 443. To check this, try with this command.
sudo netstat -ntlp | grep LISTEN
In the output, if you don't see the application beside port number, check if your vps is rightly configured to ports for your application.
I was having the same issue with NGinx. And Found the root cause finally to be the Firewall (GCP VM Firewall) having a lower priority for the rule. ie: I had 65534 (which is super low priority) for the "Ingress 443" rule. Which did block the traffic coming into the SSL. Instead when I set this rule to 1, traffic started flowing and issue sorted.
What finally helped me was https://cloud.google.com/vpc/docs/using-firewalls
Thanks #Md Zubayer for the tip.
I have two Ubuntu instances in the EC2 and I want to cluster them.
One ip will be refered as - X (the "net addr" ifconfig displayed IP) and its public ip will be reffered as PX.
the other ip is Y and its public is Y.
So now I did the following on both machines.
installed the latest rabbbitmq.
installed the management plugin.
opened the port for 5672 (rabbit) and 15672(management plugin)
connected to rabbit with my test app.
connected to the ui.
So now for the cluster.
I did the following commands
on X
rabbitmqctl cluster_status
got the node name which was 'rabbit#ip-X' (where X is the inner IP)
on Y
rabbitmqctl stop_app
rabbitmqctl join_cluster --ram rabbit#ip-X
I got
"The nodes provided are either offline or not running"
Obviously this is the private ip, so the other instance cant connect.
How do I tell the second instance where the first is located?
EDIT
Firewall is completely off, I have a telnet connection from one remote to the other
(to ports 5672(rmq),15672 (ui), 4369 (cluster port)).
The cookie on both servers (and the hash of the cookie in the logs is the same).
when recorded tcp when running the join cluster command and watched in wireshark. I saw the following (no ack. )
http://i.imgur.com/PLezLvQ.png
so I closed the firewall using
sudo ufw disable
(just for the tests) and I re-typed
sudo rabbitmqctl join_cluster --ram rabbit#ip-XX
and the connection was created - but terminated by the remote rabbit
here :
http://i.imgur.com/dxJLNfH.png
and the message is still
"The nodes provided are either offline or not running"
(the remote rabbit app is definitely running)
You need to make sure the nodes can access each other. RabbitMQ uses distributed Erlang primitives for communication across the nodes, so you also have to open up a few ports in the firewall. See:
http://learnyousomeerlang.com/distribunomicon#firewalls
for details.
You should also use the same data center for your nodes in the cluster, since RabbitMQ can get really sad on network partitions. If your nodes are in different data centers, you should use the shovel or federation plugin instead of clustering for replication of data.
Edit: don't forget to use the same Erlang cookie on all nodes, see http://www.rabbitmq.com/clustering.html for details.
The issue are probably TCP ports that should be opened.
You should do the following:
1) Create a Security Group for the Rabbit Servers (both will use it)
we will call it: rabbit-sg
2) In the Security Group, Define the following ports:
All TCP TCP 0 - 65535 sg-xxxx (rabbit-sg)
SSH TCP 22 0.0.0.0/0
Custom TCP Rule TCP 4369 0.0.0.0/0
Custom TCP Rule TCP 5672 0.0.0.0/0
Custom TCP Rule TCP 15672 0.0.0.0/0
Custom TCP Rule TCP 25672 0.0.0.0/0
Custom TCP Rule TCP 35197 0.0.0.0/0
Custom TCP Rule TCP 55672 0.0.0.0/0
3) make sure both EC2 use this security group,
note that we opened all TCP between the EC2
4) make sure the rabbit cookie is the same and that you reboot the EC2
after changing it in the slave EC2