I have set up a EC2 micro instance and installed Consul, but I can't seem to connect via Curl. I can connect to the instance from itself with curl http://localhost:8500/v1/agent/self for a test. However when I try to use the AWS public ipv4 from my local machine like so http://34.230.X.X:8500/v1/agent/self I get a connection refused. On the security group I have configured inbound port 8500 open to everyone. Everything seems to be in place and correctly configured is there something I'm missing?
The AWS VPC documentation has some steps for allowing EC2 instances to be reachable from the internet:
Attach an Internet gateway to your VPC.
Ensure that your subnet's route table points to the Internet gateway.
Ensure that instances in your subnet have a globally unique IP address (public IPv4 address, Elastic IP address, or IPv6 address).
Ensure that your network access control and security group rules allow the relevant traffic to flow to and from your instance.
It sounds like you have the public IPv4 address and have verified that the security groups are good; now just make sure you don't have any network ACLs set (or set appropriately if you have them), the internet gateway, and the route table.
It sounds like you need to set consul's client address to that of the public facing IP. You can do this with the -client option.
consul agent -server -bootstrap -bind="<Your private IP>" -client="<Your public IP>" -data-dir="<Your data dir>"
Disclaimer: This would allow anyone on the internet access to this consul agent's API. So take appropriate actions to secure this thing.
Related
My Linux based EC2 instances have both public and private IPs. I am hosting two servers on it:
S3 server, which will be accessible over both internet/private network and
NFS server, which should be accessed only via private IPs/internal network.
I want to open NFS port in the Security Group but only allow the access over the EC2 instances's private IP. I don't think this can be achieved by using only security groups as when the request reaches EC2 node, the Internet Gateway has already replaced the public IP with the private IP of the EC2 instance and the instance is not even aware that there is an extra public IP associated with it.
Instead what can be done is to choose the sources and selectively allow NFS access only to the VPCs and on-premises network (in case there is a VPN connectivity) but that would also mean that every time a new VPC is created OR a new VPN endpoint is established, someone has to modify the Security Group to accommodate new IP addresses.
What I ideally need is a way to apply port and IP based rules on the Internet Gateway which is currently not available/exported. Looking for alternatives.
The simplest method would be to add an Inbound rule to the Security Group where the Source is the CIDR range of the VPC.
For example, if your VPC is 172.31.0.0/16, then use this as the Source in the security group. It would permit any inbound connection from that IP address range.
I have an application and api running/hosted in same aws ec2 instance . I have enabled ssl cert using acm via load balancer for application domain . However , my api is exposing via ec2 public ip i.e http://ec2ip. In such scenario how can I bind ssl cert in IP address i.e https://ec2ip ?
You ideally don't want to have a public IP on your load-balanced EC2. You can achieve this by placing the EC2s in a private subnet. This will need bastion server in order to SSH though.
If you absolutely want HTTPS on an IP address, this SO page is the answer. If you do set that up, make sure that it is an elastic IP address.
If you have load balance you shouldn't directly access your instance using public IP. As per AWS documentation you shouldn't even have a public IP address for your instance.
someday if you run security assessment to your aws environment, AWS Foundational Security Best Practices v1.0.0 will be failed because of public IP.
EC2 instances should not have a public IPv4 address
This all about security concerns. Typically, only a Load Balancer is exposed to the Internet.
Back to Basics: Protecting Your Network in the Cloud
My application is working fine on the Amazon EC2 Windows Server. But when I am trying to access the same through the elastic public IP, it is not accessible. I have seen the inbound configurations and the ports(HTTP,HTTPS,SSH) are enabled. Infact, I added a rule to All Traffic from Anywhere. But no success.
Firewall ports are open in host server. The URL is accessible from private IP from other EC2 machines in same network
http://3.45.54.89:8080/My-App/ ----> Public IP- Not Working
http://10.0.2.23:8080/My-App/ ----> Private IP - Working
Please guide. Stuck Badly in this
The fact that you can access the port from within the network points out that you indeed have a rule somewhere in the VPC that is blocking the connection from outside the network.
Here are the components you need to access a resource inside a VPC from outside the VPC:
Internet Gateway: This is the entry point into the VPC. Seems like this is already working as expected as you can access the instance in the first place.
(optionally) Bastion host: If the resource you are trying to connect to is in a private subnet you need a bastion host in the public subnet. Read more about it here.
NACL: If you have not changed the defaults, this should allow the requests to flow through. Note that NACL are stateless i.e. you need to allow both inbound and outbound.
Security Group: As the final layer, the security group should allow the traffic on the ports, to the appropriate cidr block.
Based on the scenario you have described, my guess is that your instance is in a private subnet. If it is, then you need to route the requests through something in the public subnet.
Edit the firewall ports for an IIS website in Windows Server. if the iis apps are not in the inbound list please add them and try again.
https://www.youtube.com/watch?v=YQcklFuWrcw
I'm learning AWS and how to configure networking for EC2 instances and have a few questions. I'm using CentOS 7 in t2.micro instances.
The private IP is tied to the NIC in the instance as shown by ifconfig -a. The purpose seems to be a single point of contact for the server. Adding another network interface does NOT add another NIC as shown by ifconfig -a. Since the primary network interface cannot be a static IP, a secondary network interface is necessary for most configurations. For example, to connect the application to the database server, use the static IP assigned to the second network interface. Am I understanding this correctly?
The public IP is shown in the AWS console and provides a means to connect to the instance via SSH, assuming you configure the SG. The public IP also provides a means to access the internet for system updates. This seems to contradict the AWS documentation for NAT. If the public IP already provides internet access, why is a NAT (instance or gateway) needed? This is in reference to system updates which the documentation references.
You can use a NAT device to enable instances in a private subnet to connect to the Internet (for example, for software updates) or other AWS services, but prevent the Internet from initiating connections with the instances. A NAT device forwards traffic from the instances in the private subnet to the Internet or other AWS services, and then sends the response back to the instances.
Is a public IP and private IP are always assigned to each instance? I haven't walked through the process of creating an [new] AMI to verify if there's an option to not have a public IP. If the instance doesn't have a public IP, will the AWS console Connect button still allow you to connect to it to administer the server? Under what scenario will an instance NOT have a public IP? How do you connect to that instance to administer it?
I have read the NAT Gateway documentation and understand much of it. I'm having trouble understanding the pieces that state a NAT gateway or internet gateway is necessary to enable internet access, when it seems this is enabled by default. What am I missing?
I think your confusion stems from your third question. A public IP is not always assigned to an instance. Public IP is an option that you can enable or disable in public VPC subnets, and in private VPC subnets public IP isn't an option at all. For EC2 instances without a public IP a NAT gateway (or NAT instance) is required in order to access anything outside of the VPC.
You may want to place something like a database server in a private subnet so that nothing outside your VPC can ever access it. However you might want the database server to be able to access the Internet to download patches or something, or you may want it to access the AWS API in order to copy backups to S3 or something, in which case you would need a NAT Gateway to provide the server access to resources outside your VPC.
I'm new to setting up applications and currently facing issues connecting to my IP address.
Recently, I launched my first AWS instance and it was working fine before I attached it to an Elastic IP (trying to attach to my GoDaddy domain). The instance state is "running" and everything looks healthy, but when I go to the Public IP/Elastic IP, I get an error message saying: "This site can’t be reached. XX.XXX.XX.XXX refused to connect". I'm using a Mac and my web server is listening on port 80.
Things I have checked:
internet connection is working
not using any firewall/anitvirus
emptied all cache/cookies
not using a proxy server
My Security Group
– inbound ports 80, 8080, 22 and 3389;
– outbound ports 8080, All traffic.
My VPC
– subnet ID is verified and "available"
– route Tables 172.31.0.0/16 & 0.0.0.0/0 are "active", not propagated
Can someone help and please point out what I'm doing wrong?
Attaching an Elastic IP Address to an Amazon EC2 instance does not change anything on the instance itself. It is purely an assignment of a Public IP Address within the Amazon VPC.
Amazon EC2 instances do not normally know their own public IP address. Instead, traffic sent to the Public IP Address is routed through the Internet Gateway and then to the private IP address of the instance. As long as you did not somehow configure the old public IP address within the instance, the assignment of the Elastic IP Address should not be a problem.
You can remove the Elastic IP Address and try connecting again -- the instance will receive an auto-assigned IP address again (which might change whenever you start/stop the instance).
Some things you could try are:
Connect to another instance in the same subnet, with the same Security Group. If this works, then you know that the problem is with the instance itself, rather than the network.
Try connecting to the non-responsive instance from another instance in the same subnet using the private IP address of the non-responsive instance. This will eliminate potential networking problems.
The standard things to always check when attempting to connect from the Internet to an EC2 instance are:
Internet Gateway attached to the VPC
You are referencing the instance via a Public IP Address
Instance was launched in a public subnet, which means that the subnet is associated to a Route Table that routes to the Internet Gateways
Security Group is permitting the inbound traffic from your IP Address and port (outbound traffic configuration is irrelevant because Security Groups are stateful)
Network ACL is not blocking the traffic (by default it permits all inbound and outbound traffic)
The instance is listening on the port (eg Linux SSH on port 22, Windows RDP on port 3389)
There are no host-based firewalls on the instance blocking traffic (eg Windows Firewall)
I always reboot my Linux servers on AWS after associating an elastic IP. Normally I wouldn't blindly suggest rebooting a Linux server, but I have found it helpful in cases like this. There are several things you should think about before rebooting. Making sure you don't have important files exclusively on volatile storage would be one example.
Re "...when I go to the Public IP/Elastic IP..." How are you going to the address? Sounds like you're trying to connect with a web browser.
Have you tried connecting from your Mac over some other protocol, like ssh? That would be another way to confirm that your elastic IP is in effect
Have you tried to connect to the web server more directly? Like using wget from the server's shell? You would use the private IP address or localhost, so that doesn't help diagnose the elastic IP address.